cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <j...@iona.com>
Subject RE: Introducing Apache Camel (was Re: The implementation of a simple service routing. WAS: RE: Release Update)
Date Mon, 26 Mar 2007 06:33:55 GMT
Hi James, thanks for the info, very interesting project, anxious to see a CXFRouteTest sample
running in Camel soon :-), do let us know if there is anything we can help out. Regarding
"Also it'd be nice to resolve URI endpoints in Camel nicely to auto-discover CXF endpoints
and vice versa", would you be able to use a code snippet like below?

        Bus bus = CXFBusFactory.getDefaultBus();
        ServerRegistry serverRegistry = bus.getExtension(ServerRegistry.class);
        List<Server> servers = serverRegistry.getServers();

        Server targetServer = null;
        for (Server server : servers) {
            targetServer = server;
            String address = server.getEndpoint().getEndpointInfo().getAddress();
           ....
        }

I also saw your comments in org.apache.camel.component.cxf.CxfBinding, this message representation
problem is a hard one. The "CXFBinding", as its name suggested, is a very vague concept, as
in CXF, we can support many different transports and bindings, for example SOAP binding, XML
binding or CDR (CORBA). In the latter case, obviously using an XML Source object wont work.
In CXF we have a concept that built upon an underlying format of inputStream (lets take the
inbound as an example),  we may have many different representations of the incoming message,
it can be an XMLInputStream, a SAAJ message or Java objects. Interceptors that belong to different
phases can pick the representation of their interest to work with, of course, they have to
know what format they can expect by calling mesage.getContent(...). In the case of org.apache.camel.component.cxf.CxfBinding,
might be a good idea to have an abstract CxfBinding class, then several extensions such as
CXFSoapBinding, CXFXMLBinding, CXFCORBABinding etc. Another thought is that it is likely we
may only want to use a stream format in the router, for example, we only scan the soap header
or name space, once we find the info we will stop any further scanning and redirect the request.
In this case, using a Stax based API presumably will have better performance than transforming
the whole input into XML objects. 

Cheers,
Jervis

> -----Original Message-----
> From: James Strachan [mailto:james.strachan@gmail.com]
> Sent: 2007?3?23? 23:09
> To: cxf-dev@incubator.apache.org
> Subject: Introducing Apache Camel (was Re: The implementation 
> of a simple service routing. WAS: RE: Release Update)
> 
> 
> On 3/23/07, Liu, Jervis <jliu@iona.com> wrote:
> > Hi, I've been experimenting a bit on the service routing 
> lately, the result has been put on the wiki: 
> http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Ro
> uting. So it works ((I will check in a system test shortly), 
> my main concern though, is that this implementation does not 
> seem to be very "simple", it does require a fair amount of 
> knowledge of CXF internal. Not sure if it is appropriate to 
> expose this to CXF userland. Anyway, I am open to any 
> comments&suggestions.
> >
> > Thanks,
> > Jervis
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 2007?3?17? 3:32
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Re: Release Update
> > >
> > >
> > > On 3/15/07, Liu, Jervis <jliu@iona.com> wrote:
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > > > Sent: 2007?3?15? 21:44
> > > > > To: cxf-dev@incubator.apache.org
> > > > > Subject: Re: Release Update
> > > > >
> > > > >
> > > > > Hi Jervis,
> > > > >
> > > > > I wanted to ensure that we can setup an endpoint on a URL
> > > and route to
> > > > > different services based on headers (such as ws-a) or other
> > > > > logic.  I made a
> > > > > series of proposals about how to do this a while back, but I
> > > > > don't think we
> > > > > ever came to any concrete conclusion.
> > > > >
> > > > Ok, I see what you mean. I believe you are referring to
> > > this proposal [1].
> > > > One thing I have not figured out from the proposal yet is
> > > how we know the
> > > > addresses of services to which the routing service is about
> > > to redirect?
> > > > Through some kind of registries or a configuration loaded
> > > from a separate
> > > > file or a WSDL extension.? Once this kind of discussion
> > > gets started, I do
> > > > not see how it can end by the end of this release. Service
> > > routing is a huge
> > > > topic anyway. However we will have much less to worry about
> > > if we are not
> > > > after a complete resolution of service routing. For
> > > example, if we only
> > > > support the routing among different endpoints within the
> > > same Destination,
> > > > would this feature be considered helpful for some certain
> > > use cases? Reading
> > > > your proposal, I believe this is also what you want to do,
> > > start from sth
> > > > simple first. If this is the case, I am ready to get my
> > > hands dirty now.
> > > >
> > > > BTW, I am in a traveling at the moment, I may not respond
> > > in time until I
> > > > get back to office next Tuesday.
> > > >
> > > > [1].
> > > >
> > > http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
> > 
> 612.mbox/%3c7b774c950612021343x513c2783o128a032ba93923bb@mail.
> gmail.com%3e
> >
> >
> >
> > Yes, I'm really just concerned about the simple case. 
> Namely being able to
> > create some type of routing endpoint which routes to other types of
> > services. My main use cases is versioning of services. 
> Ideally many services
> > can share the same URL and I can route by headers or the 
> namespace of the
> > body part.
> >
> > Regarding how to know what services to route to - I think 
> its up to the user
> > to write that code. I was kind of envisioning that it'd be 
> an interceptor
> > that a user writes. We could build something more formal 
> like a registry,
> > but we would need something low level first :-)
> 
> Sorry to hijack this thread; a bit of background first then I'll get
> more on topic...
> 
> On the ActiveMQ and ServiceMix projects we've wanted a simple POJO
> router for a while thats
> 
> * Apache Licensed
> * small & simple with minimal dependencies (just commons-logging)
> * allows routes to be defined easily in Java code or using Spring XML
> * can work with any of the various messaging models and APIs from
> HTTP, JMS, JBI, CXF, JAX-WS, MINA etc
> 
> A little experimental library soon turned into a fairly full featured
> router very quickly. The documentation is still quite sparse, but let
> me introduce you to Apache Camel...
> http://activemq.apache.org/camel/
> 
> Here's a quick example to give you the idea...
> http://activemq.apache.org/camel/routes.html
> 
> We've been documenting how the Enterprise Integration Patterns can be
> implemented using Camel
> http://activemq.apache.org/camel/enterprise-integration-patterns.html
> 
> Here's a quick overview of the architecture (we'll document this way
> better soon)
> http://activemq.apache.org/camel/architecture.html
> 
> 
> One of the interesting things about Camel is it can work with any
> underlying protocol using a small & simple API (similar to a
> simplification & generalization of both CXF Bus API and JBI).  Not
> only that, thanks to generics and covariant return types we can work
> explicitly with specific protocols when required in a nice typesafe
> manner to avoid leaky abstractions.
> 
> e.g.
> 
> // A JMS specfic processor
> class Foo implements Processor<JmsExchange> {
>   public void onMessage(JmsExchange exchange) {
> 
>     // lets do some direct JMS stuff..
>     javax.jms.Message message = exchange.getInMessage();
>   }
> }
> 
> So we could easily route from JMS to CXF to JBI and into MINA say.
> 
> Enough of all that, lets show an example thats more releative 
> to CXF...
> 
> RouteBuilder<Exchange> builder = new RouteBuilder<Exchange>() {
>     public void configure() {
> 
>         // a declarative routing rule example
>         from("cxf:myservice").choice()
>                 
> .when(version().isEqualTo("1.2")).to("cxf:myservice1.2")
>                 .when(xpath("/foo/bar[@cheese =
> 'edam')).to("cxf:myOtherService")
>                 .otherwise().to("jms:Error.Queue");
>     }
> };
> 
> In this particular case we're using a custom expression version()
> which could be any old Expression<Exchange> implementation.
> 
> 
> I think Camel could be useful for arbitrary declarative routing and
> mediation rules in CXF. I've taken an early stab at supporting CXF Bus
> API in Camel...
> 
> https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-cxf/
> 
> I've got the main parts done (the exchange & message pieces), I'm just
> not sure yet in the CxfEndpoint how to bind inbound exchanges to the
> CXF bus and back again nicely. Also it'd be nice to resolve URI
> endpoints in Camel nicely to auto-discover CXF endpoints and vice
> versa. Then there's being able to put Camel inside CXF so that the
> JAX-WS client will invoke Camel to do the routing etc
> 
> 
> Thoughts and feedback most welcome - also any help getting Camel-CXF
> working would be good too :)
> 
> -- 
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 

Mime
View raw message