|
Number one is exactly what I wish to avoid in this situation. Number 2
is what I am endeavoring to do, but with no success to date. I have
considered a new endpoint, but that is my fall back position if I can
not get this to work as advertised. I appreciate what you have said
about the "separation of concerns", however that will eventually lead
to a undesirable fragmentation of a rather nicely partitioned
separation of responsibilities. Right now I have seven services
(endpoints) each of which is responsible for providing a cohesive set
of functionality. But as my system grows in capability I will be adding
new functionality that will frequently fall into these same spheres of
interest. I would prefer not to introduce new endpoints simply to
manage versioning. I am in contact with the two IBM authors now. I have taken the liberty of including you in the thread as you appear to have an interest and something worthwhile to add to the conversation. Please let me know if you would prefer for me to take you off at any time. Thanks for you thought they are truly appreciated. Cheers, Joel robert wrote: The article you quote is right, but I think I can sum up the issue in fewer words:1) If you make changes to the wsdl, and you want the clients of the services defined to be able to use those changes, they need to -re-generate their source files based on the new wsdl - ie create a new jar. 2) If you add new methods to the wsdl and you don't want the client to be aware of them, I suppose you could continue without syncing with the client. My advice on number two is, why not just generate a new endpoint for the other functionality? Just create another aar. That way you have a separation of concerns that don't mesh together. Just my .02 cents. HTH, Robert http://www.braziloutsource.com/ Em Terça 14 Fevereiro 2006 10:36, o Joel Rosi-Schwartz escreveu:Okay, I take on board your advice, but I think that it begs my initial question. In your point 2 you state /"Use the same jar on the server and the client."/ My quest, however, is to be able to add additional functionality to the service, i.e. new operations, and not have to force every client in the field to upgrade in unison. This is the proverbial problem with distributed systems and I had hoped that Web Services solved it in cases where there were only additions to functionality. In the IBM article /"Best practices for Web services versioning"/, http://www-128.ibm.com/developerworks/webservices/library/ws-version/, it rather clearly states: /Roughly speaking, there are two types of changes in a WSDL document that cannot break an existing requestor, and several types of changes that can. In accordance with standard industry nomenclature, we will call these backwards-compatible and non-backwards-compatible changes, respectively. The types of changes that are backwards compatible are: / / * Addition of new WSDL operations to an existing WSDL document. If existing requestors are unaware of a new operation, then they will be unaffected by its introduction. * Addition of new XML schema types within a WSDL document that are not contained within previously existing types. Again, even if a new operation requires a new set of complex data types, as long as those data types are not contained within any previously existing types (which would in turn require modification of the parsing code for those types), then this type of change will not affect an existing requestor./ So how does one actually accomplish this or am I misreading the intent. Thanks, Joel robert wrote:Combining EJB with axis 1.x requires integration with the app server. I've done it a lot with jboss, which uses axis internally. Basically there's a lot of files to edit. My advice: 1) Work with wsdl2java instead of java2wsdl. Just create your endpoint like: YourImpl implements SessionBean, EJB_Context Then implement your endpoint methods that match your wsdl2java generated methods and classes. 2) Create a jar with your wsdl2java generated classes and use that to create your references. Use the same jar on the server and the client. That's the basics. Beyond that, its all about the configuration, unfortunately different on every app server. In the long run you can use spring to solve that somewhat. HTH, Robert http://www.braziloutsource.com/ Em Segunda 13 Fevereiro 2006 14:04, o Joel Rosi-Schwartz escreveu: |
