### 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????