Hello,
I need a piece of help or advice for Client Side developping.

Given this Client part of the released example, BookService :
    public void testClient() throws Exception
    {
        Service serviceModel = 
getXFire().getServiceRegistry().getService("BookService");
        XFireProxyFactory serviceFactory = new XFireProxyFactory(getXFire());

        // Connect to web service.
        BookService service = (BookService) serviceFactory.create(serviceModel, 
"xfire.local://BookService");
        assertNotNull(service);

        // Call web service.
        Book[] books = service.getBooks();
        assertNotNull(books);
    }

You observe that, on the client side, once you have the Service interface and 
the dataObject classes (of the Service
methods signature), you can consume a remote service without a single generated 
line or any pre-wrote configuration
file.
As a matter of fact, those simple elements are deductible from the WSDL schema 
types and service description.

And so is my question :
If it is that simple on the client side, why isn't it as much simple to 
retrieve the necessary classes on the client
side ?
I mean, I can't figure out why XFire project doesn't provide a simple class 
generator which get me these three elements,
an Interface and two dataObjects (argument/return) with their 
attributes/getter/setter from the WSDL.
Those are the only things Aegis needs on the client side, and they're right in 
the WSDL.

Actually, the class generator for Axis, WSDL2Java, almost does the job. 
Signature data Objects are very clean. And by
default, the package are named from the WSDL Namespaces, which is just the way 
Aegis needs them.
So We're thinking about post-process the generated classes, deleting the axis 
binding code (the Interface will still
need a bit of hand coding). But it's quite long to developp such a tool and 
above all to fully assure its reliability.

Indeed, our architecture is, for the moment, stuck with JDK 1.4.2. (XFire 
generator unusable for us)
The WSDL is the only way java developpers will consume the services (no UDDI).

So, for all our users (both service developpers and client developpers), we 
find very clean and handy the way Aegis does
the job without any kind of binding. And very frustrating not to be able to 
parse simple class definitions from wsdl
schema types.


Thank you a lot for helping.

Best regards.
Brieuc Le Marec


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply via email to