Orchestration vs Message Driven Architecture
Asked Answered
B

4

8

What are the responsibilities of an Orchestration engine vs a Message Driven System.

If I have to build a system which have to string together different independent components(cross-technology/platform components which need not expose a web service end point), which is the toolset to be chosen?

Is there a better option?

Bonine answered 12/8, 2009 at 8:13 Comment(0)
E
2

Use openESB with netbeans editor or any other open source BPEL engines which provides standard way or orchestrating the process. if you think performance is very important than standardization you can try out some proprietary ESB or BPM tools like Jboss jBPM or mule ESB etc.

Please note BPEL can be used only to consume Web Services if your components are not web services then you may have to use some ESB like Mule which can support some 200+ protocols with extensions.

Eulaheulalee answered 10/9, 2009 at 15:16 Comment(0)
A
1

When deciding if you should use Orchestration or Message Directed work flow, the big question you face is, do you think it will be necessary to change your orchestration work-flow on a regular basis. If you think the Business Process needs to be flexible because it is subject to change, then adopt a Canonical Message format and use Orchestration, which will minimise he impact of changing relationships between services. If you think the work-flow is stable you can adopt a message driven work-flow. Personnally I think Orchestration is the superior approach in general, however it does require more software infrastructure which with tools like Apache Camel the investment is time with the reward of increased long term flexibility.

Argument answered 9/10, 2009 at 11:14 Comment(0)
V
0

While this question is tagged Java, I'm afraid to say the best tool I've seen if you really have to go this route is Microsoft's BizTalk Server.

When I had to do an evaluation of this type of product (and this was a few years back) it was head and shoulders above the competition with the main features being:

  • Visual Studio as the development environment
  • nice visual tools to describe workflows and transformations
  • extendable connector architecture used to connect to participants
  • powerful workflow engine with great realtime reporting

In the end we choose to keep-it-simple and went the messaging route, although this does require you've got control of all the participants, which may not be the case.

Veljkov answered 12/8, 2009 at 8:49 Comment(0)
T
0

I suggest you to first expose your single indipendent components as service throught the web (I didn't understand if you already have webservices for this). After that..the best choice depends on your system workload/complexity.

Basically you can choose between service Orchestration vs Choreography. Service Orchestration, made with BPM/BPEL/ESB is an architectural choice where a single component (the service orchestrator/service composer) knows which steps needs to be executed and it's responsible for invoking services in the right order (configured on the orchestrator itself). It also handle transaction management (if needed).

The opposite is Choreography where in fact each single service composing the whole system knows how to act when it recieve a specific message. In fact it's a matter of aggreement between the various component. Service Choreography it's a decentralized approach to service composition problem.

In case you have lot of services, complex rules and so on...probably it will be easier to use a service orchestrator like jBPM or something like this.

Tetrapod answered 21/1, 2016 at 10:28 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.