Ways to Access On-Premise LOB systems from Azure Applications

Access On-Premise resources from Azure

Bhonhariya, Salim (Cloud Architect)

1/16/2015

1

ContentsScenario 1: Service Bus Relay......................................................................................................................2

Scenario 2: Biz Talk Services Hybrid Connections........................................................................................2

What is similar?...................................................................................................................................3

What is different?................................................................................................................................3

Thoughts so far....................................................................................................................................4

Scenarios where I would I use Hybrid Connections.............................................................................4

Scenarios where I would use Service Bus Relay..................................................................................4

Scenarios where I could use either......................................................................................................5

Thoughts for the Future.......................................................................................................................6

Scenario 3: Service Bus queues...................................................................................................................6

Scenario 4: Custom SB-Messaging Adapter & ESB Toolkit...........................................................................7

Scenario 5: Integrate BizTalk Server 2010 / 2013 with Service Bus for Windows Server.............................7

Scenario 6: Windows Azure BizTalk Services:..............................................................................................7

Scenario 7: Express Route...........................................................................................................................8

Accessing LOB systems from Mobile devices using Azure Mobile Services.................................................9

2

Scenario 1: Service Bus RelayAzure Service Bus Relay is a cloud based service which allows you to host an endpoint in the cloud, Azure will use a port forwarding technology to forward messages received from a client to the listening service implementation which is usually hosted on premise. Service Bus Relay is intended to allow you to bridge from any application hosted in the cloud of on another data center to bridge through to your on-premise services. You simply use the ACS to provide a client access.Let’s take a look at Service Bus Relay.

Scenario 2: Biz Talk Services Hybrid ConnectionsHybrid Connections is a feature in Azure BizTalk Services which allows you to connect Azure Websites and Azure Mobile Services to on-premise resources “as if they are on the same private network”. To do this you create a hybrid connection and then pair it with your cloud resource. On premise you would install a software agent which will open up a connection to the cloud and you can configure the hybrid connection to be able to then connect to an on premise resource such as a database. Your application in the cloud would then be able to connect to the database as if it’s in the same data centre except that the connection string will be modified so that the connection is routed via the BizTalk Hybrid Connection.

3

Let’s take a look at Hybrid Connections.

What is similar? Below are some of my thoughts on the similarities on these two products: Both products support firewall friendly approach to bridge from cloud to on premise Both products open outbound connections from on premise to receive messages. No inbound

ports are required to be exposed from your data centre Both products are quite easy to use Both products have relatively straight forward infrastructure requirements

What is different?

Below are some of the differences between Service Bus Relay and Hybrid Connections:

Service Bus Relay only supports a WCF based listening service which uses the WCF relay bindings where as Hybrid Connections uses its on premise listening agent allowing it to connect to a target via any port which can include a WCF or REST service bus also many other applications such as a database

Service Bus Relay supports ACS security where as Hybrid Connections support SAS for the cloud hosted endpoint. (Note according to MSDN service bus relay is expected to support SAS sometime in the “near future”)

The Service Bus Relay endpoint only exists when the listening service comes online where as the hybrid connections endpoint is created in the cloud as a configured service before the agent is listening

4

Hybrid Connections provides an agent which can be installed on an on-premise server which can then connect to on premise assets. Service Bus Relay does not provide any software to install and you need to configure your own listening component or configure a WCF Service to use a Relay binding.

Service Bus Relay can only support clients which can talk web services and are able to retrieve an access token from ACS, Hybrid Connections can support interop with non .net technologies

Hybrid Connections can only be consumed by a resource hosted in the cloud such as an Azure Website where as Service Bus Relay can be consumed from a resource hosted outside of Azure such as from a partners data centre

Hybrid Connections requires the BizTalk Services feature in Azure which also gives you some more integration features but also includes a higher cost. Service Bus Relay is a smaller feature within Azure and is currently lower cost

Thoughts so farAt this point my thoughts about the new hybrid connections product is that although there is a lot that’s similar between the two products and they do have some overlaps there are also some significant differences between the products two. Hybrid Connections works at a lower level in the stack working with ports and connectivity and not really caring about the data where as Service Bus Relay is at a higher level, working in the WCF stack meaning there is a greater awareness around how the protocol needs to work which provides some limitations and some benefits.

I think there are likely to be some use cases where the products do not compete with each other because of the different features they offer, but there will also be scenarios where both products could be used and then it becomes a case of which is the right one for your situation. You need to think about simplicity, what your developers are used to, cost, support aspects and lots of other things.

I expect that the net result the introduction of Hybrid Connections would be that the number of scenarios Service Bus Relay is used in would reduce because sometimes Hybrid Connections might be a more appropriate option and perhaps the way we tend to use Relay may change a little.

Scenarios where I would I use Hybrid ConnectionsI think that the following list of items would be scenarios where Hybrid Connections are likely to be a better choice:

The client is hosted inside of Azure You want to integrate directly with a resource, which is not hosted in WCF. Eg: you want to

connect directly to a database The client wanting to connect to the resource is not able to talk WCF and perhaps isn’t even a

Microsoft technology You want to create a point to point tightly coupled connection from a cloud resource to an on

premise resource I am already using Hybrid Connections in my architecture and the integration pattern matches

the patterns I already use it for

Scenarios where I would use Service Bus RelayI think the following list of items would be things would be scenarios of requirements, which would indicate service bus relay would be the only choice you could use:

The client is hosted outside of Azure

5

The client is hosted on a resource in Azure which is not supported by Hybrid Connections (see documentation for more info)

You want to connect your WCF service directly to the cloud rather than having an on-premise man in the middle style agent installed

I am already using Service Bus Relay in my architecture and the integration pattern matches the patterns I already use it for

Scenarios where I could use eitherFor both products there are some clear requirements or constraints where one is more favorable than the other or one product simply wouldn’t be an option, but it will be very common that you could choose either product. This scenario is going to involve invoking WCF Services on premise from a resource in the cloud.

With Service Bus Relay you would connect your service to the relay using the WCF relay bindings and then call it using a WCF client or alternatively with Hybrid Connections you would install the on premise agent software and pair your hybrid connection with the cloud resource so you could then call the WCF service as if your local to it.

I think at this point the architecture decision comes down to your strategic use of these products. If your already a service bus relay user and are happy with it then your probably unlikely to migrate as there aren’t that many features with Hybrid Connections which would give you a big benefit versus what you might get with Service Bus Relay. Perhaps with it being a BizTalk Services feature you might get a monitoring story, which might be richer than what you get with Service Bus Relay.From a security perspective there are some differences between the products, which are important to note. The first is the different support for accessing the endpoint. If you use hybrid connections then it uses SAS but this is abstracted from the consuming technology. Using Service Bus Relay you need to use ACS. This means your client needs to be able to get an ACS token via WCF bindings or REST. Even after you are authenticated to the endpoint there are also some differences. With Hybrid Connections you’re talking to a service at a port level. This means that you can connect to any service exposed at that address and on that port. If we are bridging through to an IIS server we would be able to get to all WCF services in this WCF component on that port. If you have multiple WCF Services hosted on the same port then this could be a problem. There may be some application specific security but from a connectivity perspective we can reach all services. With Service Bus Relay things are slightly different, you are able to configure the service to only use specific WCF services to open an endpoint in the cloud. This might be important if you only want to expose a subset of your services to the cloud.Some of the common scenarios where a customer would expose WCF services to the Azure Service Bus Relay also includes using the WCF routing service to act as the on-premise listener which opens a connection to the cloud via the WCF relay bindings. This means the customer does not need to modify their existing WCF services to include the new binding. The customer then uses the WCF routing service to be the on premise listener which can then route requests to multiple on premise applications based on the soap action. This is quite a good pattern to provide a simple way of exposing services but you can also expand the usage to multiple applications without connecting all of the applications directly to the cloud themselves. This pattern could also be implemented with hybrid connections but this would require the installation of the software agent for hybrid connections on premise in front of the WCF routing service then the rest of the pattern would work as previous. I think customers would tend to be put off this approach with it seeming to add extra un-necessary hops.

6

Finally in the scenarios where you could use either product I think cost will be a key factor. One of the bits of feedback from the community previews of hybrid connections is that requiring a BizTalk Services package makes hybrid connections significantly more expensive than Service Bus Relay when you consider the usage across multiple test environments and then production. I’m sure Microsoft will use this feedback and create a better pricing model for hybrid connections because it makes sense that it should be a bit more expensive than Service Bus Relay but it should be purchasable in a cloud friendly usage based model which would make it more competitive than it is now.

I think once the costing is more balanced the decision for scenarios where both products are usable will boil down to these key factors:What do you do already (if anything) for this kind of patternWhat ports do you need to useDo you want a tightly coupled point to point integration channel or do you want to be able to have a routing pattern and to take advantage of some of the WCF features

 Thoughts for the FutureHybrid Connections is a really exciting new technology but I think that it will also help to drive improvements for Azure Service Bus Relay. I expect that the number of scenarios where customers use Azure Service Bus Relay will reduce to some degree. For many users the Hybrid Connections approach could make things simpler. One of the things id like to see would be some extensions to Azure Service Bus Relay such as the ability to install an on premise agent which hosts the WCF routing service and is able to take routing configuration from the cloud. This will make connectivity setup and configuration simpler and mean that a customer doesn’t need to support their own component to do this role. Overall the number of customers able to do hybrid connectivity in a simple way is going to increase and that’s a great thing.

Scenario 3: Service Bus queuesService Bus queues are a general-purpose technology that can be used for a wide variety of scenarios:

Communication between web and worker roles in a multi-tier Azure application Communication between on-premises apps and Azure hosted apps in a hybrid solution Communication between components of a distributed application running on-premises in

different organizations or departments of an organizationUsing queues can enable you to scale out your applications better, and enable more resiliency to your architecture( http://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-queues/)

7

Scenario 4: Custom SB-Messaging Adapter & ESB ToolkitBizTalk Server 2013 R2 introduces the SB-Messaging adapter to send and receive messages from Service Bus entities like Queues, Topics, and Relays. You can use the SB-Messaging adapters to bridge the connectivity between Windows Azure and on-premises BizTalk Server, thereby enabling users to create a typical hybrid application.( http://social.technet.microsoft.com/wiki/contents/articles/22644.using-the-sb-messaging-adapter-esb-toolkit-to-send-messages-to-the-windows-azure-service-bus.aspx)

Scenario 5: Integrate BizTalk Server 2010 / 2013 with Service Bus for Windows ServerThis solution shows how to integrate a BizTalk Server 2010/2013 application with Service Bus for Windows Server using the WCF-Custom adapter to exchange messages with external systems in a reliable, flexible, and scalable(https://code.msdn.microsoft.com/How-to-integrate-BizTalk-07fada58)

Scenario 6: Windows Azure BizTalk Services: Integrating with on-premises LOB systems using the BizTalk Service Services(http://www.neudesic.com/blog/windows-azure-biztalk-services-integrating-premises-lob-systems-using-biztalk-adapter-services/) andHybrid Scenarios using BizTalk Adapter Servicehttp://blogs.msdn.com/b/biztalk_server_team_blog/archive/2013/06/28/hybrid-scenarios-using-biztalk-adapter-service.aspx

8

Scenario 7: Express RouteBuild hybrid applications with predictable, reliable and high-throughput connections offered by ExpressRoute, you can build applications that span on-premises infrastructure and Azure without compromising security or performance. For example, you can have your corporate intranet application running in Azure that authenticates users using an on-premises Active Directory, and serve all corporate users without traffic ever routing through the public Internet.

9

Accessing LOB systems from Mobile devices using Azure Mobile Services