One of the reasons standards exist is to avoid vendor lock-in. It is a good architecture goal to avoid vendor lock-in and write code to the specs/standard apis.
Lets say you didnt know about axis and you implemented a bunch of web services in Java using some other SAAJ/JAX-RPC implementation. A friend makes you aware of axis and tells you its the best Java based SOAP engine out there. Wouldnt it be nice to be able to switch to Axis without a huge amount of work (ie without changing a lot of your code) because both the original SOAP engine you were using and Axis implement the SAAJ/JAX-RPC specs. It doesnt seem to me that web services are quite at this level of maturity but that should be the goal. -----Original Message----- From: Thompson, Eugene [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 7:38 AM To: '[EMAIL PROTECTED]' Subject: RE: How to define document/literal service with multiple operations > Also, I'd like to keep my web services portable to different JAX-RPC > implementations, so I try to avoid Axis-specific features > (e.g., Message-style > services.) > Just curious, but why? Are you constructing a service that you are planning to sell or that will need to be installed in many different JAXRPC implementations? Or have you (your company) not decided upon an implementation yet? As I've said before, I'm new to webservices, but I am under the impression that they are simply a deployment tool; an interface to the "real" code. If that's the case, why not use whatever is specific to the implementation if it makes it easier/better to deploy (and is, of course, standard)? It's not going to change the functionality of the service. Or (having an epiphany), is it that using implementation specific functionality can have a negative affect on the implementors of the service's clients? If that's the case, then I understand the reluctance. I'm sure interested in your (and anyone else's) thoughts on this. Gene
