You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Chris Blunck <ch...@thebluncks.com> on 2009/11/05 21:36:51 UTC
Calling SOAP Services via Axis1/2 from within OSGi bundle
Hello-
I have some code that relies on an Axis generated client to call a SOAP web
service. I'm interested in migrating that client to an OSGi bundle. I
thought this would be a pretty trivial process but I've become entangled in
OSGi's dependency management and packages.
I'm working with Felix 2.0.1 and Axis2 (although this happens with Axis1 as
well).
I'm posing this question to the CXF community because the "Distributed OSGi"
section of the CXF website advertises:
It implements RFC 119 using Web Services, leveraging SOAP over HTTP and
exposing the Service over a WSDL contract. Starting from 1.1-SNAPSHOT, Java
interfaces can also be exposed and consumed as RESTful JAX-RS services.
>From my preliminary reading it appears as though CXF allows services to call
one another using SOAP as a transport. Given how embedded Axis is with the
rest of the CXF project my instinct tells me that the Distributed OSGi folks
have used Axis as their SOAP client and server implementation.
The problems I've hit with Axis and Felix is that I can't bundle up all the
dependent JARs and put together an Import-Package statement that will
actually work and allow the client classes in my bundle to use Axis
properly.
Given that the CXF folks have presumably done this I'm very interested in
understanding their approach and how they accomplished rolling up Axis into
an OSGi bundle that can be used from within Felix.
PS - I'm using Maven (including the bundle plugin, which just calls bnd).
My apologies if this was sent to the incorrect list.
-c
RE: Pointer to a strategy on interface versioning?
Posted by "Rao, Sameer V" <SR...@amfam.com>.
Chris,
You could still implement common endpoint pretty much the "XML
Interface way" that you just explained.
<quote>
For our XML interface, we actually look up a "version" field up front
with XPath
and then shunt the Document off to the correct handler for the version,
which means every client of every version comes through the same URL.
<unquote>
If I understand the above, you are providing a POX (Plain old XML)
service (i.e. endpoint accepting any XML payload - not necessarily
wrapped inside SOAP envelope), and then are applying router logic to
route-to (i.e. invoke) the correct service interface (based on the
version). In this case you are not "binding" your XML data to any
POJO/Java structure until it reaches the final (correct version)
endpoint.
If you go vanilla approach of JAX-WS/JAXB binding then you are asking
CXF/stack to 'binding' the XML to an object model before it comes to you
interface and hence it gets tricky.
However, You can still do it XML/XPath (lookup to determine which
interface to invoke) with CXF by using Provider API (which gives you
access to the direct payload and then you proceed to interrogate the
version and route to the correct interface).
-----Original Message-----
From: Kessel, Christopher [mailto:ckessel@transunion.com]
Sent: Monday, November 09, 2009 2:52 PM
To: users@cxf.apache.org
Subject: RE: Pointer to a strategy on interface versioning?
I appreciate the help from you an Manoj. I'm used to straight XML
interfaces, but new to SOAP more or less and indeed I think I'm going to
have to separate Endpoints at slightly different URL locations. For our
XML interface, we actually look up a "version" field up front with XPath
and then shunt the Document off to the correct handler for the version,
which means every client of every version comes through the same URL.
That's why I asked about having different versions come through the same
URL for SOAP (with CXF). It looks like that'll be problematic though, so
I'll go the route of a http://host/v11 and http://host/v10 type scheme.
Not a big deal, though I'll have to distill the "why" into layman speak
when I get asked why it differs from how we expose our XML interface :)
Thanks,
Chris
-----Original Message-----
From: Rao, Sameer V [mailto:SRAO@amfam.com]
Sent: Monday, November 09, 2009 12:09 PM
To: users@cxf.apache.org
Subject: RE: Pointer to a strategy on interface versioning?
Hi Chris,
>> The problem is, how do I support both the v1.0 and v1.1 interfaces at
the same endpoint?
Since data structures (XSD elements) are backwards compatible, how are
you differentiating between these two version? Rather do you want to
differentiate between your 1.0 consumer and 1.1 consumer? If not then
the 1.1 WebService interface & JAXB objects should suffice all your
consumer. However, if you still want to return limited data (i.e. 1.0
data) to 1.0 version consumer then its best to have a separate endpoint
within the same WAR and support the versions.
If it's ok for all your consumer (1.0 and 1.1) to get the 1.1 data then
just have one interface. There might not be special multi-version
support in your case. Would this meet you needs?
Cheers!
Sameer
-----Original Message-----
From: Kessel, Christopher [mailto:ckessel@transunion.com]
Sent: Monday, November 09, 2009 11:41 AM
To: users@cxf.apache.org
Subject: Pointer to a strategy on interface versioning?
Is there documentation available on good strategies for versioning an
endpoint published via CXF? We've got version 1.0 and are rolling a v1.1
that has a slightly enhanced version of the previous interface. The
input/output objects have been updated, but backwards compatible with
the v1.0 defined interface.
The problem is, how do I support both the v1.0 and v1.1 interfaces at
the same endpoint? Well, let me rephrase that, I want to keep the same
URL for customers to send their SOAP requests through whether they're
v1.0 or v1.1 customers. Essentially, this should be an invisible change
to v1.0 customers since our implementation objects are backwards
compatible. v1.1 customers would get an updated WSDL that shows the new
fields available in the v1.1 input/output.
Does that description make any sense? Is it possible or will I need to
publish a new URL for v1.1 customers?
Thanks,
Chris
RE: Pointer to a strategy on interface versioning?
Posted by "Kessel, Christopher" <ck...@transunion.com>.
I appreciate the help from you an Manoj. I'm used to straight XML
interfaces, but new to SOAP more or less and indeed I think I'm going to
have to separate Endpoints at slightly different URL locations. For our
XML interface, we actually look up a "version" field up front with XPath
and then shunt the Document off to the correct handler for the version,
which means every client of every version comes through the same URL.
That's why I asked about having different versions come through the same
URL for SOAP (with CXF). It looks like that'll be problematic though, so
I'll go the route of a http://host/v11 and http://host/v10 type scheme.
Not a big deal, though I'll have to distill the "why" into layman speak
when I get asked why it differs from how we expose our XML interface :)
Thanks,
Chris
-----Original Message-----
From: Rao, Sameer V [mailto:SRAO@amfam.com]
Sent: Monday, November 09, 2009 12:09 PM
To: users@cxf.apache.org
Subject: RE: Pointer to a strategy on interface versioning?
Hi Chris,
>> The problem is, how do I support both the v1.0 and v1.1 interfaces at
the same endpoint?
Since data structures (XSD elements) are backwards compatible, how are
you differentiating between these two version? Rather do you want to
differentiate between your 1.0 consumer and 1.1 consumer? If not then
the 1.1 WebService interface & JAXB objects should suffice all your
consumer. However, if you still want to return limited data (i.e. 1.0
data) to 1.0 version consumer then its best to have a separate endpoint
within the same WAR and support the versions.
If it's ok for all your consumer (1.0 and 1.1) to get the 1.1 data then
just have one interface. There might not be special multi-version
support in your case. Would this meet you needs?
Cheers!
Sameer
-----Original Message-----
From: Kessel, Christopher [mailto:ckessel@transunion.com]
Sent: Monday, November 09, 2009 11:41 AM
To: users@cxf.apache.org
Subject: Pointer to a strategy on interface versioning?
Is there documentation available on good strategies for versioning an
endpoint published via CXF? We've got version 1.0 and are rolling a v1.1
that has a slightly enhanced version of the previous interface. The
input/output objects have been updated, but backwards compatible with
the v1.0 defined interface.
The problem is, how do I support both the v1.0 and v1.1 interfaces at
the same endpoint? Well, let me rephrase that, I want to keep the same
URL for customers to send their SOAP requests through whether they're
v1.0 or v1.1 customers. Essentially, this should be an invisible change
to v1.0 customers since our implementation objects are backwards
compatible. v1.1 customers would get an updated WSDL that shows the new
fields available in the v1.1 input/output.
Does that description make any sense? Is it possible or will I need to
publish a new URL for v1.1 customers?
Thanks,
Chris
RE: Pointer to a strategy on interface versioning?
Posted by "Rao, Sameer V" <SR...@amfam.com>.
Hi Chris,
>> The problem is, how do I support both the v1.0 and v1.1 interfaces at
the same endpoint?
Since data structures (XSD elements) are backwards compatible, how are
you differentiating between these two version? Rather do you want to
differentiate between your 1.0 consumer and 1.1 consumer? If not then
the 1.1 WebService interface & JAXB objects should suffice all your
consumer. However, if you still want to return limited data (i.e. 1.0
data) to 1.0 version consumer then its best to have a separate endpoint
within the same WAR and support the versions.
If it's ok for all your consumer (1.0 and 1.1) to get the 1.1 data then
just have one interface. There might not be special multi-version
support in your case. Would this meet you needs?
Cheers!
Sameer
-----Original Message-----
From: Kessel, Christopher [mailto:ckessel@transunion.com]
Sent: Monday, November 09, 2009 11:41 AM
To: users@cxf.apache.org
Subject: Pointer to a strategy on interface versioning?
Is there documentation available on good strategies for versioning an
endpoint published via CXF? We've got version 1.0 and are rolling a v1.1
that has a slightly enhanced version of the previous interface. The
input/output objects have been updated, but backwards compatible with
the v1.0 defined interface.
The problem is, how do I support both the v1.0 and v1.1 interfaces at
the same endpoint? Well, let me rephrase that, I want to keep the same
URL for customers to send their SOAP requests through whether they're
v1.0 or v1.1 customers. Essentially, this should be an invisible change
to v1.0 customers since our implementation objects are backwards
compatible. v1.1 customers would get an updated WSDL that shows the new
fields available in the v1.1 input/output.
Does that description make any sense? Is it possible or will I need to
publish a new URL for v1.1 customers?
Thanks,
Chris
RE: Pointer to a strategy on interface versioning?
Posted by "Purohit, Manoj R " <ma...@citi.com>.
SOAPAction if you explore can help you.
For existing service SOAPAction="http://xxx.com/v10/ops" or ""
For new service SOAPAction=http://xxx.com/v11/ops
Now you may need some proxy service which can filter based on soapaction where to rout the message synchronously.
This proxy service can have same url as current.
This proxy service can be achieved by any modern open esb tool by just few configurations or you can write your own little filtering logic.
Existing client may hit with existing soapAction and new client will send with SOAPAction=http://xxx.com/v11/ops to same url.
Manoj
-----Original Message-----
From: Kessel, Christopher [mailto:ckessel@transunion.com]
Sent: Monday, November 09, 2009 12:41 PM
To: users@cxf.apache.org
Subject: Pointer to a strategy on interface versioning?
Is there documentation available on good strategies for versioning an
endpoint published via CXF? We've got version 1.0 and are rolling a v1.1
that has a slightly enhanced version of the previous interface. The
input/output objects have been updated, but backwards compatible with
the v1.0 defined interface.
The problem is, how do I support both the v1.0 and v1.1 interfaces at
the same endpoint? Well, let me rephrase that, I want to keep the same
URL for customers to send their SOAP requests through whether they're
v1.0 or v1.1 customers. Essentially, this should be an invisible change
to v1.0 customers since our implementation objects are backwards
compatible. v1.1 customers would get an updated WSDL that shows the new
fields available in the v1.1 input/output.
Does that description make any sense? Is it possible or will I need to
publish a new URL for v1.1 customers?
Thanks,
Chris
Pointer to a strategy on interface versioning?
Posted by "Kessel, Christopher" <ck...@transunion.com>.
Is there documentation available on good strategies for versioning an
endpoint published via CXF? We've got version 1.0 and are rolling a v1.1
that has a slightly enhanced version of the previous interface. The
input/output objects have been updated, but backwards compatible with
the v1.0 defined interface.
The problem is, how do I support both the v1.0 and v1.1 interfaces at
the same endpoint? Well, let me rephrase that, I want to keep the same
URL for customers to send their SOAP requests through whether they're
v1.0 or v1.1 customers. Essentially, this should be an invisible change
to v1.0 customers since our implementation objects are backwards
compatible. v1.1 customers would get an updated WSDL that shows the new
fields available in the v1.1 input/output.
Does that description make any sense? Is it possible or will I need to
publish a new URL for v1.1 customers?
Thanks,
Chris