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:[EMAIL PROTECTED]
> Sent: 2007?3?23? 23:09
> To: [email protected]
> Subject: Introducing Apache Camel (was Re: The implementation
> of a simple service routing. WAS: RE: Release Update)
>
>
> On 3/23/07, Liu, Jervis <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> > > Sent: 2007?3?17? 3:32
> > > To: [email protected]
> > > Subject: Re: Release Update
> > >
> > >
> > > On 3/15/07, Liu, Jervis <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Dan Diephouse [mailto:[EMAIL PROTECTED]
> > > > > Sent: 2007?3?15? 21:44
> > > > > To: [email protected]
> > > > > 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/[EMAIL PROTECTED]
> 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/[EMAIL PROTECTED] =
> '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/
>
