CODEWITHSUNDEEP
proxybiztalkreverse-proxy3-tierbiztalk-2016
Bee
Bee

Reputation: 117

3-Tier BizTalk Architecture Possible?

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?

Upvotes: 0

Views: 319

Answers (3)

Dijkgraaf
Dijkgraaf

Reputation: 11527

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.

Upvotes: 1

DTRT
DTRT

Reputation: 11040

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.

Upvotes: 1

Todd Hensley
Todd Hensley

Reputation: 31

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.

Upvotes: 2

Related Questions