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: > >>Hi, > >> > >>It is my understanding that it should be possible to add a new operation > >>to a Web Service and still connect to it from old clients. The books and > >>articles I have read imply this, but in practice I have not been able to > >>accomplish it. > >> > >>What I have are a set of EJB Service beans. I generate the WSDL using > >>axis Java2WSDL. I deploy the WSEndPoints on my client and I use the > >>following code to access the proxy: > >> > >> ServiceFactory factory = ServiceFactory.newInstance(); > >> Service service = factory.createService(url, qname); > >> ServerWSEndPoint endpoint = (ServerWSEndPoint) > >> service.getPort(ServerWSEndPoint.class); > >> > >>This works fine. Now when I add a new method to the ServerWSBean and > >>redeploy to the server but not the client I get an exception: > >> > >> javax.xml.rpc.ServiceException: Incompatible service endpoint > >> interface: com.etish.useme.est.webservices.ServerWSEndPoint > >> > >>Which is understandable since the server and client have different > >>versions of the ServerWSEndPoint class. > >> > >>I figure that I a missing a piece of the puzzle. I would appreciate any > >>suggestions or pointers to a reference that actually explains what I > >>need to know. > >> > >>Thanks, > >>Joel --
