You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by robert <ro...@gmail.com> on 2006/02/13 16:36:13 UTC
Re: Is it possible to add a new method?
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
--
Re: Is it possible to add a new method?
Posted by Joel Rosi-Schwartz <Jo...@Etish.org>.
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:
>>>
>>>
>>>>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
>>>>
>>>>
>
>
>
Re: Is it possible to add a new method?
Posted by robert <ro...@gmail.com>.
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
--
Re: Is it possible to add a new method?
Posted by Joel Rosi-Schwartz <Jo...@Etish.org>.
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
>>
>>
>
>
>