I have been in several different shops that are either deploying DataPower or are a few years after deploying DataPower. I’ve also had opportunities to talk to numerous different DataPower technical resources about how they have utilized DataPower. In the post, I want to describe what I’ve seen as the three typical internal DataPower architectures. Everything I’ve seen falls into one of these three buckets. I doubt that its true of every DataPower shop, but it seems to be a good rule of thumb. If you are trying to figure out where to start with designing/deploying your application as a DataPower developer, then this article should be a good read.
The three internal Datapower designs that I often encounter for large DataPower deployments are:
- A layer of WS-Proxy objects behind a single HTTP(S) FSH.
- A layer of WS-Proxy objects behind a single Multi-Protocol Gateway
- A single Multi-Protocol Gateway that reads a configuration file that determines Service Mediation logic to be applied, routing, security, etc.
These three architectures/designs are by no means the only way to use DataPower, but I’ve found that they serve as a starting point when building a new, large DataPower environment/application.
This diagram depicts two or more WS-Proxy objects behind an HTTP(S) FSH object.
This diagram depicts an MPG in front of a layer of WS-Proxy objects.
This diagram depicts a single MPG in a configuration-driven architecture.
Using a WS-Proxy tends to be easy to setup. Simply giving DataPower the WSDL is enough to setup a simple pass-thru proxy. It also automatically configures XML Threat Protection, Schema Validation, and the remote URL (routing). The rest has to be setup manually.
Unfortunately, WS-Proxy objects behind a single HTTP(S) FSH have had scalability issues in the past. This is easy enough to over come by putting an MPG in front of the WS-Proxy objects (and giving each WS-Proxy its own FSH).
Having many WS-Proxy objects can be human resource intensive and time consuming to maintain. This gives rise to the configuration-driven architecture built within a single MPG. This can simplify management, but also adds a fair amount of complexity. This single MPG can advertises many SOAP Web Services and implement the same functionality as a WS-Proxy.
Also, there are limits to how many objects you can have in a single Application Domain. The configuration-driven architecture depicted in the third diagram helps address this issue.
If you are only deploying a couple of services, you can just setup a single FSH and a single WS-Proxy object.
If you have many services to deploy and don’t mind creating many load balancer farms and firewall rules, you can simply add more TCP ports and HTTP(S) FSH objects. This will spread the services and WS-Proxy objects across more FSH objects. While this approach may be easy to implement on the DataPower side, your company’s security and network engineer’s will probably looking unfavorably upon it.
I’m refraining from giving a deeper analysis of the pros and cons of these various approaches here. If you’d like more information, I can be contacted for consulting engagements
.