The scope of your question is quite large, and I think its answer is probably not well suited for the SO "Q + A" format.
However, the provision of an integrated corporate service consisting of one or more basic web services is a general requirement.
I built a quick and dirty example (BTS 2010 / VS 2010) and uploaded to GitHub here (download the source as zip in the lower right corner)
Here is the “cookbook” of steps taken to implement this from scratch, but I believe that you will need to get the code to follow.
Create a new solution in Visual Studio
Add a WCF service project and publish it to IIS (scope not covered in this example)
- Used the default WC2 project VS2010 and named the
WCFService project - Used by
basicHttpBinding for simplicity, but obviously other bindings can be used (but additional problems such as security, etc. will be required). - Please note that all
NameSpace tags on ServiceContract , ServiceBehavior and in the web configuration for behaviour namespace set (otherwise, the default will be tempuri )
Add 4 new BizTalk projects to the solution:
I named them BizTalkWCF.Orch , BizTalkWCF.Maps , BizTalkWCF.WCFPorts and BizTalkWCF.Schemas
First it's WCFPorts
- Right-click the
WCFPorts project and select Add, then Generated Items. - Select WCF Consumption
- Check metadata exchange endpoint (Mex)
- Specify the URL of your WCF service (e.g.
http://localhost:57582/Service.svc ) - Leave the namespace (BizTalkWCF.WcfPorts)
- Complete the wizard - WCF artifacts should now be present.
- If you need to import multiple web services, I would suggest you create separate Visual Studio solution folders for each
Since we divided the project into BizTalk (which is usually a good idea), unfortunately, the wizard will mark all imported artifacts as internal, which is not very useful if they refer to other assemblies. Open the imported generated Orchestration (MyService.odx) (NB never delete or move this ODX, because it contains the generated ports - just leave it with the generated WCF artifacts).
In the orchestration view, below, open the types. In the Port Types section, you should see the WCF ( IService ) interface. Click it and change the property type modifier to "Public". Do the same for message types with several parts (4 x IService_ * - note that for each WCF method on the service there are 2 message types x (one for the request, one for an answer).
The WCF port project should now be created.
Next Schemas project Add 2 x Schemes representing what will be shown (published) from BizTalk (I named them BizTalkServiceRequest and BizTalkServiceResponse ) This example just provides a thin facade based on the WCF service, so I just got the same fields for the original WCF service on request and an answer with the same xs types. However, note that the concept of "Entity" in the underlying WCF service has been replaced by requests and responses. It is possible, however, to refactor and reuse common elements in schemas (xsd: import) for multiple messages. I just used the default namespaces and the "Root" node, but notice that they will be visible to your BizTalk users, so in a real project you will want to give this thought.
Please note that we did not reuse the imported / generated WCF service schemas. In a complex enterprise, you can also use the 3rd set of schemes, “canonical” schemes, which are agnostic both the formats used by the consumer of the BizTalk service and the consumed service (and, in addition, more cards will be required).
The following are the cards , between the incoming Request to the WCF Input Schema, and then another card to respond from the WCF output scheme back to the BizTalk service user. In the map project, add .Net links for both the WCFPorts project and the Schemas project. Add a new map to the map project. For the source map, find the reference map scheme - BizTalkServiceRequest. For the destination scheme, select the WCF port scheme (the name is horribly distorted, but it will be with MyService, not datacontracts or microsoft schemas). Please note that you need to choose which of the following schemes you need to use. Select the GetDataUsingContract schema. Under the elements, drag the mouse from the source Name element to the value of the target schema and from the IsAddSuffix element to BoolValue . Do the same for the return response message - obviously, this time the WcfResponse message is the source, and the BizTalk response set is the destination. A boolean is not useful in the answer, so only a string value is displayed. Maps should now compile.
The last project is an orchestration project
- Add a link to the projects "Maps, schemes and ports"
- Add a new orchestration (I called AddServiceOrchestration).
- You need to add the receive port (added on the left) and send the port (on the right).
- The send port uses the existing imported WCF port (which we published earlier). I will send a request and get a response.
- Port binding selects Direct Binding and is routed using a filter expression.
- For the receive port, you need to create a new port type request - a request. Receive the request, send the response and again, Direct binding, with routing through filter expressions.
- Again, you need to make a public port
- You need to set the message types on the receiving port for both the request and the response (click on the request and response, and then find the message types in the Schema assembly)
- The forms in the orchestration should be clear and understandable - basically, just tie up the ports for receiving and sending figures, and then use the cards in the conversion forms.
- The initial form of administration is activation.
Create + Publish
Now everything has to be built, so its publication time in BizTalk (I assumed the local server) At the moment, we will publish the orchestration using the Wizard and we will use IIS to work with the open web service, although note that Biztalk can also start on its own. Be sure to include the application name on the Deployment tab in all 4 Biztalk projects (otherwise they will end in the application by default). Also, remember that BizTalk assemblies must be signed, so create a .SNK tab (Signing tab)
Right-click on the solution and select "Deploy." (Note that the project must be built + deployed before you can use the Publishing Wizard to open the service) Assuming a successful deployment, you need to configure the orchestration (another Orch — one that was created using WCF imports — owns WCF ports ) Create a dispatch send Static Solicit Response Port - WCF basicHttpBinding , specify its WCF web service URL. You can get the SOAP action from WSDL WCF, for example. YourNameSpaceHere/IService/GetDataUsingDataContract Add a filter to the send port for the message (xmlns # root), for example, YourNameSpaceHere#GetDataUsingDataContract
In Visual Studio, you can publish Orch as a WebService (Tools: BizTalk WCF Services Wizard Wizard) Enable metadata publishing. I used basicHttpBinding again. And create a receive port by selecting an application (BizTalkWCFSample)
When prompted, select the assembly containing Orchestrations (BizTalkWCF.Orchs) You will also be prompted to set the target WCF service namespace - keep a note of this as if you need to republish your service, you most likely want to keep the namespace the same .
The place at the end is the place where it will be published on IIS. Select "allow anonymous access" if you do not want to worry about blocking the open security service. AFAIK there is no way to manage the name specified for an automatically generated receive port.
Now you need to start the BizTalk application - to fix any unresolved configuration problems (for example, assign orchs to processes)
You will need the new .Net 4 application pool in IIS (call it something like BizTalkIsolatedHost ),
And then move the wizard-created application in IIS to this application pool. Now you can go to your Orchestration endpoint, for example: http://localhost/BizTalkWCF.Orchs/BizTalkWCF_AddSuffixService_RcvSuffixService.svc
Summing up - was it all worth it?
As you can see from the above, there is quite a lot of work on re-exporting the web service to BizTalk, and we really have not added any value to BizTalk, except perhaps to have some BizTalk tracking and try again the opportunity :). When organizing a composite service (for one incoming request several calls are required for external calls, as well as using canonical schemes), many more schemes and maps will be considered, as well as additional complexity with orchestration. And when working with web services, you get a large number of artifacts (schemes, maps, messages, ports, etc.) very quickly, so a strict naming convention is important.
And we did not consider such things as exception handling, retries, etc.
So, just a sanity check before planning to publish 100 services this way, I think we need to consider other technological alternatives:
- BizTalk ESB tool (especially if your enterprise has a certain degree of generality and / or you have control over the service consumer)
- Other ESBs (Mass Transit, NServiceBus, ServiceMix, etc.) or DIY buses built on Camel, Mule, Drools, Rabbit, Windows Service Bus, etc.), possibly with a custom facade to display the endpoints of the web -services.
- For large "service facades," Microsoft began prototyping the promising Managed Service Engine technology, but unfortunately it looks like ice.
But if there are very few such services, especially if such services require the compilation and comparison of several internal services or use different consumed technologies (SAP RFC, SQL, SOAP, etc.), then BizTalk will be right to work.