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). 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.
