When is a service not an orchestration?

When is a service not an orchestration? This is the question that Christoph asks?

His point is that all bpel orchestrations 'are services' and if one wanted you could use the orchestration as an agility mechanism. For example, you know that you need a service 'foo' - why not make an orchestration 'foo' where the 'foo' orchestrations calls the 'foo' service. In essence, you treat the orchestration like a proxy to the end service. Christoph goes on to point out that like any proxy-calls, you incur extra overhead. By proxying, you don't tie the 'foo' service directly to the non functional requirements (logging, security checks, business activity monitoring, etc. ) you could add additional steps into the orchestration to perform these for you.

Overall, I'd have to agree with where Christoph landed - if the orchestration is time sensitive or doesn't look like it will need any 'decorators' - then just make it a service. If it is part of a long running business process and isn't necessarily time sensitive than consider front-ending the service with an orchestration and add the decorators.

In the long run this may kind of 'orchestration-proxy for NFR's' might go away. I'm still a big believer (as is Christoph) in using declarative aspects on services. In this manner, you would declare the decorators on the service and when the service was called and it would trigger the decorator calls (think Aspect Oriented Services). Either way... I'm not sure which one is easier to read / debug. Although it does raise a good point - we probably need a metatag to state if a service call is part of a NFR resolution or if it is a legitimate Functional step in the orchestration...