• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Paul Clapham
  • paul wheaton
Sheriffs:
  • Tim Cooke
  • Devaka Cooray
  • Rob Spoor
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Tim Moores
  • Carey Brown
  • Mikalai Zaikin
Bartenders:

Difference between service orchestration and application service design pattern

 
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ranchers...

Please help me on my question..
 
Ranch Hand
Posts: 426
Eclipse IDE Fedora Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.

 
We noticed he had no friends. So we gave him this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic