Achieving Messaging Only scenario through Web Services without deploying the receive side web service on BizTalk IIS

In many systems, when we come across a requirement of receiving the request into BizTalk from External Sources through SOAP adapter (at receive side), we generally create a web service for receiving the request and deploy that service in BizTalk IIS. This web service then publishes the input message into the BizTalk MsgBoxDB and then finally the message arrives at SOAP receive location and moves on for further processing. On the send side, there is the actual web service where the message needs to land.

In order to avoid this actual web service creation and deployment on BizTalk IIS, we can use the WCF service behavior feature. To achieve this we only need to make sure is that the input schemas which send side web service is expecting should be deployed on BizTalk.

A graphical representation of the actual scenario is:

Below are the steps to accomplish this: 

1. Open the BizTalk admin console and create a new application “SampleApplication”

2. Create a new one way receive port named “ReceiveRequest”

3. Create a new receive location named “ReceiveSOAPRequest”. Select the transport type as “WCF-Custom” and XMLReceive pipeline.

4. Click on Configure tab which will open the WCF-Custom Transport Properties. On the General tab, type the Address which you want to be browsed (exposed to source) from outside by clients. I have written it as http://<YourServer>/MathServiceTest/MathServiceTest.svc. You can use anything you want.

5. On the Binding tab, select the binding as “basicHttpBinding”.

6. On the Behavior tab, right click on “ServiceBehavior” and Add extension. Then select the “serviceMetadata” from the list.

7. Click on the “ServiceMetadata” on left panel which will show you its properties on right panel. Put the service URL in the “externalMetadataLocation property”. This URL is the one whose input schema is deployed in BizTalk (which is be further invoked) which would look like http://<ServerIP>/BizTalkWcfServiceSchema/Service1.svc. Also, set the httpGetEnabled property to True. This is the destination web service where the message has to be sent.

8. Click OK. This will create a receive location as shown below.

9. Enable the receive location and restart the host instances.
10. Open internet browser and browse the URL which you typed in the general tab above i.e. http://<YourServer>/MathServiceTest/MathServiceTest.svc

Now, you will see that the URL you browsed is directly showing that service, one which you typed into the serviceMetadata.

So, you didn’t even bothered to deploy this MathServiceTest web service into BizTalk IIS and you are actually browsing it. When you pass any message to this service, it will directly land up onto BizTalk receive location and there on you can send that message further to the actual send location.

This may or may not be applicable to your scenario in particular. A front end web service may be required in places, where some business logic needs to be implemented before the BizTalk processing.

Benefits:

1. No requirement of developing a new Web Service for the messaging only scenario.
2. Lower number of Hops as the message directly lands on BizTalk receive location and is not routed through IIS.
3. Reduced Load on IIS.

Limitations:

1. As we are not writing an actual web service, there might be some concerns of Security.
2. May not be always applicable and feasible.

Please do comment if you have come across any scenario where this concept can be applied.

SOA and Web Services

Generally when we talk about SOA, the very first thing that comes to our mind is the web services. Too often, we equate a WebService and its implementation with the overall definition of SOA. In reality it is nothing more than an implementation. A good implementation, but just an implementation. A WebService is platform and language independent and its use of XML enables different platforms to communicate with one another. 

It is not true that every web service is SOA compliant and those Organizations/Companies which implements web services thinking they are implementing SOA, finally end with a total failure.

The world has been implementing SOA long before web services came into existence (you can refer to some case studies of SOA implementation at this link -- Case Studies). Below are few of many protocols which were used to implement SOA:

1. Advanced Program-to-Program Communication (APPC)

Advanced Program to Program Communication or APPC is a protocol which computer programs can use to communicate over a network. APPC is at the application layer in the OSI model, it enables communications between programs on different computers, from portables and workstations to midrange and host computers.

2. Remote Procedure Calls/Remote Method Invocation (RPC/RMI)

A Remote Procedure Call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction. When the software in question uses object-oriented principles, RPC is called Remote Invocation or Remote Method Invocation.

3. Internet Inter-ORB Protocol (IIOP)

IIOP is an object-based protocol and has the potential to massively enhance the types of applications or services or databases that are built and communicate on the web. IIOP provides a comprehensive system through which live objects can request services from one another across the corporate networks over the internet or intranet.

In today's world, when everyone is moving to cloud, the best example of SOA implementation is what Cloud offers as:

A. Software as a Service (SaaS)

B. Platform as a Service (PaaS)

C. Infrastructure as a Service (IaaS)

So, we can say that Web services are just an implementation of SOA but not the only implementation. There are many more examples available on the internet about SOA implementations.