XFireHome M5M6-SNAPSHOTDevelopersDeveloper Space |
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. HistoryClientHandler/HttpClientThe 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:
Ralf's Dynamic ClientJIRA issue: http://jira.codehaus.org/browse/XFIRE-56 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:
The good:
org.codehaus.xfire.client.ClientThis class is meant to be the next version of the client stuff. The Good:
The bad:
Things can be proxied right now: Service service = ...; XFireProxyFactory factory = new XFireProxyFactory(); MyServiceIntf client = (MyServiceIntf) factory.create(service, String url); Uses Cases1. Proxy an XFire ServiceSay 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 WSDLWe 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 ClientI'm not sure I understand how this differes from use case #1. Ralf, can you ellaborate? DesignService ModelIt should be possible to interrogate a WSDL and build up a ServiceInfo model, which will provide metadata about a service. Transport LayerThe 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. BindingsIdeally the client should work with all the bindings. Tasks?
?What does everyone else think???? |