August 5th, 2011

Can’t See The SOA For The Clouds

Written by
Category Cloud Computing, SOA
 

It has been quite a week for SOA. First, TheServerSide published a presentation delivered at their recent Java conference by Rod Johnson from VMware in which he essentially accused SOA of being a fad. Normally this is the kind of comment people would overlook; however, Rod, who is SVP, Middleware and GM of the SpringSource division at VMware, is very well regarded in the Java community, so his comments certainly carry weight.

First to cry foul was Dave Linthicum writing in Infoworld, who made the important point that “SOA is something you do” whereas “cloud computing is a computing model.” Joe McKendrick at ZDnet quickly followed up, adding that “too much work has gone into SOA over too many years at companies to relegate it to “artificial fad” status.“

To be fair to Rod, his actual statement is as follows:

If you look at the industry over the past few years, the way in which cloud computing is spoken of today is the way in which SOA was spoken of four or five years ago. I think with respect to SOA, it really was a fad. It was something that is very sound at an architectural practice level, but in terms of selling product, it was really an artificial, marketing created, concept.

And in many ways, it is hard to disagree with him. As a SOA vendor, I’m as guilty as anyone of… um… perhaps being overly enthusiastic in my support of SOA. So it’s perhaps not surprising that it would all lead to an eventual backlash. Anne Thomas Manes was certainly the most effective at calling us all out a few years ago.

Putting hype cycles behind us though, it would be a shame to miss the real impact that SOA has had in the enterprise. I would argue that SOA is in fact a great success, because while the term may have gone out of fashion, we have absorbed the ideas it described. I don’t need to write about the vision of SOA anymore; my customers seem to know it and practice the concepts without calling it such. And I don’t seem to need to evangelize my own SOA products the way I once did, simply because people accept SOA Gateways as the architectural best practice for run time governance.

This seems to be supported by an article Forrester analyst Randy Hefner published in CIO later in the week. In it, he describes the results of a survey they conducted earlier in the year. Randy writes:

organizations that use SOA for strategic business transformation must be on to something because they are much more satisfied with SOA than those that do not use SOA for strategic business transformation.

Randy’s report examines the use of SOA—apparently in its full three letter glory—as a tool to transform business. It’s a good article because he manages to distill so much of the theory and hand waving that turned people off into some concrete, prescriptive actions that just make sense.

He closes with this insight:

SOA policy management is an advanced area of architecture design, and policy-based control of services is the business-focused SOA practice that takes the greatest amount of SOA experience and expertise. Forrester first published its vision for SOA policy management three years ago, knowing it would take a while to mature in the industry, and indications are that interest in SOA policy increased significantly this year over previous years.

Given my own experience over the last year, I would agree entirely, and suggest that we are there.


March 30th, 2011

The API Gateway As Endpoint

Written by
Category API, Security, SOA
 
The US Customs and Immigration station at Point Roberts is a small building set on the edge of the coastal rainforest of Washington State. It is the last customs station in a vast western chain strung out along the 49 parallel. I enjoy crossing the border at Point Roberts. The abrupt change from sprawling Canadian suburbs to American rural countryside always appeals to me. The customs station, despite it’s small size, offers a range of services from granting a visa to simply giving advice about where to find a good deal for gas in Point Roberts. It’s not simply a gateway controlling access into the US, but a provider of a broad range of services associated with crossing an international boundary. There exists a similar duality with API gateways. Although the common deployment is as a border guard, protecting APIs hosted by an organization, an API gateway can also act as an endpoint providing valuable standalone services. Nearly all of my customers first purchase SecureSpan Gateways to fulfill the role the name implies: that is, an API or service gateway. The border guard deployment pattern is now so commonplace that I no longer need to evangelize it as I did in the early days of Layer 7, close to a decade ago. Architects recognize this pattern as an accepted best practice for securing and managing APIs. But like the Point Roberts border station, a SecureSpan Gateway can also provide services that have nothing to do with access control or transaction confidentiality, but provide value on their own, independent of any APIs they may be guarding. Here’s a very simple example illustrating the endpoint pattern using a SecureSpan Gateway. Normally I might deploy my gateway in front of a web server, acting as an authenticating reverse proxy for my web pages. In this role, the gateway is responsible for access control, SSL management, audit, lightweight load balancing, etc. All classic gateway functions. Figure 1: Gateway as boarder guard at the edge of a network. This is classic perimeter security. But suppose I wanted to use the gateway itself as the web server? In other words, it’s not acting as a gateway, but the server endpoint in itself? Figure 2: Gateway as service endpoint. Here the gateway is providing valuable APIs on its own without necessarily routing a request to an internal host. It’s very simple to configure a SecureSpan Gateway as an endpoint. You simply create a policy that never routes a request onward to an internal host, but instead acts on the message content internally. I sometimes think of it as an internal loop back mechanism. I’ll build a policy implementing my web site, and add the assertion Return Template Response to Requester. I will bind this policy to the gateway URL http://localhost:8080/helloworld as shown in the screen snippet below from the SecureSpan management console: With just one assertion, this is pretty much the simplest policy you can write, and so fitting for the time-honoured Hello World example. Let’s expand the assertion to examine at what the template actually contains: Pretty plain-vanilla HTML. The only departure I’ve made from the deliberate austerity of the Hello World tradition is to add a time stamp to showcase the use of predefined context variables. There are dozens of context variables that are automatically set as the gateway processes a transaction (regardless of whether it’s actually being a gateway or an endpoint—remember we consider this just a policy implementation pattern, not a different capability). Context variables cover everything from accessing individual fields in the X509 certificate used for client-side SSL authentication to storing the IP address of a request sender. And of course, you can set your own context variables at any time within a policy. Just to be complete, here’s what happens when I point my browser at the gateway-as-endpoint: Now, before you think I’ve gone mad, I am not advocating that you deploy a web site like this; there are much better tools for that purpose. But the point I’m making is that there are legitimate endpoint services that do indeed lend themselves to implementation on a gateway. These are just a little more complicated than what I’ve shown here, but nevertheless simple to implement using the declarative policy language in SecureSpan. For example:
  • Signing Services: In the notary pattern, a gateway with an on-board Hardware Security Module (HSM) responsible for protecting key material can easily provide authoritative signing services for all kinds of data, from XML documents to arbitrary text.
  • Encryption Services: Same idea as signing, with the goal to avoid insecure proliferation of keys.
  • Validation Services: Ensure data conforms to a particular schema.
  • Threat Detection Services: Scan content for SQL injection, Cross Site Scripting (XSS), XML threats, or custom threat signatures.
  • Security Token Services (STS): Issue security tokens like SAML or OAuth tokens. Validate or exchange tokens.
  • Centralized Session or Caching Management: Cache frequently used data items according to a scheme that is tuned to your application.
  • Policy Decision Point (PDP) Services: Receive and act on SAMLP requests.
  • XACML Services: Act as a centralized XACML engine providing authorization services.
The list above is by no means exclusive; however, at Layer 7 we’ve implemented all of these at one time or another using SecureSpan Gateways. It’s an important design point for us that the only real difference between a gateway and an endpoint is how you define your policy.