SOA: Making the Paradigm Shift Part 7 of N ROUGH DRAFT

So far, we have talked about:

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. 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. 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: Web Services are not optimized for RPCs (suck! and we just get bloated un-performant distributed RPC) and 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 Exploit, 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.

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.

XMML InfoSet……

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

Much more here…

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 large nature, when many people fail to realize that they are 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. In addition, these specifications take Services away from the HTTP-only world and define many transports for standardized interoperable services

A lot more here….

REST Services

Write the correct religious stuff here :)