Deployment Descriptors

Deployment Descriptors ^Locate

Overview ^Locate

A deployment descriptor is an XML document describing a package. It contains various settings regarding the Web service deployment, such as the URL at which it will be exposed and the transport protocol that the Web service uses. It is bundled within the package, along with Web service classes, by a packaging tool. Its structure has been designed so it may be created by hand using an XML-enabled or a plain-text editor. In most cases, though, it is generated by an integrated development tool. The deployment descriptor's XML Schema can be found in the package.xsd file in the conf subdirectory of the WSO2 SOA Enablement Server distribution.

Example 56 is a basic deployment descriptor file describing a service accessible at the URL http://server:port/InterceptorService, implemented by class demo.interceptor.InterceptorServiceImpl. As this chapter shows, you can do a lot more with deployment descriptors. The elements of deployment descriptors are described in Deployment Descriptor Reference.

Example 56. Sample Deployment Descriptor

<?xml version="1.0" encoding="UTF-8"?
<package name="InterceptorService"
    client-package="true"
    targetNamespace="http://wso2.com/package/demo/advanced/
	                 interceptor/server"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:tns="http://wso2.com/package/demo/advanced/interceptor/server"
    xmlns="http://wso2.com/wasp/package/1.2"
    version="1.0">
    <license>http://wso2.com</license>
    <processing name="InterceptorProcessing">
        <interceptor name="MyInterceptor"
            implementation-class="demo.advanced.interceptor.MyInterceptor"
            direction="in out"/>
    </processing>
    <service-client port-name="svc:InterceptorService"
        xmlns:svc="http://wso2.com/wsdl/example/interceptor/"
        processing="tns:InterceptorProcessing">
    </service-client>
</package>

Extended Configuration ^Locate

In some cases you may need to customize the Web service configuration, by extending it with parts you create yourself. These additional parts always use a different namespace than the package.

Extended configuration elements can be attached to any of the following elements:

Example 57 shows an extended configuration used inside package and transport elements (transportConfiguration, packageConfiguration). Note that the additional parts use the namespace http://my.org while the package uses http://systinet.com/wasp/package/1.2.

For an in-depth treatment of custom Web service configuration, please see Custom Configuration.

Example 57. Extended Configuration

<package name="configuration"
    xmlns="http://wso2.com/wasp/package/1.2"
    targetNamespace="urn:examples"
    xmlns:tns="urn:examples"
    version="1.0">
    <transport name="ConfiguredTransport"
        implementation-class="examples.MyTransport" scheme="myhttp">
        <transportConfiguration xmlns="http://my.org">
           <param1>
               <speed attr="1"/>
               ...some content...
           </param1>
           <dimensions length="10in"/>
        </transportConfiguration
    </transport>
    <packageConfiguration xmlns="http://my.org">
        <SomeWASPTimeout>100</SomeWASPTimeout>
    </packageConfiguration>        
</package>

Part Names ^Locate

Each part of the deployment descriptor (service-instance, processing, interceptor, etc.) can be referenced by its name. The qualified name of the part consists of its namespace and a local name. The local name is specified by the name="..." attribute and the namespace is the target namespace of the deployment descriptor where the item is defined.

Each name in a named part must be unique. Note that several deployment descriptors can share the same target namespace. You must take care to avoid name conflicts. Also note that named configuration elements must be unique throughout WSO2 SOA Enablement Server configuration files, as explained in Unique name Attribute.

References to Parts ^Locate

The export and processing elements can contain the <use ref ="namespace:localName"/> sub-element (see Example 61, Example 58, Example 59, Example 60 and Example 65), which refers to a named part of this or another deployment descriptor. Any part defined at the top level of the local deployment descriptor can be referenced in this way. Parts from another deployment descriptor must be exported to be accessible.

Exports and Dependencies ^Locate

Besides references to the parts defined in a local deployment descriptor, parts from other deployment descriptors can also be referenced. Each of these deployment descriptors must be mentioned in a dependency element. Referenced parts must be exported from the deployment descriptor in an export element.

There are two types of exports: 'default' and 'pushed,' depending on the value of the push attribute. The default type (push="false") lets you refer to exported elements with the expression <use ref = "importedNS:interceptor1"/> within a processing element. The pushed type (push="true") allows exported parts to be used everywhere a reference to that package occurs. For example, when you export a processing with the push="true" attribute from package A, this processing will precede all processings in packages that refer to package A in their dependency element. The interceptors contained in that exported processing will precede all local interceptors. Both default and pushed exports are shown in Example 58.

Example 58. Exporting Deployment Descriptor Parts

<?xml version="1.0" encoding="UTF-8"?>
<package name="export" targetNamespace="urn:examples/export" 
    version="1.5"
    xmlns="http://wso2.com/wasp/package/1.3" 
    xmlns:tns="urn:examples/export">
    <serialization name="ExportedSerialization" 
        serializer-class="examples.Serializer"/>
    <fault-serialization name="PushedExportedFaultSerialization"
        serialized-exception-class="examples.Exception" 
        serializer-class="examples.FaultSerializer"/>
    <processing name="ExportedProcessing">
        <use ref="tns:ExportedSerialization"/>
        <use ref="tns:PushedExportedFaultSerialization"/>
    </processing>
    <export push="false">
        <use ref="tns:ExportedSerialization"/>
        <use ref="tns:ExportedProcessing"/>
    </export>
    <export push="true">
        <use ref="tns:PushedExportedFaultSerialization"/>
    </export>
</package>

A deployment descriptor using imported parts must include a dependency element with a ref attribute referring to the targetNamespace and name of the exporting package. The imported parts are included in the use subelements of a processing element. 'Pushed' exports can be excluded from a processing by setting the attribute ignore-pushed="true". Example 59 is a deployment descriptor importing the parts exported by the descriptor in Example 58. Note the definition of the exportns namespace; note also the presence of both a processing that includes and one that excludes 'pushed' exports.

	Note
	Imported parts follow a natural order, but this may be overridden. Please see Part Ordering.

Example 59. Importing Deployment Descriptor Parts

<?xml version="1.0" encoding="UTF-8"?>
<package name="use" targetNamespace="urn:examples" version="1.0"
         xmlns="http://wso2.com/wasp/package/1.3"
         xmlns:exportns="urn:examples/export" xmlns:tns="urn:examples">
    <dependency ref="exportns:export" version="1.0"/>
    <serialization name="tns:LocalSerialization" 
        serializer-class="examples.Serializer"/>
    <serialization name="LocalFaultSerialization" 
        serializer-class="examples.Serializer"/>
    <processing name="LocalProcessing1">
        <use ref="exportns:ExportedProcessing"/>
        <use ref="tns:LocalSerialization"/>
    </processing>
    <processing name="LocalProcessing2">
        <!-- PushedExportedFaultSerialization is included here! -->
        <use ref="tns:LocalFaultSerialization"/>
        <use ref="exportns:ExportedSerialization"/>
    </processing>
    <processing ignore-pushed="true" name="LocalProcessing2">
        <!-- PushedExportedFaultSerialization is excluded here! -->
        <use ref="exportns:ExportedSerialization"/>
        <use ref="tns:LocalFaultSerialization"/>
    </processing>
</package>

Imported parts can be re-exported, as shown in Example 60.

Example 60. Re-exporting an Imported Part

<?xml version="1.0" encoding="UTF-8"?>
<package name="reexport" targetNamespace="urn:examples/reexport" version="1.0"
    xmlns="http://wso2.com/wasp/package/1.2"
    xmlns:exportns="urn:examples/export" xmlns:tns="urn:examples/reexport">
    <dependency ref="exportns:export" version="1.0"/>
    <export push="false">
        <use ref="exportns:ExportedSerialization"/>
    </export>
</package>

Part Ordering ^Locate

When writing a deployment descriptor, it is important to keep some elements in a particular order. A good example is the order of interceptors implementing security: the encrypting interceptor must always be at one end of the interceptor chain.

There is a natural order preserved in deployment descriptors. It follows several rules:

Elements from referenced processings and server processings are put ahead of other elements.
Elements from pushed imports are put ahead of other elements; the order of elements in exports and dependencies is preserved.
Otherwise the order of declared and referenced elements in processing is retained.

Example 61 shows this:

Example 61. Natural Ordering

<processing name="Processing1">
    <interceptor name="InterceptorB" 
        implementation-class="example.InterceptorB"/>
        <use ref="tns:InterceptorC"/>
        <use ref="tns:Processing2"/>
    <interceptor name="InterceptorD"
    implementation-class="example.InterceptorD"/>
</processing>
<processing name="Processing2">
    <interceptor name="InterceptorA"
        implementation-class="example.InterceptorA"/>
</processing>
<interceptor name="InterceptorC"
implementation-class="example.InterceptorC"/>

In Example 61 the natural order of interceptors in Processing1 will be: InterceptorA, InterceptorB, InterceptorC, InterceptorD.

Instead of the natural order, you can specify an explicit order. Ordered parts have two attributes in which the explicit order can be refined: preceding-parts and following-parts. Let us change the declaration of Processing from the previous example, as in Example 62.

The resulting order of interceptors in Processing1 would be: InterceptorB, InterceptorC, InterceptorD, InterceptorA.

Example 62. Explicit Ordering

<?xml version="1.0" encoding="UTF-8"?>
<processing name="Processing2">
    <interceptor implementation-class="example.InterceptorA" 
       name="InterceptorA" 
    preceding-parts="tns:InterceptorD"/>
</processing>

The user can specify as preceding-parts or following-parts either a list of QNames of parts or all applicable parts. The latter is specified with an asterisk (*).

The following parts of a deployment descriptor are ordered. So these parts have preceding-parts and following-parts attributes:

Using InfoPath on a Standalone WSO2 SOA Enablement Server ^Locate

In order to use Microsoft's InfoPath with WSO2 SOA Enablement Server for Java, it is necessary to unset SSJ's namespace optimization flag. To do this on a standalone WSO2 SOA Enablement Server, insert the following code into the service-endpoint (for a service) or service-client (for a client) element of your package deployment descriptor:

<envelopePrefix xmlns="irrelevant_value" value=""/>
<namespaceOptimization xmlns="irrelevant_value">false</namespaceOptimization>

Namespace optimization can also be turned off at runtime, for a WSO2 SOA Enablement Server embedded in an application. Please see InfoPath in Runtime Configuration for details.

To turn off namespace optimization globally for all services and clients on an instance of WSO2 SOA Enablement Server, set the wasp.soap.caching property to false, as described in WSO2 SOA Enablement Server Configuration.

Deployment Descriptor Reference ^Locate

The following sections describe the elements of a deployment descriptor XML document. Note that required attributes and elements are marked. Other attributes and elements are optional; the default value, if any, is noted.

To navigate the document element hierarchy, visit the root element of the document first: the package element.

<attributes> ^Locate

The attributes element aggregates information about attributes defined for its parent service-endpoint, service-instance or service-client. Attributes are custom metadata that can be associated with classes, fields, methods or method parameters.

The attributes element may contain any number of optional class sub-elements.

Example 63 shows the use of the attributes element within the service-endpoint element.

Example 63. Using attributes within service-endpoint

<?xml version="1.0" encoding="UTF-8"?>
<package name="MyService" targetNamespace="urn:examples" version="1.0"
    xmlns="http://wso2.com/wasp/package/1.2"
    xmlns:ns0="http://wso2.com/wsdl/" xmlns:tns="urn:examples">
    <service-endpoint name="MyService" path="/MyService" 
    service-instance="tns:MyServiceInstance">
        <wsdl service="ns0:JavaService" uri="MyService.wsdl"/>
        <attributes>
            <class name="examples.MyService">
                <attribute key="remoteServer" value="http://mercury.com"/>
                <field name="id">
                    <attribute key="columnName" value="server_id"/>
                </field>
                <method name="goThere(java.lang.String)">
                    <attribute key="transaction" value=""/>
                </method>
                <method name="send(java.lang.String,int[])">
                    <parameter number="0">
                        <attribute key="sign" value=""/>
                    </parameter>
                </method>
            </class>
        </attributes>
    </service-endpoint>
    <service-instance implementation-class="examples.MyService" 
    name="MyServiceInstance"/>
</package>

<class> ^Locate

An element containing the following attribute:

name
A required attribute: full qualified name of the class.

The class element can contain any number of the following optional sub-elements:

attribute
An element containing the following attributes:
- key
  A required attribute: the unique key of the attribute.
- value
  An optional attribute: the value of the attribute.
field
An element containing the following attribute:
- name
  A required attribute: name of the class field.
The field element can contain any number of optional attribute sub-elements, as is the case with the parent class element.
method
An element containing the following attribute:
- name
  A required attribute: name of the class method.
The syntax for specifying the method name is method(VarType1,VarType2...). For example, hello(java.lang.String, int[]).
The method element can contain any number of optional attribute sub-elements, as is the case with the parent class element. It may also contain any number of optional parameter sub-elements:
- parameter
  An element containing the following attribute:
  - number
    A required attribute: the number of the parameter. The first parameter of the method is numbered zero. A negative value denotes a return value.
    The parameter element can contain any number of optional attribute sub-elements, as is the case with the ancestral class element.

<dependency> ^Locate

The dependency element specifies deployment descriptors whose parts will be imported. You may specify more than one package with exported parts. Please see Exports and Dependencies and the export element.

The dependency element has the following attributes:

ref
A required attribute: the full qualified name of the referred deployment descriptor. Please see Part Names and the name attribute of the package element.
version
A required attribute specifying the minimal acceptable version of the referred deployment descriptor. The syntax is the same as in the case of determining the version of the deployment descriptor: major and minor versions are compared; the major version has higher priority.

The dependency element can have a documentation sub-element.

<documentation> ^Locate

Various parts of a deployment descriptor can contain the documentation element, which describes the element. Its content is used by various visual tools to display the part properly. The documentation element has the following attribute:

url
Optional link to further documentation.

The documentation element can contain some or all of the following sub-elements:

description
A more detailed short identification of the element used upon displaying the part in a visual tool.
display-name
A required element: The short identification of the element used when displaying the part in a visual tool.
large-icon, small-icon
The optional URLs of images used when displaying the part in a visual tool.

The documentation element can be attached to any of the following elements:

dependency

export

fault-serialization

handler

interceptor

package

processing

serialization

service-client

service-endpoint

service-instance

Example 64. Use of <documentation>

<?xml version="1.0" encoding="UTF-8"?>
<package name="documentation" targetNamespace="urn:examples" version="1.0"
    xmlns="http://wso2.com/wasp/package/1.2" xmlns:tns="urn:examples">
    <license>http://wso2.com/license.xml</license>
    <documentation url="http://wso2.com/documentation-example.html">
        <display-name>Documentation Example</display-name>
        <description> A well-documented package with a well-documented
            interceptor </description>
        <small-icon>small.gif</small-icon>
        <large-icon>large.gif</large-icon>
    </documentation>
    <packager>
        <name>Devaka Randeniya</name>
        <email>devaka@wso2.com</email>
        <company>WSO2 Inc.</company>
        <url>http://wso2.com</url>
    </packager>
    <interceptor implementation-class="examples.Interceptor" 
    name="WellDocumentedInterceptor">
        <documentation 
            url="http://wso2.com/documentation-interceptor-example.html">
            <display-name>Well Documented Interceptor</display-name>
            <description> A well-documented interceptor </description>
            <small-icon>small.gif</small-icon>
            <large-icon>large.gif</large-icon>
        </documentation>
    </interceptor>
</package>

<export> ^Locate

The export element specifies what parts of the deployment descriptor can be referenced from another deployment descriptor. Please see Exports and Dependencies. This element has the following attribute:

push
Set to true if this export should be treated as a pushed export. Please see Exports and Dependencies.

A named part is exported by referring to it using the <use ref = "namespace:localName"/> expression.

Parts of the following types can be exported from the deployment descriptor:

fault-serialization

handler

interceptor

processing

serialization

service-instance.

It is possible to have multiple exports in one deployment descriptor, some or all of which can be 'push' type. It is also possible to re-export an imported part; just take care to use the proper namespace in the <use ref = "..."/> expression.

The export element can contain a documentation sub-element.

<fault-serialization> ^Locate

The fault-serialization element contains fault serialization configuration information. Please see Structured SOAP Fault Serialization. It has the following attributes:

deserializer-class
The name of the class that does the deserialization. Either deserializer-class or serializer-class is required.
fault-actor
A string, SOAP fault actor. See SOAP Faults.
fault-code
A qualified name, SOAP fault code. See SOAP Faults.
fault-detail
A qualified name, SOAP fault detail. See SOAP Faults.
following-parts
A list of names of parts (fault serializations and processings) that should be placed after this interceptor. Please see Part Ordering.
name
A required attribute: the name of the fault serialization. Note that the couple (targetNamespace, name) must create a unique identifier. Please see Part Names.
preceding-parts
A list of names of parts (fault serializations and processings) that should be placed ahead of this interceptor. Please see Part Ordering.
serialized-exception-class
The name of the exception class this fault serialization (de)serializes.
serializer-class
The name of the class which does the serialization. Either deserializer-class or serializer-class is required.

The fault-serialization element can contain the following sub-elements:

documentation

<handler> ^Locate

The handler element specifies usage of a JAX-RPC handler. Please see SOAP Message Handlers. It has the following attributes:

direction
Any combination of in, out and fault. The default is all directions.
implementation-class
A required attribute: the name of the class implementing this handler.
name
A required attribute: the name of the handler. Note that the couple (targetNamespace, name) must create a unique identifier. Please see Part Names.

The handler element can contain the following sub-elements:

<header> ^Locate

The header element describes the SOAP header transmitted by a given handler. It has the following attributes:

name
QName of header element.
type
QName of header type, used in rpc style.
class
Java class name describing header structure.
direction
Direction of a header. It can be in, out or in/out.

<interceptor> ^Locate

The interceptor element aggregates information related to an interceptor. It has the following attributes:

direction
It can be in, out or in/out. The default is in/out.
following-parts
A list of names of parts (interceptors and processings) that should be placed after this interceptor. Please see Part Ordering.
implementation-class
A required attribute: the name of the class implementing this interceptor.
name
A required attribute: the name of the interceptor. Note that the couple (targetNamespace, name) must create a unique identifier. Please see Part Names.
preceding-parts
A list of names of parts (interceptors and processings) that should be placed ahead of this interceptor. Please see Part Ordering.

The interceptor element can contain the following sub-elements:

documentation

<license> ^Locate

The license element contains the URL of a document with licensing information for the package.

<location> ^Locate

The location element contains the deployment descriptor URL. Its value is set by the tool that created or processed the deployment descriptor.

<package> ^Locate

The package element, the root element of the deployment descriptor document, contains all the elements of the deployment descriptor. It has the following attributes:

client-package
An optional attribute: set to true if this deployment descriptor describes a client package, false otherwise. The default value is false.
library
An optional attribute: set to true if this deployment descriptor describes a library package, false otherwise. The default value is false. Packages that depend on a library package have access to its classloader. This means they have access to the classes of the library package. Please see the dependency element.
name
A required attribute: the name of the deployment descriptor. Note that the pair (targetNamespace, name) must form a unique identifier of the deployment descriptor. This applies to almost all named parts of a deployment descriptor. Please see Part Names.
targetNamespace
A required attribute: the name of the target namespace of the contents of the deployment descriptor, for example http://www.systinet.com/demos/HelloWorld. Please see Part Names.
version
A required attribute: the version of the package used when creating a dependency on a package, where this is the minimal acceptable version specified. The format is major.minor where major and minor version numbers are non-negative integers, for example version = "1.0".

All sub-elements of the package element are optional, although it makes no sense to create a deployment descriptor with no content. A package element can contain the following elements:

dependency

documentation

export

fault-serialization

handler

interceptor

license

location

packager

processing

serialization

service-client

service-endpoint

service-instance

transport

type-mapping

<packager> ^Locate

The packager element contains information about the author of the package. It can contain some or all of the following sub-elements:

email, company
The optional contact information.
name
A required element: the name of the packager.
url
An optional link to further information about the packager.

<processing> ^Locate

The processing element aggregates service-related settings. It has the following attributes:

ignore-pushed
If true, all push attributes of export elements from referred deployment descriptors will be ignored and those export elements will be treated as normal, non-pushed export elements. Please see Exports and Dependencies.
name
The name of the processing. Note that the couple (targetNamespace, name) must create a unique identifier. Please see Part Names.

The processing element can contain the following sub-elements:

documentation
fault-serialization
handler
interceptor
Another processing
schema
serialization
service-instance
type-mapping

use

The use sub-element, with its attribute ref, refers to any of the following parts:

fault-serialization

handler

interceptor

processing

serialization

type-mapping

<schema> ^Locate

The schema element allows you to specify the path of the XML Schema document. This element has the following attributes:

namespaceURI
A required attribute: the namespace of the XML Schema.
location
A required attribute: the URI of the XML Schema document. It can be relative to the root of the deployment package.

<serialization> ^Locate

The serialization element contains serialization configuration information. Please see Default Serialization. It has the following attributes:

deserializer-class
The name of the class which does the deserialization. Either serializer-class or deserializer-class is required.
following-parts
A list of names of parts (serializations and processings) that should be placed after this interceptor. Please see Part Ordering.
name
A required attribute: the name of the serialization. Note that the couple (targetNamespace, name) must create a unique identifier. Please see Part Names.
preceding-parts
A list of names of parts (serializations and processings) that should be placed ahead of this interceptor. Please see Part Ordering.
serialized-class
The name of the class this serialization (de)serializes.
serialized-type
The qualified name of the (de)serialized XML type.
serializer-class
The name of the class which does the serialization. Either serializer-class or deserializer-class is required.

The serialization element can contain the following sub-elements:

documentation

<service-client> ^Locate

The service-client element aggregates information about a client package. It has the following attributes:

async-time-out
The time in seconds after which, without communication, the connection is closed. Applies to asynchronous service invocation only.
async-transport
Name of the protocol used for asynchronous service invocation, such as http, jms, etc.
initiating-security-provider
A comma-separated list of authentication providers for initiating reqests, of type xsd:NMTOKEN. Please see Setting an Initiating Provider.
port-name
Either port-name or url is required: a qualified name, the type of interface to which settings from this service-client apply.
processing
Qualified name of the processing used by this service.
url
Either port-name or url is required: the endpoint of the service to which settings from this service-client apply.

The service-client element can contain the following sub-elements:

envelopePrefix, namespaceOptimization
These two elements are only specified if WSO2 SOA Enablement Server for Java is to be used as a standalone server in conjunction with InfoPath. For details please see Using InfoPath on a Standalone WSO2 SOA Enablement Server.
documentation

Example 66. Use of <service-client>

<?xml version="1.0" encoding="UTF-8"?>
<package name="devguide_serviceclient_settings" targetNamespace="urn:examples" version="1.1"
    xmlns="http://wso2.com/wasp/package/1.2" xmlns:tns="urn:examples">
    <dependency ref="tns:processing" version="1.0"/>
    <service-client port-name="svc:HelloService"
        processing="tns:SuperProcessing" 
        xmlns:svc="http://wso2.com/wsdl/demo/basic/hello/"/>
</package>

<service-endpoint> ^Locate

The service-endpoint element aggregates information related to a server package. It has the following attributes:

accepting-security-providers
A comma-separated list of authentication providers that accept requests, of type xsd:NMTOKEN. Please see Accepting Providers Settings.
initiating-security-provider
A comma-separated list of authentication providers for initiating reqests, of type xsd:NMTOKEN. Used for service-to-service communication, when the Web service is acting as a service client. Please see Setting an Initiating Provider.
interface
The fully qualified name of a Java interface, in xsd:string format.
name
A required attribute: the name of the service endpoint. Note that the pair (targetNamespace, name) must create a unique identifier. Please see Part Names.
path
A required attribute: the endpoint to which the service is deployed and where it is prepared to serve client requests. Note that the path must begin with a slash character, for example path="/HelloService"! The only exception is a path for e-mail transport, which is an e-mail address without the slash, for example path="mailservice@yahoo.com".
processing
The qualified name of the processing used by this service endpoint.
service-instance
A required attribute: the qualified name of the service instance used by this service endpoint.
service-type
The type of the service: either java, xml or raw. Choosing none enables autodetection, which decides on the type of service according to the exposed interface. Please see Types of Services.
url
If this attribute is specified, its value overrides the <soap:address location="..."/> tag in the WSDL. When left unspecified, WSO2 SOA Enablement Server automatically sets the <soap:address location="..."/> tag to match the address in the GET request. For example, when a WSDL is obtained from http://localhost:6060/HelloService/wsdl, it contains the tag <soap:address location="http://localhost:6060/HelloService"/>. A WSDL of the same service endpoint obtained from http://myserver.mydomain.com:6060/HelloService/wsdl contains the tag <soap:address location="http://localhost:6060/HelloService"/>.

The service-endpoint element can have the following sub-elements:

envelopePrefix, namespaceOptimization
These two elements are only specified if WSO2 SOA Enablement Server for Java is to be used as a standalone server in conjunction with InfoPath. For details please see Using InfoPath on a Standalone WSO2 SOA Enablement Server.
documentation
wsdl
The location of the WSDL file corresponding to the service endpoint. The wsdl element has the following attributes:
- uri
  A required attribute: the URI of the WSDL file.
- service
  The WSDL file can specify more than one service. In such a case, this is the name of the proper service.

Example 67 shows the service-endpoint and service-instance elements.

Example 67. Use of <service-endpoint> and <service-instance>

<?xml version="1.0" encoding="UTF-8"?>
<package name="service" targetNamespace="urn:examples" version="1.0"
    xmlns="http://wso2.com/wasp/package/1.2" xmlns:tns="urn:examples">
    <dependency ref="tns:processing" version="1.0"/>
    <service-instance implementation-class="examples.Service1"
        instantiation-method="per-client" name="LocalServiceInstance"
        preload="true" ttl="300"/>
    <service-endpoint name="MyRawGetService" path="/RawGetService"
        processing="tns:SuperProcessing" 
        service-instance="tns:LocalServiceInstance">
        <wsdl service="HelloWorldService" 
            uri="http://wso2.com/HelloWorld.wsdl"/>
    </service-endpoint>
    <service-instance implementation-class="examples.Service2" 
    name="LocaJavaServiceInstance"/>
    <service-endpoint name="MyJavaService" path="/JavaService" 
    service-instance="LocalJavaServiceInstance"/>
</package>

<service-instance> ^Locate

The service-instance element aggregates information about a service instantiation. It has the following attributes:

accepting-security-providers
A comma-separated list of authentication providers that accept requests, of type xsd:NMTOKEN. Please see Accepting Providers Settings.
ttl
The time in seconds for which one instance lives. This applies to the per-client instantiation method.
implementation-class
A required attribute: the name of the class implementing this service-instance.
initiating-security-provider
A comma-separated list of authentication providers for initiating reqests, of type xsd:NMTOKEN. Used for service-to-service communication, when the Web service is acting as a service client. Please see Setting an Initiating Provider.
instantiation-method
Either shared (default) or per-client. Shared instantiation creates one service instance for all clients; per-client instantiation creates a new instance for each client. Please see Managing Instantiation.
max-instances
The maximal number of service instances. This applies to the per-client instantiation method and determines the maximum number of clients served at the same time.
name
A required attribute: the name of the service-instance. Note that the pair (targetNamespace, name) must create a unique identifier. Please see Part Names.
preload
Set to true if the service class should be loaded upon server start. Leave the default value, false, to load the service class on-demand the first time the service instance is invoked. Preloading the service instance will speed the first service instance call but will slow the server start.

The service-instance element can also contain the following sub-element:

documentation

Example 67 shows the service-endpoint and service-instance elements.

<transport> ^Locate

The transport element loads a specified server transport. Please see Built-In Transports.

This element has the following attributes:

default-server
Set to true if this transport should be used as a default server-side transport for the scheme specified by the scheme attribute (see below). The default value of this attribute is false.
implementation-class
A required attribute: the name of the class implementing this transport.
name
A required attribute: the name of the transport. Note that the pair (targetNamespace, name) must create a unique identifier. Please see Part Names.
preload
Set to true if the transport class should be loaded upon server start (the default value), false if the class should be loaded upon the first client request.
scheme
The scheme identification, such as http, mailto, etc.

<type-mapping> ^Locate

The type-mapping element maps XML types to data types of a specific programming language. Please see Default Serialization.

This element has the following attributes:

language
The programming language for which the map is specified. The default value is java.
name
A required attribute: the name of the type-mapping. Note that the pair (targetNamespace, name) must create a unique identifier. Please see Part Names.

The type-mapping element contains one or more type sub-elements. Each maps one XML type to the data type of the programming language. The type sub-element contains the following attributes:

name
A required attribute: qualified name of the XML type.
maps-to
A required attribute: name of the programming language data type.