Question:
A client of mine is being told by a partner that the “call orchestration” shape within BizTalk doesn’t incur any persistence point overhead because it uses an RPC call to start the called orchestration. My understanding is that the XLang engine is publishing a message for which the called orchestration has a subscription, and then the calling orchestration gets the results via a message and correlation. Can someone please let me know which is correct? I am also under the impression that the calling orchestration will incur a persistence point and is slower than using Direct Bound ports or the start orchestration shape simply given the nature of the work it is doing.

Answer:
A call has essentially the same overhead as executing a nested scope. If the called orch is non-transactional there will only be a persistence point at a send or dehydration or suspend. This also means The Call Orch shape will load the called Orch into the same Host Instance as the caller, regardless of the actual setting for the 'called Orch'.

As for the messaging cost, with either a nested transaction or a called transaction, we create a message copy to maintain isolation. Message copies are shallow in the sense that the part data is shared with copy-on-write semantics, e.g.

// given msg1 already constructed and msg2 unconstructed
construct msg2 {
msg2 = msg1; // shallow copy, the parts are shared
msg2(myProperty) = “foo”; // assuming myProperty is a data property, this will cause the part, that contains the data for myProperty, to be cloned (deep copy)
}

If the message was passed in as a ‘ref’ parameter then upon successful completion we copy it back out. But these are shallow copies, so the cost of creating a new message copy is inserting a guid into the instance substate of the transaction and some db table bookkeeping to track the part sharing. This is essentially the same cost as a nested transactional scope instead of a call.

In contrast, the cost of a Start Shape is an implicit send from the orch containing the Start shape, to an implicit receive in the orch that is being ‘started’. This is a commit point for the send and a messagebox roundtrip. Though the implicit receive of the started orchestrqation is delivered a new message, the part data is streamed and shared with the original message. It starts getting more expensive if the stream is large and you need to pull it into memory by representing it as a physical .NET type instance.

I would encourage you depending on the scenario to look at direct binding vs. Call orchestration. Kevin Lam’s blog on the topic is great: http://http://blogs.msdn.com/kevin_lam/archive/2006/04/18/578572.aspx