How to best implement an Orchestration Layer?

So after carefully divding and separating our middle tier into lously-coupled services, the need for an orchestration layer that sits on top of all the services became apparent.

I'm curious to see how others are implementing this orchestration layer: using something like Biztalk or another code layer that plays the role. BizTalk seems great at managing a business workflow, but what if this orchestration layer needs to aggregate data from multiple services Is BizTalk still the right tool

Also want to know is since some service calls need the orchestration layer's help and some don't (calling the services directly), is there a pattern for this In other words, does the presentation layer ALWAYS call the orchestration layer even if some calls are just pass through to the service layer I believe the decision to call the orchestration layer or the service layer directly isn't for the presentation layer to decide but I hate to have a bunch of pass throughs.

Any tips would be helpful.

Thanks,

Jason

Architecture4

This is what we are doing.

The business process or the workflow management is done using an orchestration that makes all the required service upon receiving a request from the client which could be a windows or web application. The calls to the services may be synchronous or asynchronous. If the call is asynchronous we use correlation to make the connection between the request and response from the called service.The orchestration itself is exposed as a webservice to the initiator of the business process.

I think using a workflow everywhere is not a good solution - only use it where appropriate. If you partitioned your services correctly you will only have relatively few instances where you'd need to aggregate services (vs. the times you need to go to the services themselves).

Biztalk is a possibility - though I would setup a proof of concept to verify the needed performance can be achieved on the target hardware

Arnon

Biztalk is the right tool to do this.

"Does the presentation layer ALWAYS call the orchestration layer" NO..! Why would you do that biztalk has got some great monitoring capabilities, but that shouldn't be a reason. I would say that the orchestrations are a part of the business layer. A workflow is business knowledge and is called by a service, so the presentation layer doesn't decide what to use, it just uses services some of them have got a workflow some don't. Just like data-aggregation services, when you have a lot of difficult transformations and aggregations you better use BizTalk but when it's easy don't.

Use tools like BizTalk where they are primary made for, orchestrations / workflows.

"the need for an orchestration layer that sits on top of all the services became apparent."

I disagree.

Consider a scenario like the one I published here: http://groups.yahoo.com/group/service-orientated-architecture/message/5021

Most inter-service communication is pub/sub. Clients talk to services using correlated request/response, or just plain old one-way. If you find you need to do a lot of orchestration, chances are you've partitioned your services wrong. The main use case of orchestration is within a service - in talking to legacy applications. But this implementation detail should not leak out!

I hope that clears it up.