You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2007/11/23 09:12:41 UTC

EJB and JAXWS support in ServiceMix 4.0

One of the thing I'd like to have before we release a milestone (this year
hopefully) is a way to simply expose web services or EJB3 in the ServiceMix
bus.
I've been working since ApacheCon on OpenEJB integration and I've committed
a bunch of things already, but this is not in a workable state yet.

Freeman is also working on integrating CXF for plain JAXWS support but there
will be some overlap there, so it may be better to think about a strategy
and avoid duplication and incompatibilities in these areas. I guess we need
to solve a few points:

   * do we want to be able to deploy web services if the EJB layer is not
installed: currently, the openejb integration registers a bundle listener to
detect annotated POJOs and deploy them, so that even if you want to deploy a
plain jaxws pojo (without any EJB annotations), you still need to go through
the ejb layer.  I don't see any problems with that for the moment, though I
suppose we may want to split that later

  * how to expose POJOs on the bus ?  This is not done yet for the openejb
layer, but my thinking is that we want to expose those beans by using camel
transports so that we only have to deal with those transports.  Currently
openejb registers an http servlet so we need to have the OSGi http service
(which comes from the pax project and uses jetty).
   We also need to define, where and how these POJOs are exposed on the
bus.  I suppose each POJOs would lead to a servicemix Endpoint being exposed
in the OSGi registry (which is the way to expose an endpoint in servicemix
40, but the quetion is: which protocol / data does the pojo expect ?
   I'm thinking we may want to do the same thing we do in JBI: split the
protocol (http+soap) from the pojo invocation, but this will require an xml
wrapper so that we can keep all the WSDL 1.1 message parts (we could just
reuse the JBI one ?).  Another thing is that the CXF camel component can
work in collaboration with the camel bean component by using a list of
unmarshalled parameters as the message payload. Can we use both approach at
the same time ?

  * We need to keep a way to configure things using spring so that you can
leverage CXF features such as WS-Security, WS-ReliableMessaging, etc...

The key point is to keep things easy to use, so we need to have both the
spring way of wiring things and be able to simply deploy a bundle which
contains an annotated POJO and everyhing would work.  We also want to
integrate cleanly with other JBI components and camel components.  Ideas
welcome.

-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

Re: EJB and JAXWS support in ServiceMix 4.0

Posted by James Strachan <ja...@gmail.com>.
On 23/11/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> Well, the main intersting thing about EJB is when working with the
> persistence part.
> The programming model is quite easy to use, so if people want to expose
> their services in ServiceMix, providing support for this programming model
> is imho an interesting thing.

Yeah; though we don't need openejb to be able to use JPA nicely -
Spring does a pretty good job of working with JPA. The main benefit of
openejb seems to be for doing stateful session beans and remoting
right?

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com

Re: EJB and JAXWS support in ServiceMix 4.0

Posted by Guillaume Nodet <gn...@gmail.com>.
Well, the main intersting thing about EJB is when working with the
persistence part.
The programming model is quite easy to use, so if people want to expose
their services in ServiceMix, providing support for this programming model
is imho an interesting thing.

On Nov 23, 2007 10:32 AM, James Strachan <ja...@gmail.com> wrote:

> On 23/11/2007, James Strachan <ja...@gmail.com> wrote:
> > On 23/11/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> > > One of the thing I'd like to have before we release a milestone (this
> year
> > > hopefully) is a way to simply expose web services or EJB3 in the
> ServiceMix
> > > bus.
> > > I've been working since ApacheCon on OpenEJB integration and I've
> committed
> > > a bunch of things already, but this is not in a workable state yet.
> > >
> > > Freeman is also working on integrating CXF for plain JAXWS support but
> there
> > > will be some overlap there, so it may be better to think about a
> strategy
> > > and avoid duplication and incompatibilities in these areas. I guess we
> need
> > > to solve a few points:
> > >
> > >    * do we want to be able to deploy web services if the EJB layer is
> not
> > > installed: currently, the openejb integration registers a bundle
> listener to
> > > detect annotated POJOs and deploy them, so that even if you want to
> deploy a
> > > plain jaxws pojo (without any EJB annotations), you still need to go
> through
> > > the ejb layer.  I don't see any problems with that for the moment,
> though I
> > > suppose we may want to split that later
> >
> > Maybe we need 2 listeners; one for EJB annotations, one for JAX-WS
> > annotations (with JAX-WS winning). Then you can avoid having to have
> > the EJB stuff there?
>
> I didn't explain that too well. I guess I'm keen for things to be
> modular - so folks could just use EJB or just use JAX-WS etc.
>
> Though I guess we should always support JAX-WS - I guess its just the
> EJB part could be optional. With Spring supporting the @Resource /
> @PostConstruct / @PreDestroy I can imagine folks using those
> annotations with JAX-WS and not needing the full EJB3 stuff often?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

Re: EJB and JAXWS support in ServiceMix 4.0

Posted by James Strachan <ja...@gmail.com>.
On 23/11/2007, James Strachan <ja...@gmail.com> wrote:
> On 23/11/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> > One of the thing I'd like to have before we release a milestone (this year
> > hopefully) is a way to simply expose web services or EJB3 in the ServiceMix
> > bus.
> > I've been working since ApacheCon on OpenEJB integration and I've committed
> > a bunch of things already, but this is not in a workable state yet.
> >
> > Freeman is also working on integrating CXF for plain JAXWS support but there
> > will be some overlap there, so it may be better to think about a strategy
> > and avoid duplication and incompatibilities in these areas. I guess we need
> > to solve a few points:
> >
> >    * do we want to be able to deploy web services if the EJB layer is not
> > installed: currently, the openejb integration registers a bundle listener to
> > detect annotated POJOs and deploy them, so that even if you want to deploy a
> > plain jaxws pojo (without any EJB annotations), you still need to go through
> > the ejb layer.  I don't see any problems with that for the moment, though I
> > suppose we may want to split that later
>
> Maybe we need 2 listeners; one for EJB annotations, one for JAX-WS
> annotations (with JAX-WS winning). Then you can avoid having to have
> the EJB stuff there?

I didn't explain that too well. I guess I'm keen for things to be
modular - so folks could just use EJB or just use JAX-WS etc.

Though I guess we should always support JAX-WS - I guess its just the
EJB part could be optional. With Spring supporting the @Resource /
@PostConstruct / @PreDestroy I can imagine folks using those
annotations with JAX-WS and not needing the full EJB3 stuff often?

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com

Re: EJB and JAXWS support in ServiceMix 4.0

Posted by Guillaume Nodet <gn...@gmail.com>.
On Nov 23, 2007 9:27 AM, James Strachan <ja...@gmail.com> wrote:

> On 23/11/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> > One of the thing I'd like to have before we release a milestone (this
> year
> > hopefully) is a way to simply expose web services or EJB3 in the
> ServiceMix
> > bus.
> > I've been working since ApacheCon on OpenEJB integration and I've
> committed
> > a bunch of things already, but this is not in a workable state yet.
> >
> > Freeman is also working on integrating CXF for plain JAXWS support but
> there
> > will be some overlap there, so it may be better to think about a
> strategy
> > and avoid duplication and incompatibilities in these areas. I guess we
> need
> > to solve a few points:
> >
> >    * do we want to be able to deploy web services if the EJB layer is
> not
> > installed: currently, the openejb integration registers a bundle
> listener to
> > detect annotated POJOs and deploy them, so that even if you want to
> deploy a
> > plain jaxws pojo (without any EJB annotations), you still need to go
> through
> > the ejb layer.  I don't see any problems with that for the moment,
> though I
> > suppose we may want to split that later
>
> Maybe we need 2 listeners; one for EJB annotations, one for JAX-WS
> annotations (with JAX-WS winning). Then you can avoid having to have
> the EJB stuff there?


Currently, the openejb deployer should be able to detect pure JAXWS pojo
without any EJB annotations and deploy those without problems.  My point was
rather if we want to make things modular and be able to use JAXWS (cxf)
without openejb jars at all, or if openejb would be a requirement even for
pure jaxws pojos.


>
>
>
> >   * how to expose POJOs on the bus ?  This is not done yet for the
> openejb
> > layer, but my thinking is that we want to expose those beans by using
> camel
> > transports so that we only have to deal with those transports.
>  Currently
> > openejb registers an http servlet so we need to have the OSGi http
> service
> > (which comes from the pax project and uses jetty).
>
> Yeah - I guess we need to figure out the NMR's interface/service
> qnames too so JBI can access them in a canonical way too.
>
>
> >    We also need to define, where and how these POJOs are exposed on the
> > bus.  I suppose each POJOs would lead to a servicemix Endpoint being
> exposed
> > in the OSGi registry (which is the way to expose an endpoint in
> servicemix
> > 40, but the quetion is: which protocol / data does the pojo expect ?
> >    I'm thinking we may want to do the same thing we do in JBI: split the
> > protocol (http+soap) from the pojo invocation, but this will require an
> xml
> > wrapper so that we can keep all the WSDL 1.1 message parts (we could
> just
> > reuse the JBI one ?).  Another thing is that the CXF camel component can
> > work in collaboration with the camel bean component by using a list of
> > unmarshalled parameters as the message payload. Can we use both approach
> at
> > the same time ?
>
> Yeah; through expermentation this will become more clear. We could
> also use the annotations on method parameters to help take the XML and
> bind it to the POJOs too...
> http://activemq.apache.org/camel/bean-integration.html
>
> along with things like
>
> void mySomething(@XPath("/foo/bar") int cheese) {... }
>
>
> >   * We need to keep a way to configure things using spring so that you
> can
> > leverage CXF features such as WS-Security, WS-ReliableMessaging, etc...
>
> Yeah. Hopefully the beans are configured via spring then things are
> nice and easy?
>
>
> > The key point is to keep things easy to use, so we need to have both the
> > spring way of wiring things and be able to simply deploy a bundle which
> > contains an annotated POJO and everyhing would work.  We also want to
> > integrate cleanly with other JBI components and camel components.  Ideas
> > welcome.
>
> BTW have you noticed that in Spring 2.5, it can scan the classpath
> looking for beans and configure them as if they were in the XML via
> annotations? So it would be possible to kinda say, all beans are
> configured via Spring (whether in XML or we find 'em via annotations).
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

Re: EJB and JAXWS support in ServiceMix 4.0

Posted by Guillaume Nodet <gn...@gmail.com>.
On Nov 23, 2007 9:27 AM, James Strachan <ja...@gmail.com> wrote:

>
> >   * We need to keep a way to configure things using spring so that you
> can
> > leverage CXF features such as WS-Security, WS-ReliableMessaging, etc...
>
> Yeah. Hopefully the beans are configured via spring then things are
> nice and easy?
>
>
> > The key point is to keep things easy to use, so we need to have both the
> > spring way of wiring things and be able to simply deploy a bundle which
> > contains an annotated POJO and everyhing would work.  We also want to
> > integrate cleanly with other JBI components and camel components.  Ideas
> > welcome.
>
> BTW have you noticed that in Spring 2.5, it can scan the classpath
> looking for beans and configure them as if they were in the XML via
> annotations? So it would be possible to kinda say, all beans are
> configured via Spring (whether in XML or we find 'em via annotations).
> --
> <http://open.iona.com>
>

I missed that.  That sounds like what we want :-)   However it might require
more work as we would have to rewrite some code currently provided by
openejb, but it may be worth it :-)


-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

Re: EJB and JAXWS support in ServiceMix 4.0

Posted by James Strachan <ja...@gmail.com>.
On 23/11/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> One of the thing I'd like to have before we release a milestone (this year
> hopefully) is a way to simply expose web services or EJB3 in the ServiceMix
> bus.
> I've been working since ApacheCon on OpenEJB integration and I've committed
> a bunch of things already, but this is not in a workable state yet.
>
> Freeman is also working on integrating CXF for plain JAXWS support but there
> will be some overlap there, so it may be better to think about a strategy
> and avoid duplication and incompatibilities in these areas. I guess we need
> to solve a few points:
>
>    * do we want to be able to deploy web services if the EJB layer is not
> installed: currently, the openejb integration registers a bundle listener to
> detect annotated POJOs and deploy them, so that even if you want to deploy a
> plain jaxws pojo (without any EJB annotations), you still need to go through
> the ejb layer.  I don't see any problems with that for the moment, though I
> suppose we may want to split that later

Maybe we need 2 listeners; one for EJB annotations, one for JAX-WS
annotations (with JAX-WS winning). Then you can avoid having to have
the EJB stuff there?


>   * how to expose POJOs on the bus ?  This is not done yet for the openejb
> layer, but my thinking is that we want to expose those beans by using camel
> transports so that we only have to deal with those transports.  Currently
> openejb registers an http servlet so we need to have the OSGi http service
> (which comes from the pax project and uses jetty).

Yeah - I guess we need to figure out the NMR's interface/service
qnames too so JBI can access them in a canonical way too.


>    We also need to define, where and how these POJOs are exposed on the
> bus.  I suppose each POJOs would lead to a servicemix Endpoint being exposed
> in the OSGi registry (which is the way to expose an endpoint in servicemix
> 40, but the quetion is: which protocol / data does the pojo expect ?
>    I'm thinking we may want to do the same thing we do in JBI: split the
> protocol (http+soap) from the pojo invocation, but this will require an xml
> wrapper so that we can keep all the WSDL 1.1 message parts (we could just
> reuse the JBI one ?).  Another thing is that the CXF camel component can
> work in collaboration with the camel bean component by using a list of
> unmarshalled parameters as the message payload. Can we use both approach at
> the same time ?

Yeah; through expermentation this will become more clear. We could
also use the annotations on method parameters to help take the XML and
bind it to the POJOs too...
http://activemq.apache.org/camel/bean-integration.html

along with things like

void mySomething(@XPath("/foo/bar") int cheese) {... }


>   * We need to keep a way to configure things using spring so that you can
> leverage CXF features such as WS-Security, WS-ReliableMessaging, etc...

Yeah. Hopefully the beans are configured via spring then things are
nice and easy?


> The key point is to keep things easy to use, so we need to have both the
> spring way of wiring things and be able to simply deploy a bundle which
> contains an annotated POJO and everyhing would work.  We also want to
> integrate cleanly with other JBI components and camel components.  Ideas
> welcome.

BTW have you noticed that in Spring 2.5, it can scan the classpath
looking for beans and configure them as if they were in the XML via
annotations? So it would be possible to kinda say, all beans are
configured via Spring (whether in XML or we find 'em via annotations).
-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com

Re: EJB and JAXWS support in ServiceMix 4.0

Posted by Guillaume Nodet <gn...@gmail.com>.
The problem is that I'd like to avoid using the CXF transports, so that we
don't have the same problems as we do in ServiceMix 3.x, which is having 5
different ways of dealing with HTTP.   So I'd like to use camel transports
by using:
   from("soap:activemq://xxx")
or
   from("soap:jhc:http://localhost/xxx")

That way, we can immediately benefit from soap support on all camel
transports.
Imho, this would be ideal, though I don't know yet how far we can go that
way.

On Nov 23, 2007 10:02 AM, Freeman Fang <fr...@gmail.com> wrote:

> Guillaume Nodet wrote:
> > One of the thing I'd like to have before we release a milestone (this
> year
> > hopefully) is a way to simply expose web services or EJB3 in the
> ServiceMix
> > bus.
> > I've been working since ApacheCon on OpenEJB integration and I've
> committed
> > a bunch of things already, but this is not in a workable state yet.
> >
> > Freeman is also working on integrating CXF for plain JAXWS support but
> there
> > will be some overlap there, so it may be better to think about a
> strategy
> > and avoid duplication and incompatibilities in these areas. I guess we
> need
> > to solve a few points:
> >
> >    * do we want to be able to deploy web services if the EJB layer is
> not
> > installed: currently, the openejb integration registers a bundle
> listener to
> > detect annotated POJOs and deploy them, so that even if you want to
> deploy a
> > plain jaxws pojo (without any EJB annotations), you still need to go
> through
> > the ejb layer.  I don't see any problems with that for the moment,
> though I
> > suppose we may want to split that later
> >
> >   * how to expose POJOs on the bus ?  This is not done yet for the
> openejb
> > layer, but my thinking is that we want to expose those beans by using
> camel
> > transports so that we only have to deal with those transports.
>  Currently
> > openejb registers an http servlet so we need to have the OSGi http
> service
> > (which comes from the pax project and uses jetty).
> >    We also need to define, where and how these POJOs are exposed on the
> > bus.  I suppose each POJOs would lead to a servicemix Endpoint being
> exposed
> > in the OSGi registry (which is the way to expose an endpoint in
> servicemix
> > 40, but the quetion is: which protocol / data does the pojo expect ?
> >    I'm thinking we may want to do the same thing we do in JBI: split the
> > protocol (http+soap) from the pojo invocation, but this will require an
> xml
> > wrapper so that we can keep all the WSDL 1.1 message parts (we could
> just
> > reuse the JBI one ?).  Another thing is that the CXF camel component can
> > work in collaboration with the camel bean component by using a list of
> > unmarshalled parameters as the message payload. Can we use both approach
> at
> > the same time ?
> >
> My comment [1] just verify how servicemix camel component  works with
> cxf camel component inside SMX4. I think this test split  protocal from
> the pojo invocation,
> something like
> from("cxf://http://localhost:9000/router?serviceClass=
> org.apache.servicemix.camel.HelloService&dataFormat=POJO")
>    .to("smx:testEndpoint") // for procotol
>
> from.("smx:testEndpoint")
>
> .to("cxf://local://smx/helloworld?serviceClass=
> org.apache.servicemix.camel.HelloService&dataFormat=POJO")
> // for invocation
>
> here testEndpoint is an endpoint of SMX.
> But I am not sure cxf camel component can handle ws-* feature so far.
>
> Btw, to get this test working,  we need apply patch for camel-243 as [2]
> Can any camel committer review and apply this patch? :-)
> Thanks very much
>
> [1] http://svn.apache.org/viewvc?diff_format=h&view=rev&revision=597579
> [2] https://issues.apache.org/activemq/browse/CAMEL-243
>
>
> >   * We need to keep a way to configure things using spring so that you
> can
> > leverage CXF features such as WS-Security, WS-ReliableMessaging, etc...
> >
> > The key point is to keep things easy to use, so we need to have both the
> > spring way of wiring things and be able to simply deploy a bundle which
> > contains an annotated POJO and everyhing would work.  We also want to
> > integrate cleanly with other JBI components and camel components.  Ideas
> > welcome.
> >
> >
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

Re: EJB and JAXWS support in ServiceMix 4.0

Posted by Freeman Fang <fr...@gmail.com>.
Guillaume Nodet wrote:
> One of the thing I'd like to have before we release a milestone (this year
> hopefully) is a way to simply expose web services or EJB3 in the ServiceMix
> bus.
> I've been working since ApacheCon on OpenEJB integration and I've committed
> a bunch of things already, but this is not in a workable state yet.
>
> Freeman is also working on integrating CXF for plain JAXWS support but there
> will be some overlap there, so it may be better to think about a strategy
> and avoid duplication and incompatibilities in these areas. I guess we need
> to solve a few points:
>
>    * do we want to be able to deploy web services if the EJB layer is not
> installed: currently, the openejb integration registers a bundle listener to
> detect annotated POJOs and deploy them, so that even if you want to deploy a
> plain jaxws pojo (without any EJB annotations), you still need to go through
> the ejb layer.  I don't see any problems with that for the moment, though I
> suppose we may want to split that later
>
>   * how to expose POJOs on the bus ?  This is not done yet for the openejb
> layer, but my thinking is that we want to expose those beans by using camel
> transports so that we only have to deal with those transports.  Currently
> openejb registers an http servlet so we need to have the OSGi http service
> (which comes from the pax project and uses jetty).
>    We also need to define, where and how these POJOs are exposed on the
> bus.  I suppose each POJOs would lead to a servicemix Endpoint being exposed
> in the OSGi registry (which is the way to expose an endpoint in servicemix
> 40, but the quetion is: which protocol / data does the pojo expect ?
>    I'm thinking we may want to do the same thing we do in JBI: split the
> protocol (http+soap) from the pojo invocation, but this will require an xml
> wrapper so that we can keep all the WSDL 1.1 message parts (we could just
> reuse the JBI one ?).  Another thing is that the CXF camel component can
> work in collaboration with the camel bean component by using a list of
> unmarshalled parameters as the message payload. Can we use both approach at
> the same time ?
>   
My comment [1] just verify how servicemix camel component  works with 
cxf camel component inside SMX4. I think this test split  protocal from 
the pojo invocation,
something like
from("cxf://http://localhost:9000/router?serviceClass=org.apache.servicemix.camel.HelloService&dataFormat=POJO")
    .to("smx:testEndpoint") // for procotol

from.("smx:testEndpoint")
    
.to("cxf://local://smx/helloworld?serviceClass=org.apache.servicemix.camel.HelloService&dataFormat=POJO") 
// for invocation

here testEndpoint is an endpoint of SMX.
But I am not sure cxf camel component can handle ws-* feature so far.

Btw, to get this test working,  we need apply patch for camel-243 as [2]
Can any camel committer review and apply this patch? :-)
Thanks very much
  
[1] http://svn.apache.org/viewvc?diff_format=h&view=rev&revision=597579
[2] https://issues.apache.org/activemq/browse/CAMEL-243


>   * We need to keep a way to configure things using spring so that you can
> leverage CXF features such as WS-Security, WS-ReliableMessaging, etc...
>
> The key point is to keep things easy to use, so we need to have both the
> spring way of wiring things and be able to simply deploy a bundle which
> contains an annotated POJO and everyhing would work.  We also want to
> integrate cleanly with other JBI components and camel components.  Ideas
> welcome.
>
>