java-tju

BlogJava 联系 聚合 管理
  1 Posts :: 2 Stories :: 1 Comments :: 0 Trackbacks

services.xml Reference Print

The basic structure of a configuration is like so:

<beans xmlns="http://xfire.codehaus.org/config/1.0">
<xfire>
<inHandlers>
<handler handlerClass="">
</handler>
</inHandlers>
</xfire>
<service>
<name/>
<namespace/>
<serviceClass/>
<implementationClass/>
<serviceFactory/>
<bindingProvider/>
<style>document|rpc|message|wrapped</style>
<use>literal|encoded</use>
<scope>request|session|application</scope>
<invoker/>
<executor/>
<inHandlers>
<handler handlerClass=""/>
</inHandlers>
<outHandlers>
<handler handlerClass=""/>
</outHandlers>
<faultHandlers>
<handler handlerClass=""/>
</faultHandlers>
<createDefaultBindings>true|false</createDefaultBindings>
<bindings>
<soap11Binding name="qname" transport="" allowUndefinedEndpoints="">
<endpoints>
<endpoint name="qname" url="" />
</endpoints>
</soap11Binding>
<soap12Binding name="qname" transport="" allowUndefinedEndpoints="">
<endpoints>
<endpoint name="qname" url="" />
</endpoints>
</soap12Binding>
</bindings>
</service>
</beans>

Service Options

Here are options common to all bindings. The sections following outline options for specific bindings.

The name element is required. This will be the name of the service as exposed to the world. You will also use this name to access the Service class from the ServiceRegistry.

<name>MyService</name>

The namespace element is optional, it specifies the target namespace for the service.

<namespace>http://xfire.codehaus.org/Echo</namespace>

The style element is optional and defaults to "wrapped". Services can be of style wrapped, message, document, or rpc. Keep in mind that "document and "wrapped" both specify a document-style service but with different parameter styles, bare (unwrapped) and wrapped, respectively. The "message" option is also document style.

<style>wrapped</style>

The "use" element is optional and defaults to "literal". This determines the encoding type and can be either encoded or literal. Only literal services are supported currently.

<use>literal</use>

The class name of the object you wish to make into a service. Required.

<serviceClass>org.codehaus.xfire.HelloService</serviceClass>

The class name of the implementation which you wish to use when the service is invoked. Optional.

<implementationClass>org.codehaus.xfire.HelloServiceImpl</implementationClass>

The ServiceFactory controls how the Service is built and configured. Optional.

<serviceFactory>your.service.builder.class</serviceFactory>

To use the Java 5 JSR 181 Service factory

<serviceFactory>jsr181</serviceFactory>

To use the Commons-Attributes JSR 181 Service factory

<serviceFactory>commons-attributes</serviceFactory>

If you are using XMLBeans, you will want to specify "<serviceFactory>org.codehaus.xfire.xmlbeans.XmlBeansServiceFactory</serviceFactory>".

The path to the WSDL file for your service. Optional.

<wsdlURL>file:///location/of/wsdl</wsdlURL>

The scope element is optional. Specify "application" to have your service object persist indefinitely, "session" to have one service object per session, and "request" to create a new service object for every request. The default is "application".

<scope>session</scope>

The invoker element is optional. It can be used to set a non-default Invoker for a service. Available since XFire 1.1-beta1

<invoker>#invokerBean</invoker>

The executor element is optional. It can be used to set a non-default Executor (i.e. scheduler) for a service. Available since XFire 1.1-beta1

<executor>#executorBean</executor>

To configure a #bean using a constructor parameter you can use the following syntax.

<bean name="invokerBean" class="some.package.MyInvoker">
<constructor-arg value="myConstructorParam"/>
</bean>

Handlers

You may want to add request, response or fault handlers to your service. To do this use the <requestHandlers>, <responseHandlers> or <faultHandlers> sections:

<service>
<inHandlers>
<handler handlerClass="your.custom.handler.Class"/>
</inHandlers>
</service>

Bindings

You may want to configure bindings for your service to allow it to talk on other transports. By default, the ObjectServiceFactory (and AnnotationServiceFactory) create a SOAP 1.1 HTTP binding. <createDefaultBindings> will suppress the creation of the default bindings if set to "false", and is "true" by default.

<createDefaultBindings>false</createDefaultBindings>

On a binding you specify a transport. This is the ID of the transport you want to reference. For instance:

Transport Transport ID
HTTP + SOAP 1.1 http://schemas.xmlsoap.org/soap/http
HTTP + SOAP 1.2 http://www.w3.org/2003/05/soap/bindings/HTTP/
XMPP http://jabber.org/protocol/soap
JMS urn:xfire:transport:jms
Local urn:xfire:transport:local

On bindings you can also specify endpoints which you listen on. XFire will then look at the incoming message's URI then map the service to that request if it matches.

So lets combine everything and create a JMS transport for SOAP 1.1:

<bindings xmlns:e="urn:echo">
<soap11Binding name="e:EchoJMSBinding" transport="urn:xfire:transport:jms">
<endpoints>
<endpoint name="e:EchoJMSEndpoint" url="jms://Echo" />
</endpoints>
</soap11Binding>
</bindings>

Using the endpoint syntax allows us to override the default URL resolution. However only certain transports like HTTP have their own service resolution method, whereby services names are extracted in a URL Transports like JMS however do not have that capability.

Here is a SOAP 1.2 endpoint for http which just uses the default service resolution:

<bindings xmlns:e="urn:echo">
<soap12Binding name="e:EchoSoap12Binding"
transport="http://www.w3.org/2003/05/soap/bindings/HTTP/" allowUndefinedEndpoints="true"/>
</bindings>

Service Properties

Name Type Default Description
wsdlBuilder.generateImports String false Specifies whether or not the WSDLBuilder should generate imports for all the schemas in your WSDL. Necessary with some tools.
wsdlBuilder.cleanImports String true Specifies whether or not the WSDLBuilder should remove the schemaLocations from schemas which are added to the WSDLBuilder.
wsdlBuilder.removeAllImports String false Specifies whether or not the WSDLBuilder should remove all the imports from the schemas. This turns both the import generation and cleaning off.

Using spring beans

 Because all XFire configuration tags uses "http://xfire.codehaus.org/config/1.0" namespace, to use "plain" spring tag you must set its namespace to empty value  xmlns="". For example :

 <inHandlers>  <!--Xfire configuration tag -->

      <handler handlerClass="org.codehaus.xfire.util.dom.DOMInHandler" /> <!-- Xfire configuration tag -->

      <bean class="org.codehaus.xfire.security.wss4j.WSS4JInHandler" xmlns=""> <!-- spring tag -->

     ...

  </bean>

</inHandlers>

 

Spring 2.x support

 Because of Spring 2.x new feature, services.xml default namespace must not be declared on the root element of configuration ( beans ) and need to be moved to <service> tag level.

<beans>
<service xmlns="http://xfire.codehaus.org/config/1.0">
<name/>
<namespace/>
...
...
</service>
</beans>
posted on 2007-06-08 19:22 java_tju 阅读(319) 评论(0)  编辑  收藏

只有注册用户登录后才能发表评论。


网站导航: