• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Difference between service orchestration and application service design pattern

 
Sujeeth Pakala
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

Can any one explain the difference between "Service Orchestration"in SOA context and "Application Service" core J2EE design pattern ?

Service Orchestration : "Service orchestration is the coordination and arrangement of multiple services exposed as a single aggregate service"

Application Service : "You want to centralize business logic across several business-tier components and services"

Technically both are doing similar thing. What is wrong in calling "Application Service" as "Object Orchestration" ?

Thanks in advance.
Application Service.gif
[Thumbnail for Application Service.gif]
Application Service
 
Sujeeth Pakala
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ranchers...

Please help me on my question..
 
Roger Sterling
Ranch Hand
Posts: 426
Eclipse IDE Fedora Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In an ESB, you can have one end-point exposed which receives a request, and calls several downstream services. For example, the end-point provided by the ESB could be "ProcessOrder". A WAS server could host an Internet site that is a shopping boutique. A customer can add several items to his or her cart. When done shopping, the customer fills in payment details and submits. The WAS server then calls the ESB "ProcessOrder" service. ProcessOrder can do several things, like validate the credit card with the CC network, tokenize the payment details in support of PCI controls, establish warehouse pick-pack-ship actions, etc. Eventually the ESB returns a "thumbs-up" or "thumbs-down" to WAS.

There is a fine line between service aggregation done in an ESB and Business Process Service Orchestration. A business process that would be more likely to adopt BPEL would be a life insurance service underwriting function. ESB would fit underneath the BPEL product, actually responsible for making the down-stream calls to various service providers on behalf of the BPEL product. Managers who do not understand how the component parts of SOA fit together should not embark on an IT infrastructure modernization effort lightly. It takes more than casual knowledge to be successful in SOA. You have to have the insight, skill and expertise to determine when to use a BPEL product and when to implement an aggregate service in an ESB. You also have to be skilled in Web Services. Queues are nice and have their place, but Web Services are absolutely essential to the long-term success of any SOA implementation.

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic