Publishing an orchestration as a WCF Service leads to tight coupling. Whereas publishing schema as a WCF Service achieves loose coupling.
When an orchestration is published as a WCF Service, the data (message) received via the WCF Service will be directly bound the Orchestration which is published.
On the other hand when a schema is published as a WCF Service, the data (BizTalk message) received via the WCF Service will be published to the BizTalk Server Message Box and hence any number of subscribers can subscribe for the message.
When an orchestration is published as a WCF Service, the data (message) received via the WCF Service will be directly bound the Orchestration which is published.
On the other hand when a schema is published as a WCF Service, the data (BizTalk message) received via the WCF Service will be published to the BizTalk Server Message Box and hence any number of subscribers can subscribe for the message.
When we expose an orchestration as a WCF service, it means we should execute the orchestration by calling the WCF service from client with the parameter message payload same as what the orchestration receive shape expects. The message payload is received by message box first and the subscribing orchestration instance then gets fired and the 'processing' takes place very much similar to what happens inside the method of a WCF service which is decorated with [OperationContract] attribute.
·
Now when a schema is exposed as a WCF service, it gives rise to a very loosely coupled pattern. Here only the schema is coupled, which is the contract of the 'contract first' approach. Here no 'processing' like orchestration is yet defined, which means, any orchestration can subscribe to the message payload received from the message box, when the WCF service is called by client. Here the loose coupling comes from the fact that we can simply make any, just any orchestration to subscribe to that message. Whereas, while you expose an orchestration as WCF service, you essentially mean to use that orchestration alone, a tighter coupling scenario.
Now the thing is after you expose certain schemas as WCF service, then when you add reference to the .svc file from your client application then appropriate proxy classes are created in the wsdl wherein all the types you declared are already available. This also happens when you consume the WCF service from another orchestration by saying "Add Generated Items --> Consume WCF service" eventually going through the WCF service consuming wizard. The types with appropriate namespaces would be automatically available to you and you need to populate the objects from your client code and call the service by submitting the payload
Hi Ashok, I am new to BizTalk.
ReplyDeleteI have an assignment to consume WCF from BizTalk Orchestration.
The actual requirement is to wrap WCF into BizTalk.
There is no change in input/output parameters.
So I successfully consumed WCF into BizTalk Orchestration.
I followed below steps:
1. Used WCF Consume Wizard & Added artifacts
2. Created 4-messages (Biz-Input, Biz-Output, WCF-Input, WCF-Output)
3. For Biz-Input/WCF-Input, I used reqest message from Multi-part, generated by Wizard
4. For Biz-Output, WCF-Output, I used response message from Multi-part, generated by Wizard
5. I even used construct message before & after call WCF in Orchestration for converting Biz-Input to WCF-Input & WCF-Output to Biz-Output
6. Build & Deployed Successfully.
7. Configured on BizTalk Administration Console Successfully.
8. I can added the URL into SOAP UI and it got loaded as well.
The issue is Request message is not displaying the parameters.
Could you please help me out here...