January 25, 2011
Two weeks ago, I posted about SOA Gateway trends that have been emerging lately. If you are interested in this topic or if you are in the process of setting up an SOA infrastructure, you will not want to miss tomorrow’s (Jan 27, 2011) webinar : “How to Choose a SOA Gateway: Lessons from the Field”. This will cover topics such as Portability Considerations, Scalability Risks, Extensibility and Upgradeability, Global Management Implications and Hidden Operation Costs.
Register for this webinar here.
January 24, 2011
We’ve been getting a number of field requests lately for handling case insensitive URLs. That is, resolving something like http://foo/blah the same way as http://foo/Blah and any other case mutation. Of course, URLs are meant to be case sensitive by definition (not the scheme and host parts but the URI and query). This is standardized by W3C and mostly respected except for a few rogue implementations (we’re looking at you IIS).
In an upcoming service pack for version 5.4 of our SOA Gateway and subsequent releases, we are introducing a number of additional controls pertaining to service resolution. One of them lets the administrator change the default behavior of the Gateway so that resolution paths are matched ignoring case. This simplifies the process of accommodating requesters that are not URL “case-aware”, and mediating between services which respect this aspect of URLs and services which do not.
What I find most interesting however, is how our users, support team and field engineers have been using our technology until now to accommodate such requirements. Using our sophisticated and fine-grained resolution subsystem, some users register a “/*” endpoint to catch all messages that do not get explicitly resolved to other published services (for example because of character case mismatch). Once in this “/*” policy, you can feed the incoming URL into a simple XSLT which produces a lowercase version of the URL, then circle the request back to the Gateway using the resulting URL so that the intended service gets invoked. This is pretty straightforward.
A catch-all policy is great at processing traffic which is not expected at design time and doing something useful with it. However, the use of wildcard characters in service resolution parameters is not limited to setting up a catch-all policy. You can publish services with such resolution patters to handle in a single policy, requests following a common pattern. For RESTful web services, such resolution parameters are essential such as illustrated in this tutorial.
Flexible and customizable service resolution patterns have always been a key ingredient in sophisticated service mediation and complex routing rules. Look for advancements in this area and more in v5.4 service pack 1 of the Layer 7 Gateway solution.
January 10, 2011
It has been fascinating to witness how the use for SOA gateways evolved over time. In 2010, we saw an explosion of market demand for our gateway appliance product. Here are my thoughts for what I expect to see this year and beyond.
Recent use cases for these types of devices largely focused on B2B interactions and internal enterprise integration. Many enterprise architects realized the benefits of using the lightweight ESB-in-a-box deployment model and gateway-based integration. I don’t think we’ve hit the peak of this type of use case. I expect the demand for quickly deployed integration, and a preference for “configure, not code” to continue to accelerate in 2011. The cost and complexity involved in deploying full-blown software-based ESB stacks is becoming well known and the alternative provided by best of breed SOA gateways with their out of box support for existing enterprise standards will continue to gain popularity.
Another source of momentum for SOA gateways is the enterprise adoption of cloud computing. As the enterprise gradually moves some of its IT assets from on-premise to a cloud-based deployment model (SAAS, PAAS or IAAS), the requirement for integration between these IT assets does not simply vanish. Integrating your IT assets is as important in 2011 as it was back when they were all deployed in your own domain. Cloud computing adoption is currently limited by the ability of the enterprise to securely integrate on-premise and off-premise. And what better way is there to enable this secure integration than perimeter deployed SOA gateways? The SOA gateway acts as the glue between your on-premise IT assets and external services that they interact with. Concretely, this means support for federation and trust management. Your SOA gateway at the perimeter is enabling the trust management for the various external domains you interact with and presents a homogenous identity authority on behalf of your existing services. Utilizing the federation capabilities of SOA gateways with support for SAML, OAuth and other relevant standards is increasingly recognized as a winning pattern for integrating enterprise and cloud.