Podcast re: "SOA is Dead" Debate available

I participated in one of Dana Gardner's BriefingsDirect podcasts last week. David Linthicum, Jim Kobelius, Tony Baer, Joe McKendrick, JP Morgenthal, and I debated the "SOA is Dead" theme. You can access the podcast or read the transcript here.

I was a little surprised (and annoyed) at the "commercial sponsor" flavor of the show. The first two thirds of the show focused on communication services, which is a reasonably interesting topic, but the discussion was led by a vendor of one such product. If I'd realized that I was being asked to endorse a vendor product, I probably wouldn't have participated.

The "SOA is Dead" debate starts about 35-40 minutes into the podcast.

"Common REST API"?

Jerry Cuomo published an article on InfoQ yesterday: 2009 Trends and Directions for WebSphere. In it he discusses his Top 10 list of R&D projects for the WebSphere team in 2009. One of the items on the list is REST (which for some reason he combines with Agile). He says:

Restful / Agile – In 2008 we made solid progress in REST enabling our WebSphere portfolio. I’m quite proud of the team for aggressively responding to the call; including the REST enabling in CICS, WebSphere MQ, WAS, WSRR, Commerce, Portal, Process Server, and the list goes on. We have more work to do in 2009. Specifically, with all this REST work, a Common REST API is needed across these products. Complementing our work on REST is our work on Agile programming – specifically the dynamic scripting capability (PHP and Groovy) that is the hallmark of our WebSphere sMash product...

I must say I'm flummoxed by his assertion that IBM needs to develop a "common REST API" across the WebSphere product family. I always thought that one of the fundamental constraints in REST is "uniform API". Wouldn't the common API be GET, PUT, POST, and DELETE?

Maybe I should go back and read the REST dissertation again. I must be missing something.

I'm also not sure I understand why Jerry appears to be linking Agile methodologies with dynamic languages. Again, I think I must be missing something.

Response to the SOA Obituary

Well, this has been an entertaining week. Sensationalism is fun.

On Monday afternoon I published a SOA Obituary. Here are some of my favorite responses:

• Miko renamed his soacenter.org web site to whatevercenter.com
• Miko and friends (Ron Schmelzer, Todd Biske, JP Morgenthal, and others) decided to rename SOA to TAFKAS (The Architecture Formerly Known as SOA), which has been picked up by quite a few others
• David Worthington named me the "Ann Coulter of the analyst community". (Actually I don't like this comparison at all)
• ribaribigrizerep on reddit referred to me as "some chick"
• Harvey Stage posted a comment to blog and referred to it as "a boat load of regurgitated crap"
• Amin Abbasopour posted a comment saying, " 'Anne" is a new word in dictionary meaning 'insight + courage' "
• Loraine Lawson gets it and adds excellent insight in SOA:Dead as Elvis
• Sandy Carter doesn't get it, and Tweeted erroneously, "Well, this SOA is dead article is written by the same group that four years ago wrote a report called Java is Dead. (I’m not kidding.)" (The report was called "JEE5: The Beginning of the End of Java EE." There's a big difference between Java and Java EE.)
• Nick Gall (as expected) used the opportunity to denounce services and promote WOA. (I don't wholy disagree with Nick -- I'm a proponent of exploiting the Web more effectively, and I firmly believe that REST is [in most circumstances] a better way to go -- but he and I have a very different definition of "service".)

SOA Governance presentation available

I presented a session on SOA governance at the InfoWorld SOA Executive Forum in New York on November 8th. InfoWorld has published the slides from the event on their web site.

My presentation was entitled, "You Can't Buy Governance".

How NOT to do RESTful Web Services

A number of web service toolkits , including Apache Axis2 and Apache CXF, now claim to support REST. But in fact, these systems do NOT support REST. They support non-RESTful POX (plain old XML) over HTTP. Non-RESTful POX services are more accessible than SOAP services, but they don't exhibit the desirable characteristics associated with RESTful resources.

The REST architectural style defines a number of basic rules (constraints), and if you adhere to these rules, your applications will exhibit a number of desirable characteristics, such as simplicity, scalability, performance, evolvability, visibility, portability, and reliability.

The basic rules are:

• Everything that's interesting is named via a URI and becomes an addressable resource
  
• Every resource exposes a uniform interface (e.g., GET, PUT, POST, DELETE)
  
• You interact with the resource by exchanging representations of the resource's state using the standard methods in the uniform interface

Non-RESTful POX applications violate these basic rules. First, they don't define a URI for every resource. And second, they don't constrain the interactions to the methods defined in the uniform interface. Instead they define a single URL that represents an operation that can be performed on any number of unnamed resources. Essentially they are tunneling RPC calls through the URL.

Take this example from a recent exchange on the Axis user list:

Q: How do I call a web service operation from a browser having input and output?

My target is end point is http://host/MyService/getInfo and the SOAP body is:

<soapenv:Body>
<ns1:getInfo xmlns:ns1="http://webservice.opt.srit.com/xsd" >
<ns1:systemName>Administrator</ns1:systemName>
<ns1:systemPassword>Password123</ns1:systemPassword>
</ns1:getInfo>
</soapenv:Body>

A: http://host/MyService/getInfo?systemName=Administrator&systemPassword="Password123"

Notice that the URL contains a method name (getInfo) and query string containing the method parameters. This is NOT REST!

A RESTful system would define a different URL for each systemName, and you would invoke GET, PUT, POST, and DELETE operations on the individual systemName resources. The GET query would look more like this:

http://host/systems/Administrator

Notice that I haven't included the systemPassword query parameter in a query string. The idea of passing a password via a URL query string simply boggles the mind. More likely you would use HTTP authentication rather than submitting a password as a query parameter.

I've written more about REST in the Burton Group blog, if you're interested.

More detail on "wrapped" style best practices

Paul Fremantle has written a great write-up on how to design WSDLs to ensure easy compatibility between Axis2 and .NET.

Axis Message Style

I periodically see people asking questions about the Axis "message" style. So let me spend a moment to explain what it is and why you might want to use it.

First let me explain about Axis "styles" and differentiate them from WSDL "styles".

The WSDL "style" refers to the way the WSDL describes the content of a SOAP message body. There are two options:

• Document: indicates that the WSDL explicitly describes the content of the SOAP message body -- in all cases the body is described by a schema element definition. The message description contains at most one message part, and that message part must reference an element definition in a schema defined or imported into the types section.
• RPC: indicates that the WSDL implicitly describes the content of the SOAP message body by specifying an operation name and a set of parameter types. The message description contains one message part for each parameter, and each message part must reference a type definition. At runtime, the SOAP engine dynamically constructs the message based on the following convention: The root element of the SOAP body has a local name that is equal to the operation name and is in the namespace specified in the namespace attribute from the <soap:body> definition. The root element contains a child accessor element for each message part defined. Each accessor element gets its local name from the name attribute of the message part. All parameter accessor elements are in no namespace.

Bear in mind that the WSDL "style" only refers to the way the message content is described. It does not prescribe how an application interacts with the SOAP framework (i.e., the programming model). "RPC" style obviously lends itself to an RPC-style programming model, but what may not be obvious is that "Document" style can also support an RPC-style programming model. In fact, there's a particular convention, referred to as "wrapped document/literal" which enables easy mapping from document style to an RPC-style programming model. See my post on the wrapped convention for more information.

The Axis "style" refers to the programming model that Axis exposes for a given service. The Axis "style" represents a combination of the WSDL "style" plus the message processing system--or "provider"--used to handle messages.

Axis supports two types of providers:

• RPC: The RPC provider automatically converts the XML in a SOAP message into Java objects and invokes a specific method associated with the incoming message type. (There's also an EJB provider that can invoke an EJB rather than a POJO.)
  
• MSG: The MSG provider converts the XML in a SOAP message into DOM and invokes a generic method to process the request

As I said before, the Axis "style" represents a combination of the WSDL "style" and the type of provider. There are four options:

• RPC: Uses the RPC provider and generates an RPC style WSDL
• Wrapped: Uses the RPC provider and generates a Document style WSDL that conforms to the "wrapped" convention. From a programming perspective, it feels exactly like RPC style. At runtime, Axis automatically "wraps" input parameters in a containing element.
  
• Document: Uses the RPC provider and generates a Document style WSDL, but it does not conform to the "wrapped" convention. From a programming perspective, input and output parameters must be wrapped in a bean.
• Message: Uses the Message provider and generates a Document style WSDL.

So, let's look a little more closely at Message style...

Message style is basically do-it-yourself message processing. Axis will perform all SOAP header processing, but it's up to the developer to write the code to process the SOAP body contents. Message style support four method signatures:

public Element [] method(Element [] bodies);
public SOAPBodyElement [] method (SOAPBodyElement [] bodies);
public Document method(Document body);
public void method(SOAPEnvelope req, SOAPEnvelope resp);

This style is appropriate if the application wants to work natively in XML. It's also an effective means to support a completely dynamic system -- it can process any type of input or output message. If you use the RPC provider, Axis needs to know what type of messages to expect and how to map them to Java objects. When using the Message provider, Axis just maps them to DOM, and it's up to the application to then figure out how to process them.

A word of caution, though: if you use the "Message" style and you ask Axis to generate a WSDL, the WSDL will have basically no information in it. Axis doesn't know anything about the content of the messages; therefore, it generates element definitions with type="xsd:anyType". Unless your goal is to build a completely dynamic processor, it's typically a bad idea to use "xsd:anyType" or "xsd:any"in a WSDL. For better interoperability, it really helps to explicitly define the expected contents of all input and output messages. (That's why WSDL Document style is preferred to RPC style.)

So if you use the message style, make sure you also hand-craft your WSDL and add a schema definition of your input and output messages.

Axis 1.x or Axis2?

A lot of people have been asking which version of Axis should they use:

Axis2 is the next generation web services platform. It supports all the latest and greatest SOAP and REST capabilities. It's definitely the system you'll be wanting to use in 2007. Unfortunately, it is not yet stable. The developers are planning to release v1.1 in late September, and I'm hoping that version will be stable. But if you want to use Axis2 before that release comes out, you must be preprared to use the nightly builds, to help identify bugs, and to perhaps propose fixes. The documentation is also pretty sketchy for those unfamiliar with the Axis2 architecture.

Axis is pretty much on life support. It's pretty stable, although a few bugs still exist regarding arrays. If you find a bug, please report it, and it will probably get fixed, but don't expect to see any enhancements going forward.

A little history
Axis2 is actually Apache's third generation SOAP engine:

Generation 1: Apache SOAP -- based on IBM's SOAP4J. Apache SOAP 1.0 was released on June 1, 2000. The last release, V2.3.1, came out on June 10, 2002. (This is now a dead project.) Apache SOAP was the first released SOAP engine, and it relied on DOM to process SOAP messages. It was extremely inefficient. It pre-dated WSDL, and it pretty much required RPC/encoded unless you wanted to programmatically manipulate the messages using DOM.

Generation 2: Apache Axis -- a completely redesigned SOAP engine with native support for WSDL and the JAX-RPC and SAAJ APIs. The first alpha release came out on August 15, 2001, and V1.0 was released on October 7, 2002. The last release, V1.4, came out on April 22, 2006. It relies on SAX to process messages. It's much more performant than Apache SOAP, but definitely not the most efficient engine available. Releases prior to V1.3 provided minimal support for document/literal.

Generation 3: Apache Axis2 -- yet another completely redesigned SOAP engine with an architecture that natively supports the next generation WS-* stack, including SOAP 1.2, WSDL 2.0, WS-Addressing, and plug-in modules for any WS-* header system. It also supports SOAP 1.1/WSDL 1.1, as well as RESTful services. The Axis2 native programming model is based on AXIOM, the Axis Object Model -- which relies on StAX for XML processing. Axis2 supports automatic object/XML data mapping via optional plug-in data binding systems, such as the Axis2 Data Binding (ADB) and XMLBeans. The Axis2 developers are currently working on implementing the JAX-WS API over Axis2.