Scott,
So you want to build your SE then, that inspects your work order and
calls the required services based on the information available in the
work itself -- that wouldn't be any problem. Probably you can take a
look at how ServiceMix static routing slip implementation does this, but
instead you dynamically generate the list of exchange targets in your code.
ServiceMix ships with servicemix-quartz, which can be used to schedule
and trigger jobs.
Gert
Scott Johnson wrote:
On May 7, 2007, at 4:09 PM, Gert Vanthienen wrote:
L.S.,
I think an ESB solution, such as ServiceMix, can provide you with a
lot of
the features you require:
- flexible protocol handling and bridging
- loose coupling
- routing services
- dynamic endpoints
Using ServiceMix as the foundation for your solution would allow you to
leverage these features and to invest your development efforts on the
SE you
will be using in step 3 of the flow you describe. If I understand your
requirements correctly, you would want to build some kind of tooling to
easily assemble and deploy these workflows (as service assemblies).
I hadn't thought about using the service assembly as the driver for
completing a work order. In some cases our customers may build
hundreds of work orders, and we'd have to manage a service assembly
for each. That may be workable (although it seems more involved than
what I was originally thinking about). My original idea was to have
one service assembly that simply defined the various SEs, etc. needed
and their roles and have the routing done dynamically by each SE (via
the RoutingSlip approach I mentioned in the original mail that is
created based on a work order definition file).
On a different note, can service assemblies be scheduled for automatic
execution (i.e. perform this work-flow of services every day at 3
a.m.)? That is another requirement of the application.
Regards,
Scott
Is this the kind of solution you're envisioning or am I missing
something?
Regards,
Gert
Scott Johnson-16 wrote:
I am in the process of evaluating various integration/component
technologies for a forthcoming application I will be charged with
developing.
The purpose of the application is to be a means by which our
customers can perform batch operations on a selection of resources.
The customers define "work orders" that instruct the application to
perform a series of steps to accomplish the customer's goals. The
customers then instruct the application to perform those work orders.
That is the most important point: this process is completely customer-
driven and the customer can create any number of work-flows. I cannot
hard-code a Service Assembly to, say, get text files from this FTP
location, route them through the English-to-German translator, and
put them on the local hard drive. At the time of creating the
application I don't know what the work flows are specifically (just
that they involve using the services my application provides).
I have been looking into ESB, OSGi (both new approaches for me) or
just using hand-rolled code to solve the problem. Initially ESB and
OSGi seemed to be reasonably perfect matches, but the more I work
with an ESB solution, the more frustrated I become.
For my prototype application I envisioned the following pieces I'd
need to create for an ESB solution:
1. Bridge from HTTP to JMS:
a. HTTP endpoint for inbound requests (seems a reasonable way to
trigger the execution of a work order for this prototype)
b. EIP pipeline to transform and place request (which is the "work
order") onto a JMS Queue
2. JMS consumer of above JMS queue whose destination service is...
3. Custom SE1 - A component that parses the work order and forwards
to the first component listed, which is...
4. Custom SE2 - A component that performs the first work order
process then forwards the work order to...
5. Custom SE3 - A component that performs the second work order
process, then forwards the work order to...
6. Custom BC2 - An output component that places the resource to a
specific location.
Note 1: depending on the work order, there could be any number of
custom SEs involved between steps 3 and 6 above.
Note 2: none of the custom SE/BCs know about each other (as it should
be) but all know about a RoutingSlip object that is passed as a
property on the ME. Each SE designates the next service to be called
based on that routing slip (which was generated by the initial
component, #3 above) until the work order is complete.
Note 3: I have created Service Units for all the SEs which are all
designated as providers.
I'm having lots of issues getting this to work (some due to the
newness of ServiceMix and JBI to me, certainly) but, before I get
much farther I would like to ask: does this type of dynamic work flow
really align with the goals of an ESB and is it well supported or am
I barking up the wrong tree here?
Thanks for your time,
Scott
--View this message in context:
http://www.nabble.com/Is-ServiceMix-JBI-a-Good-Fit-for-Dynamic-Processing--tf3705460s12049.html#a10364510
Sent from the ServiceMix - User mailing list archive at Nabble.com.
