Generic WebService Client

[Anubhav Anand]

I am new to webservices. Use apche Axis2, Tomcat and eclipse europa for webservice development.

Is it possible to make a web service client that can interact with any kind of web service. What I mean is that : can I have a generic client that can read any wsdl and provide appropriate results for that web service. Kind of some SOAP message reader that can handle all wsdl's and generate appropriate output for the service it is interacting with.

Thanks in advance.

[Ulf Dittmer]

That depends on what you mean by "results" and "output".

You can certainly write such a WS client that does appropriate type checking for the request parameters etc., but what would be its use? Its API would be rather cumbersome to use, compared to classes that have descriptive method names that correspond to the request parameters and response items, whatever those are.

[Anubhav Anand]

Actually my application has to get data from a few resources e.g. a SAP Database, XML database and a few others.

Now all these resources(SAP - XML) have web services to get data from their respective databases.

I want to make a single client that will interact with all webservices and provide me data( e.g. SAP webservice will give me data in flat file from SAP DB, XML webservice will give me a XML file from XML DB).

Basically, a generic web service client that can interact with any web service (WSDL ) and fetch the respective data.

[Ulf Dittmer]

Its genericity will be limited, since each of these takes different parameters and returns different results. They may even have different binding styles. My hunch would be that it's easier to keep separate specific client classes.

[Anubhav Anand]

Yes, I agree.
But, someone suggested that one can get the SOAP messages from WSDL and then can implement a generic client which can handle SOAP messages.

I don't have much idea about it.
Any suggestions will be helpful.

BTW, thanks for your early response.

[Peer Reynders]

Originally posted by Anubhav Anand:
But, someone suggested that one can get the SOAP messages from WSDL and then can implement a generic client which can handle SOAP messages.

Well - think it through for a moment. Web service testing tools are usually such clients - they get some of their information from the WSDL. However they still need to be supplied with the data that fits the request and the data that is returned depends on the structure of the response (the structure of the data is information too). That means that whatever is providing the information for the requests and consumes the information from the responses now has to know about that structure - ultimately coupling it to that specific service.

The only sane thing to do in your case is to develop an adapter service. First you have to look all the request and response pairs that you have to unify and come up with a unified request/response format. Your adapter service is then responsible converting the unified request to the specific request format which it then sends to the ultimate destination; then it converts the specific response to the unified response and returns it to the original sender. That way you have one unified client that only has to change when the unified format changes. You should also be able to add new web services to the adapter service without affecting existing clients and to some degree accommodate changes in existing web services that can be localized to the adapter service.

Now given that your target web services seem to act like databases it would make sense if your unified request is a "query request" format which also identifies the data source. The unified response would be a "result set" response.

Sounds like you are reinventing JDBC? Now you get the idea. Also note that dependencies/coupling between the "data source" and the ultimate consumer still remain. The ultimate consumer will still have to know the "table" and "column" names used by the "datasource". Unless of course you have the adapter service translate those too.

There is a real risk that the process of data harmonization will destroy many of the advantages that you can derive from SOAP web services. If you are adapting too broad a spectrum of web services your harmonized format will quickly degenerate into a key-value list similar to Java property lists that will be a pain to work with in all but the most simple scenarios.

Typically adapter services use XSLT to transform the requests and responses.

See Integrating Services with XSLT, XSLT in Java, Processing XML with Java: Chapter 17. XSLT
[ February 28, 2008: Message edited by: Peer Reynders ]

[Anubhav Anand]

Thanks Peer for you input. Will look into the feasiblities.

Thanks a ton.