SOA: Making the Paradigm Shift Part 7 of N

This episode is listed, as “Realization of SOA with Web Services, Web Services Standards, 1st Gen and 2nd Gen, Web standards.” Yuck :) This could, and is the subject of whole books.

Web Services != SOA

The first thing to emphasize is that Web Services != SOA. This means several things. First and foremost, its perfectly possible, and has been for a long time, to create SOA and be “Service Oriented” 100% without Web Services. There have been, and will be many other ways from CORBA to complex B2B solutions to do that. The core ideals have been around for a long time and have been realized in various degrees by various “technologies” as we talked about. The second thing, is that if you use Web Services you won’t necessarily get either “Services” or “SOA.” There is zero guarantees. Remember both SO and SOA are Architectural and Design paradigms as well as business-driven activities. Without those paradigms, you will just create a bloated and less performant (XML) version of your tightly coupled RPC stuff you already have.

In fact, we have what I call the “Big Misconception”: Web Services are for making RPC calls to distributed objects using XML. The Reality is that Web Services are not optimized for RPCs (suck! and we just get bloated un-performant distributed RPC) and that Web Services work best when they respond to messages.

We‟ve been  misled especially by VS.NET tooling (prior to 2K8) and ease of creating a ASMX  “Web Service” that is not a Service or SOA. The Project wizard in Visual Studio .NET suggests that Web Services are…

• ASMX automagically generates the interface description for you
  (aka WSDL) - “I must have a Service!”
• Created a Proprietary Section 5/7 Encoded SOAP RPC CALL
• Service’s full poten tial cannot be leveraged

In my opinion, the right design approach is to always think in terms of messages and operations when designing a service. Using Contract-First Design helps you keep the right focus as It’s The Agreement that matters and that’s all. The rest is small.

As we will see, even though Indigo generates the right “Web Service stuff” underneath, it is a framework for SOA that works with Messages. But again, even though Indigo is Microsoft’s framework for creating Services and SOA, you can still create tightly-coupled RPC applications. It’s just that, with the explicit opt-in enforcement of Boundaries are Explicit, with Data Contracts and Service Contracts, it is much more possible to create SOA. No substitute for using your brain though :).

Why SOA Now with Web Services?

The big question most people have is “why now” and “what’s different” than SOA in year’s past. The answer is everything.

SOA is not new. It has been around, in some form, for decades in technologies like CORBA, COM/DCOM and RPC. So what’s new, and why now? There is a perfect storm of factors right now that make SOA finally achievable.

The first of these is unprecedented industry consensus with world-wide standards based on XML. Particularly, Microsoft and IBM agreed, and the rest of the industry fell in line. The second is that the concept of SOA has been tied together with the powerful enabling and delivery mechanism of XML Web Services. This now makes implementing standards-based services possible and cost effective. The final factor is the degree of dissatisfaction that both business and IT has with the current state of IT within their enterprises with integration. They are tired of endless integration models that have become silos themselves, particularly EAI. The answer is to not integrate, but service enable existing IT assets to create an Agile Business.

The next few sections can get religious and contentious. I am trying to stay away from that, keep it simple.

First-Gen Web Services

Note: This section undergoing editing… Did I get this well?

In general, “first-Gen” Web Services were first pushed by Microsoft, particularly 2000-2003 and are still very much predominant. These services are SOAP + WSDL standard services and culminated with the WSI-I Basic Profile 1.0 standardization in 2004. This set of capabilities is represented by the BasicHttpBinding in WCF.

I think it’s fair to say, that in the first version of SOAP, Don Box and others were attempting to look at getting things like DCOM through firewalls and the Simple-Object-Access Protocol had more to do about getting an interoperable representation for distributed RPC calls. Thus Section 5 and 7 encodings in the 1.0 SOAP spec.

Its also fair to say that we matured as an industry and realized XML-ized RPC sucked and we begin to move, as a community and industry to realize that we needed to move to document and message based services. To that end, SOAP 1.1 was rewritten and both the 1.1 and 1.2 versions are all about Documents and Messages.

In a funny twist, SOAP no longer stands for Simple-Object-Access-Protocol and now stands for nothing :). Its an acronym for itself!

Second-Gen Web Services

Over the last 8 years, Microsoft, IBM and others have worked on a more robust enterprise set of capabilities for Web Services that are composable and interoperable, but yet still based on the XML Infoset, and all the other standards like XML Encryption, XML-Signature, SOAP, etc.. The result has been the WS-* series of specs.

These specs are frequently mis-interpreted and derided for their bloated and voluminous nature, when many people fail to realize that they are both COMPOSABLE and OPTIONAL. In other words, you take what you need. I will argue that core specs like WS-Addressing and WS-Security are very necessary, particularly for creating Enterprise services. In addition, these specifications take Services away from the HTTP-only world and define many transports for standardized interoperable services.

In any regard, it really doesn’t matter in the WCF Framework, as the Service Model is quite happy to construct a Channel Stack based on the correct Transport and Protocol channels dynamically as you opt-in or out for WS-* features or use REST bindings. The Service Model Software Factory interface to you stays the same. The WCF model of using Attributes and Bindings allows a great deal of abstraction over all of this and you never really see it, unless you want to be. In other words, the use of WS-* underneath is virtually orthogonal to the business aspects of the service you are building.  Sure, there is some degree of what “features” can go with what “bindings” but the main point is Indigo will dynamically create the appropriate channel stack for you and will use the relevant Internet Standards underneath for interoperability. In fact, in the 4 years that I have been using Indigo, it has been my pleasure to enjoy a great deal of Interoperability with Java stacks like Apache Axis with a lot less effort and code than previous frameworks.

I am going to move on here, as there are whole books devoted to this area.

REST Services

Circa 2008, there has been a movement, in some circles, towards REST and POX Services and to be "with the cool kids" you have to be "restful" and renounce all other religions. There is absolutely no doubt in my my mind that REST services are very useful in a number of places, particularly CRUD services, services that are containers for large amounts of data, and particular binary data, and I use them alongside SOAP services all the time.

Having said that, I can’t help but see a lot of misconceptions about REST and fear about the way some people see it as the one solution to every Service problem and deride the other ways. At the risk of being very blunt, sometimes I feel that some of these people work for training companies and not in Enterprise shops where multiple transports other than HTTP are needed, where the limitations of the Resource Model become apparent, where things like Reliable Messaging, real security other than end-to-end SSL and others are critical. I like to give credit where credit is due, and I feel my words cannot but echo the fine words that McMurthy, Mercuri, Watling and Winkler have already expressed in Chapter 18 of their fine book “Windows Communication Foundation: Unleashed:

“….REST sometimes misrepresented, as is by Paul Prescod (2002) as a “new model for Web services construction. Actually it is an architectural pattern that was first formally described by Dr. Roy Fielding…”

“So, Dr. Fielding was not proposing a way of building web services; he was providing a formal description of the architecture of a web browser.”

“Thus, the term Representational State Transfer” describes the architecture of an application with a client that behaves like a Web Browser does.”

Then there the misconceptions and I can vouch for the relative difficulty one:

“A common notion is that a REST service that provides POX responses is simpler than a SOAP service…That perceived simplicity is sometimes put forward as a justification for building a REST service rather than a SOAP service.”

“In practice, though, building a REST POX service is not simpler than building a SOAP service. It is true that the specifications pertaining to a REST POX service are merely the specifications for HTTP and XML, while those pertaining to SOAP services have become quite voluminous….”

""Yet, because great tools for building SOAP services are so ubiquitous, developers of SOAP services have as little need to read all of these specifications as .NET or Java developers have a need to know the assembly language of the processors on which their applications will be executing."

"Indeed, precisely because the SOAP specification because the SOAP specifications include a metadata specification - the WSDL specification - SOAP toolkits can download descriptions of services and generate the code required for communication with them. The only way of describing how to use a REST POX service is with prose and samples."

 

That has also been my experience. Working with POX, well blows, sorry, I don't want to sling angle brackets around, I have business problems to solve. That is, in my world, until WCF 3.5 and the excellent REST/POX support that the Indigo team added to the existing System.ServiceModel to make it easy and transparent. So we are left with this last quote that I wholeheartedly agree with,

"More important, though, is that REST POX services and SOAP services should not be seen as two alternative ways of implementing the same solution, because in fact, REST POX services are clearly suited to certain scenarios for which SOAP services are not, and the other way around."

Enough already. I know this will get flamed and we have been fighting these battles forever. Just keep an open mind, don't be all or nothing, and use the right tool for the job is my advise.