Tag Archives: SOA

Can’t See The SOA For The Clouds

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.

The API Gateway As Endpoint

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.

How to Choose a SOA Gateway

Dana Crane, Product Marketing Manager for Layer 7, is delivering a webinar this Thursday January 27 that tells you what you should consider when choosing a SOA Gateway. The SOA gateway category is a little like an iceberg, in that there is a lot more to it than first meets the eye. Here at Layer 7, we find that customers first become interested in SOA Gateways as a means to solve their security and transaction management problems. But they quickly discover that SOA Gateways can easily function as an Enterprise Service Bus (ESB), a service orchestration engine, a lightweight PKI system, a Security Token Service (STS), and even a service host for applications. We have a number of customers who have been able to discontinue expensive maintenance contracts on basic infrastructure applications simply because their SOA Gateway was able to meet all of their needs.

I hope you can join my colleague Dana later this week and learn more about what you need to look for in an SOA Gateway solution. Dana is one of the best product guys I know. He really understands the needs of the marketplace, and he keeps all of us here at Layer 7 honest. You can sign up for Dana’s webinar on the Layer 7 web site right here.

Why Health Care Needs SOA

A recent article in DarkReading offers a powerful argument as to why the health care sector desperately needs to consider Service Oriented Architecture (SOA). In her piece Healthcare Suffers More Data Breaches Than Financial Services So Far This Year, Erika Chickowski cites a report indicating that security breeches in health care appear to be on the rise this year, with that sector reporting over three times more security incidents than the financial services industry.

I worked for many years in a busy research hospital, and frankly this statistic doesn’t surprise me; health care has all of the elements the lead to the perfect storm of IT risk. If there is one sector that could surely benefit from adopting SOA as a pretext to re-evaluate security as a whole, it is health care.

Hospitals and the health care eco-system that surround these are burdened with some of the most heavily siloed IT I have ever seen. There are a number of reasons why this is so, not the least of which is politics that often appear inspired by the House of Borgia. But the greatest contributing factor is the proliferation of single-purpose, closed and proprietary systems. Even the simplest portable x-ray machine has a tremendously sophisticated computer system inside of it. The Positron Emission Tomography (PET) systems that I worked on included racks of what at the time were state-of-the-art vector processors used to reconstruct massive raw data sets into understandable images. Most hospitals have been collecting systems like this for years, and are left with a curiosity cabinet of samples representing different brands and extant examples of nearly every technological fad since the 1970s.

I’m actually sympathetic to the vendors here because their products have to serve two competing interests. The vendors need to package the entire system into a cohesive whole with minimal ins and outs to ensure it can reasonably pass the rigorous compliance necessary for new equipment. The more open a system is, the harder it is to control the potential variables, which is a truism also in the security industry.  Even something as simple as OS patching needs to go through extensive validation because the stakes are so high. The best way to manage this is to close up the system as much as reasonably possible.

In the early days of medical electronics, the diagnostic systems were very much standalone and this strategy was perfectly sound. Today, however, there is a need to share and consolidate data to potentially improve diagnosis. This means opening systems up—at least to allow access to the data, which when approached from the perspective of traditional, standalone systems, usually means a pretty rudimentary export. While medical informatics has benefited some from standardization efforts, the medical systems still generally reduce to islands of data connected by awkward bridges—and it is out of this reality that security issues arise.

Chickowski’s article echos this, stating:

To prevent these kinds of glaring oversights, organizations need to find a better way to track data as it flows between the database and other systems.

SOA makes sense in health care because it allows for effective compartmentalizing of services—be these MRI scanners, lab results, or admission records—that are governed in a manner consistent with an overall security architecture. Good SOA puts security and governance upfront. It provides a consistent framework that avoids the patchwork solutions that too easily mask significant security holes.

A number of forward-looking health providers have adopted a SOA strategy with very positive results. Layer 7 Technologies partnered with the Universitry of Chicago Medical Center (UCMC) to build a SOA architecture for securely sharing clinical patient data with their research community. One of the great challenges in any medical research is to gather sample populations that are statistically significant. Hospitals collect enormous volumes of clinical data each day, but often these data cannot be shared with research groups because of issues in compliance, control of collection, patient consent, etc. UCMC uses Layer 7’s SecureSpan Gateways as part of its secure SOA fabric to isolate patient data into zones of trust. SecureSpan enforces a boundary between clinical and research zones. In situations where protocols allow clinical data to be shared with researchers, SecureSpan authorizes its use. SecureSpan even scrubs personally identifiable information from clinical data—effectively anonymizing the data set—so that it can be ethically incorporated into research protocols.

The UCMS use case is a great example of how SOA can be a protector of information, promoting the valuable use of data while ensuring that only the right people have access to the right views of that information.

To learn more about this use case, take a look at the detailed description available on the Layer 7 Technologies web site.

eBizQ: SOA in This Year and the Next

It’s that time when we look back on one year and forward to the next. Over at the eBizQ forum Peter Schooff asked about SOA’s past and future:

What Developments in SOA Are You Most Thankful For This Year?

What Do You Think Will be the Biggest Trend or Development for SOA in 2010?

eBizQ Forum Question: Is Service Reuse Overrated as a Value Proposition for SOA? Does Reuse Even Work in Real-Life Situations?

Ah, the reuse question. My thoughts are here.

eBizQ Forum Question: Do You Think the Pervasive Use of Cloud Computing Will Expand or Contract the Use of SOA?

My answer is here.