Thanks for the info. I guess I am used to the RPC style web services model. With axis1 the plan was to expose a specific API for web services. The internal object model of the application would not be exposed directly. Rather a well thought out API would be constructed. Then that API would be made available as Web Services. The client would have an API to work with rather than working with documents. This would seem to minimize the amount of code an end user would have to write to consume the web service.
Sending documents across doesn't seem to be much more convenient that just documenting a particular soap messaging scheme and letting the end user use soap directly. The only major benefit seems like they get a WSDL that they can use to create a set of object to manipulate the soap message according to a schema. However, they still are just configuring the soap message. I realize the same thing happens in the RPC style web services, but the with RPC the client has a nicer API (IMO) that they can immediately understand.
I could certainly write a set of classes that would wrap the code generated by Axis2, but then I would have to do that ahead of time and ship that with the system providing the web services. That would seem to defeat the benefit of all of those WSDL to source code generation utilities built into popular IDE's. I can I manually create a WSDL that will achieve what I want and that will work with Axis2? Thanks.
Michael MacFadden
Tomax Corp - http://www.tomax.com
[EMAIL PROTECTED]
| The views, opinions, and judgments expressed in this message are solely those of the author. The message contents have not been reviewed or approved by Tomax Corporation . |
Anne Wrote:
First -- a comment about document-oriented systems versus object-oriented systems. In SOA, it's generally considered a good idea to expose coarse-grained interfaces rather than fine-grained interfaces. Your goal is not to expose an object, but to expose a service. In other words, your service interface should not expose getter and setter methods for each attribute in your object structure.
Second -- Axis2 does not currently support the "wrapped" convention -- i.e., constructing a wrapper element for your method parameters (the element name being the same as the operation name) and automatically unwrapping that element for the application. Therefroe your application must do the unwrapping itself.
If you use java2wsdl, Axis2 will generate in input message element that has the same name as the operation, which is defined as a sequence of your input parameters, and an output message element called <operation-name>Response. If you don't like this mnamign convention, you can hand-craft your own WSDL and generate your Java code from it.
Anne
