Calling SOAP Services via Axis1/2 from within OSGi bundle

[Christopher Blunck-2]

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

[dkulp]

CXF is COMPLETELY separate from Axis and Axis2.   While Axis2 and CXF share
some libraries (like wss4j, neethi, etc..), the underlying SOAP processing are
completely different code bases.

I PERSONALLY recommend migrating the applications to CXF, but I can definitely
understand why that's not an option.   But you would need to post this to the
Axis2 lists.    The WSO2 folks could probably help you as they've done a lot
of osgi stuff with Axis2 for their products.

Dan


On Thu November 5 2009 3:36:51 pm Chris Blunck wrote:

> 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
>

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

[Christopher Blunck-2]

Thanks for the followup, Dan.  I'll look within the Axis community for  
answers.

I posted to CXF because of the "Distributed OSGi" feature.  Can anyone  
confirm that the "Distributed OSGi" feature relies on Axis/Axis2 under  
the covers to provide SOAP messaging between separate OSGi containers  
and the services deployed within them?  If so then that gives me hope  
that using Axis/Axis2 from within OSGi is technically possible and it  
also tells me that I can look at CXF as a possible example on how to  
accomplish it...


-c

On Nov 5, 2009, at 9:15 PM, Daniel Kulp wrote:

>
> CXF is COMPLETELY separate from Axis and Axis2.   While Axis2 and  
> CXF share
> some libraries (like wss4j, neethi, etc..), the underlying SOAP  
> processing are
> completely different code bases.
>
> I PERSONALLY recommend migrating the applications to CXF, but I can  
> definitely
> understand why that's not an option.   But you would need to post  
> this to the
> Axis2 lists.    The WSO2 folks could probably help you as they've  
> done a lot
> of osgi stuff with Axis2 for their products.
>
> Dan
>
>
> On Thu November 5 2009 3:36:51 pm Chris Blunck wrote:
>> 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
>>
>
> --
> Daniel Kulp
> dkulp@...
> http://www.dankulp.com/blog

[dkulp]

On Thu November 5 2009 9:21:18 pm Christopher Blunck wrote:

> Thanks for the followup, Dan.  I'll look within the Axis community for
> answers.
>
> I posted to CXF because of the "Distributed OSGi" feature.  Can anyone
> confirm that the "Distributed OSGi" feature relies on Axis/Axis2 under
> the covers to provide SOAP messaging between separate OSGi containers
> and the services deployed within them?  If so then that gives me hope
> that using Axis/Axis2 from within OSGi is technically possible and it
> also tells me that I can look at CXF as a possible example on how to
> accomplish it...

No, the Distributed OSGi feature relies on CXF under the covers to provide
SOAP messaging between  separate OSGi containers and the services deployed
within them.   :-)   No Axis2 involved.

Dan

>
>
> -c
>
> On Nov 5, 2009, at 9:15 PM, Daniel Kulp wrote:
> > CXF is COMPLETELY separate from Axis and Axis2.   While Axis2 and
> > CXF share
> > some libraries (like wss4j, neethi, etc..), the underlying SOAP
> > processing are
> > completely different code bases.
> >
> > I PERSONALLY recommend migrating the applications to CXF, but I can
> > definitely
> > understand why that's not an option.   But you would need to post
> > this to the
> > Axis2 lists.    The WSO2 folks could probably help you as they've
> > done a lot
> > of osgi stuff with Axis2 for their products.
> >
> > Dan
> >
> > On Thu November 5 2009 3:36:51 pm Chris Blunck wrote:
> >> 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
>

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

[Christopher Blunck-2]

Gotcha.  Thanks for the clarification.  I'll go check out the Axis-
Users lists.


-c

On Nov 5, 2009, at 9:27 PM, Daniel Kulp wrote:

> On Thu November 5 2009 9:21:18 pm Christopher Blunck wrote:
>> Thanks for the followup, Dan.  I'll look within the Axis community  
>> for
>> answers.
>>
>> I posted to CXF because of the "Distributed OSGi" feature.  Can  
>> anyone
>> confirm that the "Distributed OSGi" feature relies on Axis/Axis2  
>> under
>> the covers to provide SOAP messaging between separate OSGi containers
>> and the services deployed within them?  If so then that gives me hope
>> that using Axis/Axis2 from within OSGi is technically possible and it
>> also tells me that I can look at CXF as a possible example on how to
>> accomplish it...
>
> No, the Distributed OSGi feature relies on CXF under the covers to  
> provide
> SOAP messaging between  separate OSGi containers and the services  
> deployed
> within them.   :-)   No Axis2 involved.
>
> Dan
>
>>
>>
>> -c
>>
>> On Nov 5, 2009, at 9:15 PM, Daniel Kulp wrote:
>>> CXF is COMPLETELY separate from Axis and Axis2.   While Axis2 and
>>> CXF share
>>> some libraries (like wss4j, neethi, etc..), the underlying SOAP
>>> processing are
>>> completely different code bases.
>>>
>>> I PERSONALLY recommend migrating the applications to CXF, but I can
>>> definitely
>>> understand why that's not an option.   But you would need to post
>>> this to the
>>> Axis2 lists.    The WSO2 folks could probably help you as they've
>>> done a lot
>>> of osgi stuff with Axis2 for their products.
>>>
>>> Dan
>>>
>>> On Thu November 5 2009 3:36:51 pm Chris Blunck wrote:
>>>> 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
>>
>
> --
> Daniel Kulp
> dkulp@...
> http://www.dankulp.com/blog

[Kessel, Christopher]

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

[Purohit, Manoj R]

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@...]
Sent: Monday, November 09, 2009 12:41 PM
To: users@...
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

[Rao, Sameer V]

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@...]
Sent: Monday, November 09, 2009 11:41 AM
To: users@...
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

[Kessel, Christopher]

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@...]
Sent: Monday, November 09, 2009 12:09 PM
To: users@...
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@...]
Sent: Monday, November 09, 2009 11:41 AM
To: users@...
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

[Rao, Sameer V]

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@...]
Sent: Monday, November 09, 2009 2:52 PM
To: users@...
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@...]
Sent: Monday, November 09, 2009 12:09 PM
To: users@...
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@...]
Sent: Monday, November 09, 2009 11:41 AM
To: users@...
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