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:

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

The config file <xfire-soapclient.xml>:

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:

1. Proxy an XFire Service

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

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?

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.