Oracle Dynamic Services User's and Administrator's Guide Release 9.0.1 Part Number A88783-01 |
|
This appendix describes the descriptive matrix of the schemas and adaptors supplied by Oracle Dynamic Services.
At the top level, a service descriptor schema contains the data shown in Table C-1. Table Table C-2 through Table C-4 show the descriptive matrix for the classification, contact, and organization schemas. Required data is designated by bold element names. Element names are indented to show the relationship and hierarchy of elements. A service provider will define a service by writing an XML document that complies with the XML schema file sd.xsd and other auxiliary documents such as the classification, organization, and contact XML documents. See Example 6-11 through Example 6-15 to view the contents of sample service header and service body sections of a service descriptor schema.
Element Name | Description | |||||
---|---|---|---|---|---|---|
SERVICE_DESCRIPTOR |
Required element. The root element in the service descriptor document. |
|||||
|
SERVICE_HEADER |
Required element. The service header section. Contains high-level descriptions of the service. |
||||
|
|
NAMING |
Required element. The naming section. Contains a globally unique identifier ID, as well as NAME and DESCRIPTION elements describing what the service does. |
|||
|
|
|
ID |
Required element. An identifier uniquely identifies the service and must be a uniform resource name (URN). |
||
|
|
|
NAME |
Required element. The name of the service. |
||
|
|
|
DESCRIPTION |
Required element. The description of the service. |
||
|
|
PACKAGE |
Required element. The package section. Contains version specifications and pointers to where the service update is to be performed. |
|||
|
|
|
VERSION |
Required element. The version number of the service definition package. |
||
|
|
|
RELEASEDATE |
Required element. The release date of the service definition package. |
||
|
|
|
UPDATEURL |
Optional element. The URL to obtain the latest version of the service definition package. In general, a service should contain an update URL. Note: However, for services created by an administrator, this parameter is meant to be used locally and UPDATEURL is not applicable (not used currently). |
||
|
|
|
BINARY_RESOURCES |
Optional element. The binary resources section. For advanced usage, such as specifying locations for Java class files or stylesheets for custom services and adaptors, as well as names of resource bundles. |
||
|
|
|
|
JAR_POINTER |
Optional element. The URL of the jar file containing service-specific Java classes and resources within the service definition zip file. |
|
|
|
|
|
EXCEPTIONS |
Optional element. The exceptions section. Contains the specification for the resource bundle for custom exceptions. |
|
|
|
|
|
|
EXCEPTION_MSG_BUNDLE |
Optional element. The specification for the custom exceptions that rely on the custom resource bundle. |
|
|
DEPLOYMENT |
Required element. The deployment section. Contains a set of deployment properties from the service provider to aid the service administrator during service registration. |
|||
|
|
|
CLASSIFICATION |
Required element. An xlink to the classification XML document. Service providers can provide suggestions while a service administrator will decide the classification of the service. The XML file should comply with sd_classification.xsd. See Table C-2 for a description of the classification schema. |
||
|
|
|
CACHING |
Required element. The caching section. Contains recommended caching parameter values. |
||
|
|
|
|
MAX_AGE |
Required element. The duration that a cache entry is valid for, in seconds. If the value is 0, it means the entry should not be cached. The default value is 0. |
|
|
|
|
|
SESSION_PRIVATE |
Required element. A value of TRUE means that the scope of the cache entry is within the service engine user session. The default value is FALSE. |
|
|
|
|
|
USE_PROTOCOL |
Required element. A value of TRUE means that the protocol caching parameters will override MAX_AGE. The default value is FALSE. |
|
|
|
PROVIDER |
Required element. The service provider section. Contains information about the service provider including the provider's company name, copyright information, company URL, contacts for support, and URLs for logos. |
|||
|
|
|
ORGANIZATION |
Required element. An xlink to the organization XML document. Provides generic information about the service provider. The xml file should comply with sd_organization.xsd. See Table C-4 for a description of the organization schema. |
||
|
|
|
CONTACTS |
Required element. The contacts section. Contains detailed support contacts for this service. |
||
|
|
|
|
CONTACT |
Required repeating element. An xlink to the contact XML document. Provides information to contact a person for any issues related to the service. The xml file should comply with sd_contact.xsd. See Table C-3 for a description of the contact schema. |
|
|
|
INTERFACE |
Required element. The service interface specification. Contains the definition of an interface characterized by the schema specifications of its input, output, and exceptions. |
|||
|
|
|
NAME |
Required element. The name of the interface template. |
||
|
|
|
INPUT_SCHEMA |
Required element. An xlink to the request XML document. The URL to the request definition XML schema document, or the DTD defining the XML service request syntax. |
||
|
|
|
OUTPUT_SCHEMA |
Required element. An xlink to the response XML document. The URL to the response definition XML schema document, or the DTD defining the XML service response syntax. |
||
|
SERVICE_BODY |
Required element. The service body section. Contains detailed descriptions and information used by the Dynamic Services engine at execution time. Information is sectioned into specifications (including adaptors) for input, protocol, execution, and output. |
||||
|
|
INPUT |
Optional element. The input section. Contains the details for preprocessing the XML request from the service consumer application and includes the following sections: namespaces, alias directives, input adaptor, and rendering directives. |
|||
|
|
|
NAMESPACES |
Optional element. The namespaces section. Declares any namespaces and their prefixes that can be used in the aliases section to build the XPaths pointing to where the data is located. |
||
|
|
|
|
NAMESPACE |
Required repeating element. A single entry of a namespace definition. |
|
|
|
|
|
PREFIX |
Required element. The namespace prefix. |
|
|
|
|
|
VALUE |
Required element. The namespace value. |
|
|
|
|
ALIASES |
Optional element. The aliases section. Used by service providers to specify additional directives for the purpose of creating aliases. Aliases are used to create a map that can translate the parameters embedded in the XML document to actual parameters needed by the adaptor (for example, the protocol adaptor). |
||
|
|
|
|
ALIAS |
Required repeating element. A single entry of an alias definition. |
|
|
|
|
|
|
NAME |
Required element. The alias name. |
|
|
|
|
|
VALUE |
Required element. The alias value. Can be specified as an XPath or as a service consumer application profile property and optionally its modifier. The XPath is used at run-time to extract either the value of the node pointed to by the XPath, or the XML fragment (for which this node is the root) from the service request. |
|
|
|
RENDERERS |
Optional element. The renderers section. Contains additional rendering directives. The service provider can optionally supply some form of schema mapping specifications, such as an XSL transformation, that could map the input XML schema to a presentation form such as HTML or Wireless Markup Language (WML). Thus, the service consumer application can provide to its clients a way to enter service requests, for applications that have an HTML or WML interface. |
||
|
|
|
|
RENDERER |
Optional element. A single entry of the renderers definition. |
|
|
|
|
|
|
TYPE |
Optional element. The type of rendering directive, such as the request XML document or the type of input transformation, or both. |
|
|
|
|
|
STYLESHEET |
Optional element. An xlink to the request XML document or the schema mapping specification XSL transformation, or both. The URL to the request XML document or the XSL transformation mapping the input XML schema to a presentation form, or both. |
|
|
|
ADAPTOR |
Optional element. The input adaptor section. Specifies, optionally, an adaptor that further processes the service request before sending it to the service provider. A packaged adaptor is the XSLT input adaptor. |
||
|
|
|
|
NAME |
Optional element. The fully qualified name of the class implementing the oracle.ds.engine.InputAdaptor Java interface that handles the processing. |
|
|
|
|
|
PARAMETERS |
Optional element. The parameters specification. The service provider can optionally specify adaptor-specific parameters that are validated at service registration time and interpreted at runtime by the adaptor. These parameters must be in XML syntax. See Table C-5 for a description of the input adaptors parameters specification. |
|
|
|
PROTOCOL |
Optional element. The protocol section. Contains the details for submitting a request to the service provider. Identifies the way that a service engine accesses the underlying service. |
|||
|
|
|
ADAPTOR |
Optional element. The protocol adaptor section. Specifies, optionally, an adaptor that transforms the standard service request into the input needed by the underlying service, using the underlying protocol. |
||
|
|
|
|
NAME |
Required element. The fully qualified name of the class implementing the oracle.ds.engine.ProtocolAdaptor interface that handles the communication to the underlying service. Packaged protocol adaptors support the HTTP, HTTPS, SMTP, or JDBC protocols. |
|
|
|
|
|
DRIVER |
Required element. The driver specification. Ensures that a certain class in the classpath for the adaptor to function properly. |
|
|
|
|
|
PARAMETERS |
Optional element. The parameters specification. The service provider can optionally specify adaptor-specific parameters that are validated at service registration time and interpreted at runtime by the adaptor. These parameters must be in XML syntax. See Table C-7, Table C-8, and Table C-9 for a description of the HTTP, JDBC, and SMTP protocol adaptors parameters specifications. |
|
|
|
EXECUTION |
Optional element. The execution section. Identifies the way in which the service must be executed. It takes the request XML and returns the response from the underlying service provider. |
|||
|
|
|
ADAPTOR |
Optional element. The execution adaptor section. Specifies, optionally, an adaptor that executes a service request in a particular flow or order. |
||
|
|
|
|
NAME |
Optional element. The fully qualified name of the class implementing the oracle.ds.engine.ExecutionAdaptor Java interface that performs the execution. Packaged adaptors are compound, failover, and conditional service execution adaptors. |
|
|
|
|
|
PARAMETERS |
Optional element. The parameters specification. The service provider can optionally specify adaptor-specific parameters that are validated at service registration time and interpreted at runtime by the adaptor. These parameters must be in XML syntax. See Table C-10 and Table C-11 for a description of the compound and conditional execution adaptors parameters specifications. |
|
|
|
OUTPUT |
Optional element. The output section. Specifies the list of necessary as well as optional processing to produce the service response to the service consumer application. Includes the output adaptor and rendering directives sections. |
|||
|
|
|
RENDERERS |
Optional element. The renderers section. Contains additional rendering directives. The service provider can optionally supply some form of schema mapping specifications, such as an XSL transformation, that could map this response XML to other forms, such as HTML or WML. Thus, the service consumer application can provide to its clients a way to produce service responses, for applications that have an HTML or WML interface. |
||
|
|
|
|
RENDERER |
Optional element. A single entry of the renderers definition. |
|
|
|
|
|
|
TYPE |
Optional element. The type of rendering directive, such as the response XML document or the type of output transformation, or both. |
|
|
|
|
|
STYLESHEET |
Optional element. An xlink to the response XML document or the schema mapping specification XSL transformation, or both. The URL to the response XML document or the XSL transformation mapping the output XML schema to a presentation form, or both. |
|
|
|
ADAPTOR |
Optional element. The output adaptor section. Specifies an output adaptor to be used to transform the output returned by the execution adaptor into an XML document compliant with the output XML schema specified in the service interface. The output name is a fully qualified name of the class implementing the oracle.ds.engine.OutputAdaptor interface that handles the transformation. A packaged adaptor is the XSLT output adaptor. |
||
|
|
|
|
NAME |
Optional element. The fully qualified name of the class implementing the oracle.ds.engine.OutputAdaptor Java interface that handles the transformation. |
|
|
|
|
|
PARAMETERS |
Optional element. The parameters specification. The service provider can optionally specify adaptor-specific parameters that are validated at service registration time and interpreted at runtime by the adaptor. These parameters must be in XML syntax. See Table C-5 for a description of the output adaptors parameters specification. |
At the next level, a Classification schema contains the data shown in Table C-2. Required data is designated by bold element names. Element names are indented to show the relationship and hierarchy of elements. See Example 6-5 to view the contents of a classification schema.
Element Name | Description | |
CLASSIFICATION |
Required element. The classification information from the service provider to assist the service administrator during registration. |
|
|
CATEGORY |
Required element. The hierarchical categories specified using the substring of the Distinguished Name (DN) specified in the RFC2253 specification ( |
|
KEYWORDS |
Required element. The keywords, separated by commas. |
At the next level, a Contact schema contains the data shown in Table C-3. Required data is designated by bold element names. Element names are indented to show the relationship and hierarchy of elements. See Example 6-4 to view the contents of a contact schema.
At the next level, an Organization schema contains the data shown in Table C-4. Required data is designated by bold element names. Element names are indented to show the relationship and hierarchy of elements. See Example 6-3 to view the contents of an organization schema.
Table C-5 through Table C-12 show the descriptive matrix for the parameters section of each type of adaptor schema supplied by Oracle Dynamic Services.
An Input Adaptor schema contains the data shown in Table C-5. Required data is designated by bold element names. Element names are indented to show the relationship and hierarchy of elements. See Example 6-13 to view the contents of the input adaptor schema contained within the service body description.
An Output Adaptor schema contains the data shown in Table C-6. Required data is designated by bold element names. Element names are indented to show the relationship and hierarchy of elements. See Example 6-15 to view the contents of the output adaptor schema contained within the service body description.
An HTTP Protocol Adaptor schema contains the data shown in Table C-7. Required data is designated by bold element names. Element names are indented to show the relationship and hierarchy of elements. See Example 6-27 to view the contents of the HTTP protocol adaptor parameters section contained within the service body description.
A JDBC Protocol Adaptor schema contains the data shown in Table C-8. Required data is designated by bold element names. Element names are indented to show the relationship and hierarchy of elements. See Example 6-29 to view the contents of the JDBC protocol adaptor parameters section contained within the service body description.
An SMTP Protocol Adaptor schema contains the data shown in Table C-9. Required data is designated by bold element names. Element names are indented to show the relationship and hierarchy of elements. See Example 6-30 to view the contents of the SMTP protocol adaptor parameters section contained within the service body description.
A Compound Execution Adaptor schema contains the data shown in Table C-10. Required data is designated by bold element names. Element names are indented to show the relationship and hierarchy of elements. See Example 6-32 through Example 6-41 to view the contents of the compound execution adaptor parameters sections contained within the service body description that are described in Table C-10.
A Conditional Execution Adaptor schema contains the data shown in Table C-11. Required data is designated by bold element names. Element names are indented to show the relationship and hierarchy of elements. See Example 6-42 to view the contents of a sample conditional execution adaptor parameters section contained within the service body description.
A Failover Execution Adaptor schema contains the data shown in Table C-12. Required data is designated by bold element names. Element names are indented to show the relationship and hierarchy of elements. See Example 6-31 to view the contents of a sample failover execution protocol adaptor parameters section contained within the service body description.
|
Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|