Thursday, November 27, 2008

SOA around the World

Is SOA universally deployed around the world? Saul Caganoff at the SOAbloke blog looks at the figures from the recent Gartner survey:

SOA Adoption shows considerable geographic disparity. Europe has almost universal adoption (70% currently using), followed by North America (55% currently using) then Asia (25% currently using). The majority of organizations in Asia have no plans to adopt SOA. The report doesn’t really analyse why Asia has such low SOA adoption. My guess would be a combination of factors including lack of SOA expertise in the region, the characteristics of Asian companies being late technology adopters and the preponderance of manufacturing in the region which the survey shows has overall low SOA adoption compared with other sectors.
http://www.soabloke.com/2008/11/06/gartner-2008-soa-user-survey/

Those figures ring true. The Vordel Customer Case studies section on the Vordel website contains a selection of case studies from around the world, and you can see the spread does tally with the figures (though, we do have deployments in Malaysia, Mozambique, the Middle East, and other places which are not "pinned" on the Google Map, because many customers want to be confidential).



On the puzzling "Asia question", ZDNet Asia quotes a study by Springboard Research, an analyst firm based is based in Singapore. Michael Barnes, the vice president of software research at Springboard Research, says that:

The adoption cycle for SOA in the Asia-Pacific region is going through the natural maturation process typical of most IT-related markets.

Barnes said SOA initiatives have seeped into organizations in less direct ways. "We find that SOA initiatives here are less a specific objective or design point and more of an approach that has quickly become an integral part of other IT projects, such as new application development, business process management, and application and data integration," he said.

Springboard's survey noted the biggest reasons for SOA adoption in the region are application integration and data integration, as well as reducing the time and cost of delivering new services.

I think that the real geographic difference is not SOA adoption itself, but at what point do you say you are adopting SOA. I've seen many cases where an organization will use SOA techniques (reusable services) as "an approach", as Michael Barnes from Springboard says above, in a particular IT project. This approach may come from vendor tools which make it straightforward to create a Web Service, expose the service, perhaps register the service also, and call the service from a browser or from a client application. In most cases the service will be plain-XML (not SOAP) or REST. In the case of REST, it is more likely to be described as simply "calling the application from a browser". Then, the "approach" of SOA becomes "an integral part of other IT projects, such as new application development, business process management, and application and data integration", as Michael Barnes says above.

That is starting to sound a lot like SOA... But when do you say "Hey we're now doing SOA". I think that is the big geographical difference. In Europe, where there is more of an appetite for architectural "grands projects" (the most obvious being the EU itself), this is most likely to happen. In the US, there is still a virtue in simple integration projects, not quite "hacks" but still simple and elegant. Simple XML or REST based integration fits into that thinking, while "SOA" sometimes seems like a kind of "big government" architecture-for-the-sake-of-architecture. In Asia, I agree with the Springboard Research study that underlying SOA approaches are being used in integration projects, without the architectural fanfare.

So, I think the difference isn't about SOA adoption itself, but the point at which an organization says "We're now doing SOA". Often an organization will happily be using services-based integration (especially with XML and REST) quite happily, thank you very much, but if asked will say "We're not doing SOA".

To see for yourself, check out the Vordel Customer Case studies section to read about projects around the world (US, Canada, Brazil, Ireland, UK, Netherlands, Spain, Australia).

Friday, November 14, 2008

CSI 2008 next Monday near Washington DC

The CSI 2008 conference takes place next week, in National Harbor, Maryland, which is just down the Potomac from DC. You can see the convention center, all shiny and new, on the right as you fly into DCA. Conference Expo passes (including free access to two sessions) were free on the site until recently when the Web registration period ended. I assume they're free onsite at the Gaylord National convention center too (but don't quote me on that!). For any IT Security person in the DC/Virginia/Maryland area, dropping by CSI for at least a day next week is a great use of time.

I'm giving a talk at the conference on Monday at 1.45pm, entitled "Notes from a Vulnerability Assessment of a Bank’s Web Services". I'm also interested in attending the summit on OS security, especially since it is billed with the line "Windows Vista is arguably the most secure operating system ever, in part because it embraces now some of the more promising security tools of the future like Identity 2.0 and trusted computing." The operative word there is "arguably", and although Microsoft has made great strides in security, it is hard to argue that it's more secure than this OS released by the conference's Maryland neighbors

Looking forward to meeting up with DC-based people interested in XML Networking and security. It's the start of a hectic week of travel for me, since I'm speaking at CA World in Las Vegas on Wednesday.

How to convert from REST to SOAP

[ Update: Axway acquired Vordel in 2012 and the new name for the Vordel Gateway is the Axway API Gateway ]

The popular advantages of REST over SOAP are well known: It's easier to write a REST client, the messages are smaller, you can cache REST traffic using standard Web infrastructure. But what if you have SOAP Web Services and your clients are crying out for REST Web Services instead?

Here is how you create REST Web Services in front of SOAP services using Policy Studio and the Vordel XML Gateway...

To do this, create a policy which reads parameters from the REST URL and then inserts those parameters into a SOAP message which it creates on-the-fly. This is shown in the screenshot below:



Let's look at one of the filters which retrieves parameters from the REST request. This is added to the policy by dragging and dropping it from the "attributes" group (a REST parameter is an example of a message attribute).



Once the attributes are read in from the REST request, we create a SOAP message using a "Set Message" filter, as shown below. The message attributes are written dynamically into this SOAP message which is created on-the-fly. You can see the message attributes below, with the dollar signs and curly braces:



The upshot is that now a REST client, such as an XMLHttpRequest object running in a browser, can access a URL like this http://xmlgateway:8080/QuotationRequest?CustomerID=1234&CommencementDate=Jan2008 and then this results in the XML Gateway sending a SOAP request to a Web Service which looks like this:

<soap:envelope soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:body>
<m:getquotation m="http://www.example.org/">
<customerid>1234</customerid>
<commencementdate>Jan2008</commencementdate>
</m:getquotation>
</soap:body>
</soap:envelope>

The overall picture is shown below:



This is a nice example of "service virtualization". The REST service in this example is a "virtual service", since it doesn't actually exist on the Web Service platform itself. Only the SOAP service exists there. The XML Gateway exposes the REST service as a "virtual service". This has security advantages, since there is nothing so secure as something which doesn't even exist. The REST service does not exist on the Web Services platform. It only exists on the locked down, hardened XML Gateway as a virtual service.

The REST parameters can be scanned using a "Threatening Content" filter dragged into the policy in Policy Studio. This is shown below:



In addition, authentication can be added, for example using HTTP client authentication or SSL mutual authentication.

Using this technique, clients can access a REST service, gaining the advantages of REST, while the service provider is safe in the knowledge that they haven't just opened up a backdoor into their SOAP services.

Tuesday, November 4, 2008

Using an XML Gateway as a Federation Gateway, with an STS

Vordel's XML Gateway operates as a Security Token Service (STS), which means it can be used as a Federation Gateway in a scenario like the example shown below. In the case below, using SiteMinder, the XML Gateway at site 2 (on the right) consumes SAML tokens (v1.0, v1.1, or v2), maps them to the local identity at site 2, and then binds the clients message to an existing or new SiteMinder session. This means that the client can access a Web Service at site 2 as if they'd logged in there. The XML Gateway and STS infrastructure enables this.

Because the Vordel XML Gateway includes STS support out-of-the-box, the STS part of the architecture is provided by the XML Gateway. A Vordel customer does not have to go out to the market in order to buy an STS.



If we focus on the STS part of the solution, we see that it can be used not only for Active Directory, but for Sun Access Manager, CA SiteMinder, Tivoli Access Manager, and others. The value of an STS is a number of the amount of identity infrastructure it plugs into multiplied by the number of security tokens it supports.

Who goes first?

Joe McKendrick asks: "Who buys the first round of SOA?". In many cases, the first round is actually not explicitly billed as SOA. Check out the Case Studies on the Vordel website. These all describe projects which solved a particular problem, such as linking a Europe-wide transportation network into a centralized SAP XI system, so that shipment information can be seen in realtime or securely exposing tax information via Web Services. In many cases, the goal was a specific benefit to be realized using new XML-based technologies, but not a case of one department saying "Let's build an SOA and see what happens".

In each case study, the challenges of performance and security had to be overcome if XML-based technologies were to be used. But once these challenges are overcome, using XML Gateways, other departments can use the same (or similar) infrastructure for their own projects. This can be called an SOA. But the key point is that successful SOA initiatives start with real life problems which are solved, not by airlifting infrastructure into place and hoping for the best (a point echoed by the 451 Group's recent SOA report).