Dave, simple is good for a start and the requirements that you outlined are reasonable. I
have a couple of questions on what you said.
"ddunkin" wrote : In our inhouse system, we have many adapter components that
plug into a core. These adapters may handle specific types of input documents (e.g. an
Ariba OrderRequest document) or a range of documents.
If you read the original requirements architecture document for JBossESB from March 2006,
you'll notice that we have the concept of multiple buses. Each bus can be for a
different requirement, e.g., SOAP/HTTP or JMS, lifecycle messages (start/stop a service
etc.), or application content. So in our architecture, it would seem that the requirement
you've just described could be modeled as a bus per type of document(s). Would that be
a fair assessment?
anonymous wrote :
| Our system uses OAGIS, an XML "business language," as the common language
for the system, so all messages are converted to OAGIS documents if they're not
already in that format.
|
Sounds like a good candidate for one of the formats we could transform from/to once Tom
gets up to speed. We currently don't have a default message format and I was wondering
what the pros and cons are of OAGIS. Could you start a separate thread in the forum on
that and just seed it with your impressions of using OAGIS?
anonymous wrote :
| Here's where the content-based routing comes in. The adapter components in our ESB
are deployed with a set of routing rules.
|
How configurable is this? Is it static or can it be updated dynamically?
anonymous wrote : These rules basically say "for a document matching this XPath
expression, send the document to this location (an instance of an adapter component bound
in the JNDI tree)." We use drools 2.1 and a simple custom DSL.
|
The dispatcher component within our ESB architecture has always been the place I've
looked to add content-based routing. I think that's still the case, but would be
interested in your feedback.
anonymous wrote :
| So for us, the requirement of content-based routing is pretty simple: be able to
determine destination address of a message from an XPath expression. Does anyone else have
examples of how they would like content-based routing to work?
|
Presumably it's not just addresses? I've seen examples of CBR where the routing
algorithm is finer grained: for example address and payload ("operation").
I've also seen deployments that use stateful routing algorithms, e.g., "if the
last interaction put us into state A, then route this msg here, otherwise route it
here." There's an argument that stateful interactions should be dealt with at the
higher level by a process flow component and I haven't had time to revisit this in
enough depth. Certainly some transient stateful interactions may be better dealt with
within the lower levels, e.g., fault tolerance.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960326#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...