Infosys Microsoft Alliance and Solutions blog

« .NET Framework 4.0 CLR Enhancements | Main | Silverlight and Matrix Transformation »

Enterprise systems available on the cloud as services

Suppose an enterprise has a set of services that it feels can be exposed to the internet for business or for its own usage, there are two ways to address it.

1) Setup the services on a DMZ thereby exposing the services in a secure manner to the internet.
2) Open up ports on the enterprise firewall to allow inbound access from outside machines to the services running. [This is not allowed as it has the potential to allow users to exploit the enterprise network]

The first mode of setting up a DMZ is the preferred way, but its limitation would be allowing access of DMZ machines onto the enterprise network. If the DMZ needs to access internal systems like a Mainframe, then there could be deployment and security issues.

The Microsoft .NET services (or the BizTalk Services as it was previously called) allows enterprises to expose their services to the internet from within a firewall without having to setup a DMZ or allow explicit inbound access to the machines. It used the concept of Relay Binding (extension over the existing WCF) to allow access to the services. Allowing disparate systems to be interconnected through the internet, the .NET services sets up an internet service bus in the Microsoft cloud. 

Some of the offerings of .NET Services are:
1) Access Control Services or  Identity Services: it is a hosted service that enables enterprises easily manage its users supporting user identities from various organizations

2) Connectivity Services: These services make connectivity between services in different enterprises feasible. We could host a service from within Infosys Firewall and it could be consumed by a customer in another enterprise or on the internet. It allows enterprises to expose services through the .net services as a URI which is accessible over the internet. In practice, the actual URL and Machine of the service is hidden from the client applications.

3) Workflow Services: A new addition to the .NET services, it allows execution of Windows Workflow Services that orchestrate the interactions between other services hosted via the ISB.

4) .NET framework extensions that allow connecting to the ISB through applications
 
The Connectivity Services relies on using RelayBinding 

ISBRelay.jpg

Applications that need to use connectivity services establish outbound connections (allowed by enterprises) to the service bus. This would be done by both the sending as well as receiving applications. 

When an application listens on an endpoint, it automatically polls the Connectivity Service to retrieve incoming messages. In a simple example, suppose applications in two distinct enterprises send and receive messages through the WCF framework and APIs. Enterprise A establishes an outbound connection to the Connectivity Service, and begins listening on an endpoint, defined by the URI labs.biztalk.net/enterpriseA/someapp.  Enterprise B also establishes an outbound connection to the Connectivity Service, and sends a message to the same URI. The Connectivity Service receives the message, and relays it to the application in enterprise A, via its already open connection. The SDK simplifies developing applications that use the .net services, and enables existing applications to use the service bus without modifications.

In cases where Direct connection is possible, the service bus would first establish a relay connection and then make a direct connection between the applications. The connectivity service internally calls the identity services to authenticate the users. The steps to start working on service bus are.
1) Create an account on the http://labs.biztalk.net site.
2) Download the .net services SDK and install it on the machine.
3) If the machine is within a firewall then open outbound connections to 65.55.22.* and 65.22.20.* IP range over the following ports 808, 809, 818 and 819. Install the Winsock client so that access to the BizTalk service machines is available. [This is required because the relay mechanism internally uses TCP connections to ensure connectivity with the Service bus]. Now we are set to start using the sample applications.

There are many sample applications available in the SDK that showcase the various abilities of the Service bus like Relay connection, multicast, Direct connection, Http based file sharing and Workflow. The .NET services offer a simple way for enterprises to share their services across the internet without having to put them on a DMZ or another hosting service. This blog from Clemens Vasters has a good amount of information about .NET services. 

Comments

I am trying to run the downloaded SDK samples for Azure. Its from service bus samples. whenever I try to run my service, it gives me following error,

{"Could not connect to net.tcp://servicebus.windows.net:828/services/haSolution/EchoService/. The connection attempt lasted for a time span of 00:00:21.1043294. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 65.55.54.16:828. "}

Any pointers in this regard will be of great help.

Thanks.

Are you trying to run the sample from your home or office network?
Check if you can establish a telnet connection on to 65.55.54.16:828. Usually if your internet access has been filtered, say through the use of a firewall in your office network, this connection will not be able to established.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter