Services. xml

Document directory

• Compile the services. xml file used to deploy a single service
• Service name
• Service Description
• Service-level Parameters
• Service
• Service-level Message Receiver
• Modules
• Service session Scope
• Service target namespace
• Schema target namespace
• Elementformdefault value in WSDL
• Expose the service on the specified transmission channel
• Overwriting
• Operation-level Message Receiver
• Add actionmapping
• Modules
• Exclusion operation

Introduction

When deploying a service in axis1, we use the service. WSDD file to configure the service. In axis2, services. XML is used instead of the service. WSDD file. The syntax of these two configuration files is completely different.

This section describes the syntax and usage of the services. xml file. In Apache axis2/Java, the same service package file can be used to deploy a single service or multiple services. No matter how the service is deployed, a valid service package file must contain the services. xml file. As we deploy services in different ways, the syntax of services. xml files is also different. There are two types of services. xml files: one for deploying a single service and the other for deploying a service group.

Compile the services. xml file used to deploy a single service

The root node of the services. xml file used to deploy a single service is service, and the entire file looks like this:

123	<service> ............... </service>

Service name

When we deploy a single service using a service package, if we do not specify the name attribute for the service node, the service package file name is the service name. For example, if the service package file name is foo. AAR, then the service name is foo. You can also add the name attribute to the service node to specify different service names. As described below:

123	<service name="foo" > ............... </service>

Service Description

Service writers can use the description element to describe the service. When viewing a service in the axis2 Web Console, we can only see the service name and service description. If the description element is not added to the services. xml file, the service name is displayed in the service description column. The service description is very useful for users who access the service. Adding service description information is very simple. You can add an optional description node to the services. xml file. The value of this node can be either plain text or HTML code snippets.

1234	<service> <description> Calculate the rectangular area </description> …… </service>

You can also write it as follows:

1234	<service> <description><b> Calculate the rectangular area </b></description> …… </service>

Note: The description node is an optional node.

Service-level Parameters

In the services. xml file, we can define parameters directly under the service node for the message context (at runtime), axisservice, or axisoperation to access. The parameter has a required parameter and optional parameter: The parameter name is a required parameter, and the locked attribute is an optional parameter.

The locked attribute specifies whether to allow the parameter value to be overwritten by the quilt node. For example, if we add a parameter whose locked attribute value is true to the axis2.xml file, an exception is thrown if the service tries to define a parameter of the same name in the services. xml file.

For example, if the axis2.xml file defines a parameter named Foo and the locked attribute is true, and the services. xml file also has a parameter of the same name, an exception is thrown during deployment. If the locked attribute of the parameter is true, the parameter defined in the parent node cannot be overwritten in the child node.

The parameter value can be anything, either plain text or XML fragment. To add service-level parameters, refer to the following:

12345

<service> ..... <parameter name=location>Colombo , Sri Lanka</parameter> ..... </service>

Service

In axis2, the Web service does not require the specified service implementation class! The axis2 architecture allows you to write web services without service implementation classes because message receivers allow this. In axis2, once the request is handed over to the Message Receiver for processing, the axis2 engine considers that its work is complete and the rest of the work is the message receiver's work. Therefore, services. XML does not require a service implementation class. However, in most cases, we still need a service class. We can add the serviceclass parameter to the services. xml file to specify the service class. The value of this parameter is the full path name of the service class. Example:

1	<parameter name="ServiceClass" locked="false">org.apache.Foo</parameter>

Service-level Message Receiver

In axis2, the message receiver is a special processor and the last processor in the in path (Request Path. Each operation in the Web service has its own message receiver, and different operations can have different message receivers. Message receivers depend on the message exchange mode. Therefore, we must specify different message receivers for different message exchange modes.

How can I specify the same message receiver for all operations? You only need to add a service-level message receiver. In this way, you do not have to specify a Message Receiver at the operation level. What we need to do is to specify a service-level message receiver. During deployment, axis2 automatically selects the correct message receiver for the operation.

1234	<messageReceivers> <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-only" class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"/> <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out" class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/> </messageReceivers>

Modules

In some cases, if the WS-Security Module is not used, we should not run the service. In this case, you only need to add the module tag to the services. xml file to use this module. It should be noted that if the module is unavailable, the service becomes a wrong service and cannot be used.

123	<service> <module ref=foo/> </service>

Service session Scope

In axis2, the Web Service has four session scopes. If this parameter is not specified, the request session range is used by default. You can specify the session range by adding an optional scope parameter to the service node. There are four session ranges:

1. Application: application level. The lifecycle is the same as that of the axis2 engine.
2. Soapsession: Use the custom reference attribute in addressing headers to manage sessions.
3. Transportsession: Uses transport cookies to manage sessions. The life cycle is the same as that of the underlying transport.
4. Request: the lifecycle is short, which is the same as the request processing cycle.

123	<service scope="application"> ...... </service>

Service target namespace

The service target namespace only plays a role in the WSDL generation process. When running, if someone tries to use? The target namespace in the generated WSDL file is the value specified in the services. xml file. At the same time, in order to use a custom WSDL file, we put the WSDL file in the META-INF directory, in this case to overwrite the original target namespace, also through to services. add the target namespace to the XML file. The default value of the target namespace is http://ws.apache.org/axis2.

To specify the target namespace, we need to add the optional targetnamespace attribute to the service node, for example:

123	<service targetNamespace=http://foo.org> …… </service>

Schema target namespace

If the WSDL file is not found in the META-INF directory when a wsdl file (runtime) or Schema (at deployment time) is generated, you can go to services. add a schema node to the XML file to specify the name space of the custom schema target.

During deployment, if the schema target namespace is not specified, the target namespace is generated based on the full path name of the service implementation class. For example, if the full path name of the service class is org. Apache. axis2.fooservice, the generated schema namespace is a http://FooService.axis2.apache.org/xsd

To use custom values, you only need to add the following nodes to the services. xml file.

123	<service> <schema schemaNamespace=http://foo.org/xsd/> </service>

Elementformdefault value in WSDL

When you use a Java class to generate a WSDL file, elementformdefault In the schema definition of the WSDL file is set to qualified by default. If qualified is true, all elements in the Response Message are limited. However, in some cases, we do not need such behavior. We hope to set elementformdefault to unqualified. In this case, you only need to add the following entries in the services. xml file.

1	<schema elementFormDefaultQualified="false"/>

Note: We can also specify the schemanamespace attribute.

Expose the service on the specified transmission channel

Axis2 can expose services on multiple transmission channels through Lister manager. For example, you can use listener manager to expose services over HTTP and TCP.

Since axis2 supports multiple transmission channels, we can expose services on the selected transmission channels. For example, in the system management service, we hope that the service will only be exposed on the channel that supports SSL, so as to ensure the security of system management.

When the server supports multiple transmission channels, all services are exposed on all channels. If you only want to expose the service on the selected channel, you need to add the transport tag to the services. xml file, as described below:

123	<transports> <transport>https</transport> </transports>

Operation and operation-related elements

The previous section describes the service-level configurations that will affect all operations in the service. For example, we use modules at the service level, which will affect all operations in the service. But sometimes we want to overwrite these configurations or add new ones in the operation.

Note: If the service implementation class is written in Java, all public methods in the service class are exposed by default. If the service class is written in other languages, you must specify the operation to be released. Otherwise, the operation is not exposed by default.

Overwriting

As mentioned above, we want to override the service-level configuration in the operation. To override service-level parameters, we need to add the operation Tag:

123456

<service> <parameter name=location locked=false>Colombo , Sri Lanka </parameter> <operation name=doSmt> <parameter name=location locked=false>California ,USA</parameter> </operation> </service>

Operation-level Message Receiver

The previous article describes how to specify a service-level message receiver. However, we can also specify different message receivers for different operations, which requires the messagereceiver tag in operation.

123	<operation name=doSmt> <messageReceiver class="org.apache.axis2.MyMessageReceiver"/> </operation>

Add actionmapping

Actionmapping is equivalent to the operation alias. We can add any number of aliases for the operation. We can filter requests based on actionmapping, or execute different processing logic for different action mapping. The client sends action mapping by specifying soapaction or WSA: Action in the request message. In this way, the axis2 distributor can distribute request messages to the correct operation.

1234	<operation name=doSmt> <actionMapping>mapping1</actionMapping> <actionMapping>http://foo.org/doSmt</actionMapping> </operation>

Modules

Just like we use modules in services, we can also use modules in operations. For example, if we only want to provide secure access to a specified operation, the best way is to use the module in these operations.

To use a module, you only need to add the module element to the operation element.

123	<operation name=doSmt> <module ref="foo"/> </operation>

Exclusion operation

By default, axis2 exposes all public methods in the implementation class (if implemented in Java ). If we place the. WSDL file in the META-INF directory, instead of all the operations in the file that we don't want to publish, we can add the excludeoperations tag to exclude the operations that we don't want to expose.

123	<excludeOperations> <operation>op1</operation> </excludeOperations>

Compile the services. xml file used to deploy the Service Group

To deploy multiple services in a single service package file, the Service Group is a convenient method. Of course, there should be a logical relationship between these services. The services. xml file used for the Service Group and for a single service. The only difference between them is the root element. For service groups, the root element is ServiceGroup. We can define multiple service elements within the ServiceGroup element.

12345678

<serviceGroup> <service name=service1> ...... <service> <service name=service2> .......... </service> </serviceGroup>

Note: In this case, the service package name is the name of the Service Group. The name attribute of the service element is mandatory and must be unique throughout the server. The system does not allow two services with the same name.

Once we understand how to write the services. xml file for a single service, it is easy to write the services. xml file for the Service Group. As mentioned above, the Service Group is only a collection of service elements, and all the syntaxes mentioned above are the same in the Service Group.