Re: Is ServiceMix/JBI a Good Fit for Dynamic Processing?

[Scott Johnson]

On May 8, 2007, at 8:49 AM, Gert Vanthienen wrote:
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.


Yes this is precisely what I need to do. It sounds like it's worth  
the time for me to pursue this prototype in ServiceMix further.

One other question: can the provided SEs be configured at run-time to  
perform their service? For example, say I have 2 work orders both of  
which want use FTP to monitor for input files but at different times  
and from different FTP sites. Can my SE pass along a configuration at  
run-time to the servicemix-ftp component to tell it where to GET from  
(rather than having to specify it in a config file)? I assume I'd  
still need to deploy an SU but (hopefully) I can override it's  
configuration dynamically as I process work-orders.

Thanks,
Scott

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.








Scott Johnson, Software Developer
MediaSpan Media Software
[EMAIL PROTECTED]