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+Routing. 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]
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/
