XFire

Home
Bug/Issue Reporting
Download
FAQ
Get Involved
License
News
Stack Comparison
Support
User's Guide
XFire Team

M5

Javadocs
Reports

M6-SNAPSHOT

Javadocs
Reports

Developers

Developer Space
CVS
Building
Architecture
Interesting Projects
Release Process

Hopefully this can be a space to share some ideas and get a feel for whats going on in the current CVS. Its not going to necessarily be easy, but I want to do it RIGHT.

History

ClientHandler/HttpClient

The ClientHandler, AbstractClientHandler, AbstractHttpClient, etc were the first stab at the client. It allows very raw access to the StAX stream. The only binding that interacted with it was XMLBeans. xfire-xmlbeans also has some classes in the generator package which generate a client class which uses the SoapHttpClient to interact with services.

The sucky things about this is:

  • Its real hard to create a client from an existing service. (see proxy use case)
  • It doesn't use the XFire Transport layer

Ralf's Dynamic Client

JIRA issue: http://jira.codehaus.org/browse/XFIRE-56
My comments: http://jira.codehaus.org/secure/ViewProfile.jspa?name=dandiep

Sample Usage without exceptions:

EchoInterface service = (EchoInterface) SoapInvocatorFactory.createStub(EchoInterface.class);
String echo = service.echo("hello");
assertEquals(echo,"hello");

Sample Usage with exceptions <internal exception are thrown as SoapExceptions if wanted>:

IBadService service = (IBadService) SoapInvocatorFactory.createStub(IBadService.class);
try {
  service.badMethod();            
}
catch(MyException e){
  assertEquals(e.getMessage(),"bad bad");
}

The config file <xfire-soapclient.xml>:

<?xml version="1.0" encoding="UTF-8"?>
<config>
    <!-- base url -->
    <entry name="baseURL" value="http://127.0.0.1:8080/XFireTest/services/"/>
    <!-- should internal exceptions be thrown or not (default: false) -->
    <entry name="throwInternalExceptions" value="true"/>
    <node name="http">
        <!-- http 1.0 or 1.1 -->
        <entry name="protocol" value="1.1"/>
        <!--  timeout in ms -->
        <entry name="timeout" value="1000"/>
        <!-- content charset (UTF-8)-->
        <entry name="content-charset" value="UTF-8"/>
    </node>
    <node name="services">
        <node name="org.codehaus.xfire.demo.java.EchoInterface">
            <entry name="serviceName" value="Echo"/>
            <entry name="urn" value="urn:Echo"/>
            <entry name="soapVersion" value="1.2"/>
        </node>
    </node>
</node>

The (current) Restrictions:

  • Service must implement a interface, because java reflection proxy throw otherwise nullpointer exception
  • works with aegis style services (pojo impl + interface)

The good:

  • Client need only the service interface,the client api and his dependent apis (stax,yom)
  • no stub generation needed

org.codehaus.xfire.client.Client

This class is meant to be the next version of the client stuff. The Good:

  • Uses XFire Transports
  • Allows In/Out/Fault Handlers

The bad:

  • It requires you to use the XFire Service. I.e. you need to go through and use an ObjectServiceFactory to create the service and the ServiceInfo model. People find this confusing so we either need to simplify this or find another way.

Things can be proxied right now:

Service service = ...;
XFireProxyFactory factory = new XFireProxyFactory();
MyServiceIntf client = (MyServiceIntf) factory.create(service, String url);

Uses Cases

1. Proxy an XFire Service

Say I have all the service classes on the classpath. I should be able to do something like:

XFireProxyFactory factory = new XFireProxyFactory();
MyServiceIntf client = (MyServiceIntf) factory.create(MyServiceIntf.class, String url);

client.doFoo(...);

The Spring remoting use case falls under here too. The unit tests show that this type of thing is possible, but it requires a ServiceBean to be set up.

2. Create a client From WSDL

We should be able to take a WSDL, generate a client and then the binding should be able to generate the POJOs. We could possibly leverage the Axis WSDL2Java code. Or a multitude of others.

3. Dynamic Client

I'm not sure I understand how this differes from use case #1. Ralf, can you ellaborate?

Design

Service Model

It should be possible to interrogate a WSDL and build up a ServiceInfo model, which will provide metadata about a service.

Transport Layer

The client should use the Transport layer defined by XFire. Granted some changes need to be need. If you see any flaws, bring them up and we'll correct them.

Bindings

Ideally the client should work with all the bindings.

Tasks?

  • Code which looks at the wsdl and does schema->code generation for a particular binding. This would just be a thin wrapper around JAXB, XmlBeans, etc.
  • WSDL->Service interface class which contains the operations on the service. Would utilize the DTOs built above.
  • Investigate ways to do the above better. I'm sure people have better ideas than mine

?

What does everyone else think????