0

According to this BizTalk documentation, the HTTP receive adapter must be in the application (middle) layer. This means BizTalk is limited to a 2-tier architecture, which for modern enterprises is a pretty big limitation.

Is the reverse proxy suggestion that Microsoft recommends (on the link above) the common solution to this problem? Has anyone used any other configuration to use the HTTP receive adapter in the web/perimeter layer and been able to negotiate messages through an application layer?

If the reverse proxy method was used, were existing proxy's in the enterprise used or were dedicated proxy's configured for the solution?

Bee
  • 109
  • 2
  • 11
  • 1
    Why do you think it is an issue? The whole idea behind tiers is that you independent layers. You certainly would not want to use BizTalk as your presentation or Data Layer. But you can have a web site (presentation layer) that calls a web service exposed by BizTalk (application layer) that connects to a database (data layer). Except I wouldn't put too much business logic in BizTalk, so you may even get BizTalk to call another application layer. – Dijkgraaf Nov 14 '17 at 19:25
  • The issue is that Microsoft's recommendation is to forward all HTTP traffic to the middle layer, which I'm sure has inherent security risks and is also different than what you suggest. I think your solution is probably the way to go but I would expect to have an out-of-the-box solution. I'd prefer not to have to create a custom solution on the web layer that delegates requests to BizTalk in the middle layer. All the documentation I have seen on the HTTP receive adapter seemed to assume the service would be called directly from internet/public sources. – Bee Nov 14 '17 at 20:32
  • 2
    At no point does that article you link to mention Middle Layer, Tier or similar concept. It does mention perimeter network (DMZ), data domain & processing domain (FW3), but those are Firewall terms, not 3 Tier ones. It is just telling you to put BizTalk/IIS one layer back from your DMZ and to reverse proxy to the IIS services you want to expose to the external world. – Dijkgraaf Nov 14 '17 at 22:21
  • Thank you for the reply. Ok, so my terms are throwing you off. When looking at [this](https://docs.microsoft.com/en-us/biztalk/core/large-distributed-architecture) diagram, it appears that the suggestion is to have traffic from the internet go straight (the red line) to a BizTalk server on the processing network (which I think of as the 'app layer'). My main question here was just to double check if that is common practice or if something like what you suggested (letting a website be exposed on the perimeter network that calls the BizTalk server in the processing network) is a better option. – Bee Nov 14 '17 at 23:39
  • 1
    These days it is becoming more common practice to expose the web service via Azure Service Bus Relay or API in Azure. But yes, it is was common to expose your BizTalk web service via a reverse proxy with proper security in place. If you place your BizTalk server in the DMZ, you have to poke a lot of holes from BizTalk to your internal systems. – Dijkgraaf Nov 15 '17 at 21:28
  • Ok, that was the answer I was looking for. Azure is not an option since our org is hesitant to adopt cloud solutions in this way. So I guess using IIS in the perimeter as a reverse proxy to the BizTalk Server(s) in the processing network is indeed a secure (enough) and common solution. Thanks. ps:if you want to paste that in an answer response I'll mark it as such. – Bee Nov 16 '17 at 15:16

3 Answers3

2

I believe you are confusing application tiers with network architecture.

BizTalk is almost by definition the middle tier, implying at least a 3-tier solution. There would be the client that calls a BizTalk service, the BizTalk application itself, and some line of business application that contains most of the business logic (and then whatever database/repository that system uses to store its records). There could be more than one line of business application that BizTalk interacts with to process the client request.

The diagram and article you have referenced simply describe how you can use a reverse proxy to grant external clients access to BizTalk HTTP(S) endpoints that are hosted on your internal network.

Todd Hensley
  • 31
  • 3
1

Keep in mind, the "n-tier" thing is pretty much meaningless. An app can be as many tiers as you want to count.

However, in 99.9% of cases, there is no reason to put the BizTalk HTTP host or any other endpoint on the perimeter network.

Depending on local polity, shops will do either port forwarding or inbound proxy (reverse proxy isn't really a thing either ;).

There are absolutely no limits in BizTalk for way to accomplish this. How depends entirely on what your network team allows or prefers.

Johns-305
  • 10,908
  • 12
  • 21
1

These days it is becoming more common practice to expose the web service via Azure Service Bus Relay or API in Azure. But yes, it is was common to expose your BizTalk web service via a reverse proxy with proper security in place. If you place your BizTalk server in the DMZ, you have to poke a lot of holes from BizTalk to your internal systems, which is what you want to avoid.

Dijkgraaf
  • 11,049
  • 17
  • 42
  • 54