Application Platform Strategies Blog

WS-I Interoperability Demo

Blogger: Anne Thomas Manes

WS-I is sponsoring an interoperability demonstration of the Basic Security Profile on June 28 at Burton Group's Catalyst Conference in San Francisco. The Basic Security Profile provides guidance for implementing interoperable web services with basic security features, including authentication, message integrity, and message confidentiality, using SSL and/or WS-Security. Demo participants include IBM, Microsoft, Novell, SAP, and Sun.

SOA and REST operate at different levels of architecture

Blogger: Anne Thomas Manes

VP & Research Director

Application Platform Strategies

I often hear questions such as:

If SOA is about "services" and REST is about "resources", aren't they fundamentally different things?

I also often hear the REST proponents claim that SOA is not really an architecture because it does not define specific architectural constraints.

But that's because SOA and REST operate at different levels in the architectural spectrum.

• SOA is an enterprise architectural style that focuses on understanding what services the business needs, rationalizing those services into capabilities, and deciding what software should be implemented to support those capabilities. But it stops at the point of specifying how to go about implementing a capability. It does suggest that the approach taken when implementing the capability should support concepts like loose coupling, interoperability, flexibility, reusability, and evolvability. 

• REST is a software architectural style that can be used to implement those capabilities. If you abide by the constraints defined by the style, your resulting systems should benefit from a number of desirable qualities, such as simplicity, scalability, performance, interoperability, and evolvability.

It should be clear that SOA and REST are complementary.

Mike Glendenning puts it beautifully in this post to the service-orientated-architecture discussion list in Yahoo! Groups.

The language of business design is very much about services, or the three questions of:

1) What will you do for me (the service)?
2) How will this help my business?
3) How much will it cost?

So, we might have marketing services, finance services, HR services,
manufacturing services and customer support services all making up
our business. In choosing service suppliers, you care only
incidentally (through the SLA) about how the service is implemented.
Instead, services are considered as self-contained "black boxes".

Historically, the language of IT has been all about implementation
platforms and technology, with terms such as the mainframe,
client/server, SQL, Java, WSDL, REST and so on. In the context of
trying to design the [whole] business, this is largely irrelevant.

Now, if we can use the same language to talk about the operation of
the business as well as the IT systems then we are in a much better
position to understand and decide what IT systems are needed to
support the business. We can see immediately how these IT systems
will work with the other parts of the organisation to achieve the
aims of the business. And we can use the same methods for evaluating
the financial cost and benefits as we use elsewhere.

The rest of Mike's post is excellent, so I recommend you read it all.

If you're interested in learning more about REST, I highly recommend attending a half-day workshop, REST Easy, that Burton Group's Pete Lacey will be giving at Catalyst next week in San Francisco.