The View From The Bow

RIP Sasha -- April 1, 1997 - July 21, 2011

2011-07-23T17:48:00.008-04:00

Sasha was a miracle dog.

We adopted her from a Chesapeake Bay Retriever rescue group at 5 months.

She was completely uncivilized when we got her. She came from a bad situation: Her people obviously did not understand Chessies. Sasha was remarkably intelligent, energetic, and driven. Her people didn't know how to handle her, so they kept her crated pretty much all the time. They also didn't understand about growing puppies. The breeder had told them to feed her a cup of food a day. They were still feeding her one cup of food a day at 5 months. She weighed just 24 lbs! Two weeks later, she weighed 32 lbs. Soon after, she developed panosteitis (growing pains). But we got through that.

Initial training was ... challenging. She learned commands in next to no time--she just wasn't convinced that she needed to heed them. Keep-away was one of her favorite games. Fortunately, she was very food driven, and in time she became quite civilized. She developed an enormous vocabulary, including concepts like left, right, inside, and outside. She was most certainly the smartest dog we've ever known. And that look of mischief was always in her eye.

From an early age, Sasha set her sights on the alpha spot in the pack. Sheba (our 9 year old golden) had other ideas. Poor Sheba endured 2 cruciate repairs, but managed to retain her alpha spot. We deemed it prudent to adopt another younger pup, Peter, (a chessie/golden mix -- 6 months younger than Sasha) to reduce some of Sasha's attentions on Sheba. It worked. Sasha and Peter were great playmates. Sheba and Tucker (our 11 year old golden) were relieved.

Alas, Sasha developed bone cancer in her right knee at age 2. The prognosis was not good: 4 months without chemo; 18 months with chemo. Amputation was essential either way. They took the leg off at the hip. The vet went in to check on her after surgery and found her standing up in her cage waiting to get out. Once that nasty, painful bone was gone, she was raring to go. We then put her through a course of chemo -- 4 treatments over 3 months. She tolerated them very well. She did not appreciate her restricted activity period. She wanted to PLAY!

And soon we got back to normal life. 18 months came and went, and Sasha showed no sign of a relapse. Sasha (now a tripod) wasn't quite as fast as she used to be, but she had just as much drive as ever. She had balls and sticks and bumpers to fetch. Most people didn't realize that she was a tripod unless we pointed it out. She was a very determined dog!

Alas, her never-say-die approach to life put excessive strain on her remaining knee, and she blew out her cruciate ligament at age 4. We attempted a repair using TPLO. Remarkably, she was walking again in just a couple of days. Our attempts to restrict her activity failed, though, and she developed a complication: She broke the sliver of bone in her leg before the two pieces had healed.

Have you ever tried to keep a high-energy 4 year old chessie on strict bed-rest for 12 weeks? Yikes! We concocted a barrier half-way up in her crate that forced her to remain lying down. The bone eventually healed, but Sasha had arthritis in that knee from that point forward. (Not that she would ever let on, though.)

The two goldens passed on when Sasha was 5 -- Sheba was 13 and Tucker was one month shy of 15. Finally Sasha assumed the alpha spot. Somehow, though, being queen just isn't as satisfying if there's no one to push around. But we solved that. We adopted Cally -- a petite deadgrass chessie puppy. Sasha suddenly found herself on the other side of the fence: She was the queen defending her crown from this obnoxious little upstart! Cally didn't have a chance, though. But the two of them traded a number of scars over the years.

Sasha was never one to admit that she had a disability. If we'd let her, she'd play fetch until she couldn't walk anymore. And she hated it when we forced her to rest. She couldn't sit by and let Peter and Cally have all the fun.

Arthritis eventually took its toll, though, and Sasha finally started to slow down at about age 12. Perhaps Peter's death gave her tacit permission to take it more slowly. (Poor Peter -- just 11 years old -- died of histiocytic sarcoma -- very nasty.) In any case, stairs became a real challenge for Sasha, as well as navigating any type of uneven terrain. She never stopped dock diving though. This picture was taken when she was 13.

This winter we bought her a Help 'em up Harness. Fabulous! It made it so much easier to help her get around. I'd grab the rear handle and she'd be off running. We also got her a set of wheels from Eddie's Wheels. She took to the wheels very quickly, but they were a bit heavy for her. And our hilly property limited her ability to get around.

Sasha turned 14 in April, but you'd never know it to look at her. She was only slightly gray, and her expression was always vibrant. She did lose her hearing, though. I think she loved using it as an excuse not to obey. (She conveniently forgot her hand signal commands, too.)

Two weeks ago, she lost her appetite. Given her puppy starvation phase, Sasha was always a voracious eater. I once tried an experiment to see how much she would eat in one sitting. I stopped after 12 cups of food. Sasha still wanted more. If she wouldn't eat, you knew something was wrong. So we went to the emergency room. An ultrasound revealed a large tumor in her liver. Another mass in her lungs indicated metastasis.

There wasn't much we could do about the cancer, but at least we could do something about her symptoms. We gave her medications to reduce her nausea and indigestion. And within 2 days, she sprang back to life. We went to a barbecue at a friend's house -- a beautiful spot on a pond. There were 6 retrievers and a dozen children eager to throw Frisbees. Sasha played non-stop for 3 hours. Cally even has a new scar on her nose. (Sasha got the Frisbee.) It was a wonderful evening.

All I can say is that I'm happy the end was swift. Tuesday evening, Sasha ate dinner with her usual gusto. Wednesday morning, she picked at her breakfast. By 1:00pm it was clear she was in great distress. We went back to the emergency room. They put her in ICU and tried to stabilize her -- they treated her for shock and gave her fluids and anti-nausea medication. Alas, she was no better in the morning. Her time had come. Thanks to euthanasia, we didn't prolong her agony. She drifted quietly off to sleep in my arms.

A friend of mine gave me these words of comfort:

I remember the Buddhist parable of the cup. The novice asks the master, aren't you sad when you see this beautiful cup, knowing that someday it will be broken? The master replies, no! Because the first day it was given to me I imagined it in pieces, and since then I have celebrated every day I have been allowed to spend with it.

In 1999, they told us she had 18 months to live. I guess no one told her, though. She lived 12 more years! And I have celebrated every moment of them.

No doubt she has caught up with Sheba at the Rainbow Bridge, and Sasha is doing her best to make Sheba's life miserable again.

Podcast re: "SOA is Dead" Debate available

2009-01-27T13:23:00.002-05:00

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"?

2009-01-22T18:08:00.002-05:00

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

2009-01-08T15:34:00.003-05:00

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

2007-11-19T18:32:00.000-05:00

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

2007-06-01T09:21:00.000-04:00

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

2007-06-01T08:51:00.000-04:00

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

Axis Message Style

2007-03-04T10:32:00.000-05:00

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?

2006-08-28T08:15:00.000-04:00

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.

A Short Explanation of XML Namespaces

2006-07-07T16:53:00.000-04:00

I wrote this up in response to a question on the Axis User discussion list, but thought others might appreciate it.

The purpose of a namespace qualification is to disambiguate two
components of the same name. For example, if you have multiple schemas
that each defines an element called "foo", how do you tell them apart?


    <s:schema
          xmlns:s="http://www.w3.org/2001/XMLSchema"
          targetNamespace="urn:example:foo:1">
       <s:element name="foo" type=s:string"/>
    </s:schema>   

    <s:schema
          xmlns:s="http://www.w3.org/2001/XMLSchema"
          targetNamespace="urn:example:foo:2">
       <s:element name="foo" type=s:int"/>
    </s:schema>

    <s:schema s="http://www.w3.org/2001/XMLSchema"
          xmlns:ns1="urn:example:foo:1"
          xmlns:ns2="urn:example:foo:2"
          targetNamespace="urn:example:foo:0">
      <s:import namespace="urn:example:foo:1"/>
      <s:import namespace="urn:example:foo:2"/>
      <s:element name="foo">
         <s:complexType>
             <s:sequence>
                <s:element ref="ns1:foo"/>
                <s:element ref="ns2:foo"/>
             </s:sequence>
         </s:complexType>
      </s:element>
    </s:schema>

An instance document of this element could look like this:


    <ns0:foo
        xmlns:ns0="urn:example:foo:0"
        xmlns:ns1="urn:example:foo:1"
        xmlns:ns2="urn:example:foo:2">
          <ns1:foo>some string</ns1:foo>
          <ns2:foo>12345</ns2:foo>
     </ns0:foo>

This instance is equally valid (but less readable):


    <tns:foo xmlns:tns="urn:example:foo:0">
       <tns:foo xmlns:tns="urn:example:foo:1">
          some string</tns:foo>
       <tns:foo xmlns:tns="urn:example:foo:2">
          12345</tns:foo>
    </tns:foo>

In other words, the string used for the prefix is irrelevant -- what
matters is the namespace it's been assigned to and the scope of the
namespace declaration. A namespace declaration applies to the element
it's defined in and all that element's children, but you can always
reassign the prefix to a different namespace in a child element.

The default namespace declaration (e.g., xmlns="urn:example:foo:0")
says that all non-explicitly qualified elements belong to the default
namespace. I generally recommend avoiding use of the default namespace
-- especially if you have unqualified elements -- because that forces
you to override the default namespace (e.g., xmlns="") on all
unqualified elements.

So for example, let's say I have this schema:


   <s:schema
        xmlns:s="http://www.w3.org/2001/XMLSchema"
        targetNamespace="urn:example:foobar">
      <s:element name="foobar">
         <s:complexType>
            <s:sequence>
               <s:element name="foo" type="s:string"/>
               <s:element name="bar" type="s:string"/>
            </s:sequence>
          </s:complexType>
      </s:element>
   </s:schema>

Because the schema does not specify elementFormDefault="qualified",
all local elements ("foo" and "bar") are unqualified. A valid instance
of this schema is:


  <tns:foobar xmlns:tns="urn:example:foobar">
     <foo>some string</foo>
     <bar>another string</bar>
  </tns:foobar>

But the following instance is not valid because "foo" and "bar" must be unqualified:


  <foobar xmlns="urn:example:foobar">
     <foo>some string</foo>
     <bar>another string</bar>
  </foobar>

This instance is valid:


  <foobar xmlns="urn:example:foobar">
     <foo xmlns="">some string</foo>
     <bar xmlns="">another string</bar>
  </foobar>

A Flash of Enlightenment in the SOAP vs REST Debate

2006-06-29T09:33:00.000-04:00

I just came upon this great post by Steve Jones about the pointlessness of the debate about SOAP vs REST.

I heartily concur. I will take Steve point one step further, though.

The essence of Steve argument is that the actual technologies used to implement services should not be front of mind when designing services. What should be front of mind is:

what is the functionality that needs to be exposed?
what are the messages that need to be exchanged to achieve that functionality?

From that point on, tooling should just generate the endpoint middleware necessary to achieve the exchange, and infrastructure should ensure that the messages are delivered properly.

But things are not always quite that simple -- any dependency on a specific type of middleware will constrain the reach of a service. The SOAP proponents will argue that SOAP makes XML messaging simpler and easier for people that are more familiar with the RPC-style programming model. The REST proponents argue that SOAP is too complex, and that automatic XML/object mapping is a myth, therefore the ease-of-use associated with SOAP is deceiving and misleading.

Both arguments have merit, but they are beside the point.

When you provide a service, you must cater to your customer. Therefore you must support whatever service interface your customer desires -- SOAP, REST, ebXML, "plain old XML" over HTTP, EDI, etc.

Which brings me back to Steve's basic argument. The essence of your service design must be:

what is the functionality that needs to be exposed?
what messages must be exchanged in order to achieve that functionality?

After you have designed the fundamental requirements of the service, then you can expose that functionality using as many middleware technologies as you need in order to support your customers' requirements. As long as you maintain clean separation of interface from implementation, you can do that.

AMQP finally emerges from stealth

2006-06-23T10:28:00.000-04:00

I first heard about AMQP in an eWeek article published in February, and I was very disappointed at the time that I couldn't find any other information. For a supposedly "open source" effort, the folks involved were keeping things tightly under wraps.

Well, the AMQP Working Group finally emerged from stealth mode on June 20.

AMQP proposes a standard, interoperable protocol for message queuing systems. Such a protocol would enable any message queing system to interoperate with any other message queuing system -- assuming, of course, that the message queuing systems involved use AMQP. It remains to be seen, though, if the leading MOM vendors will adopt AMQP. I think it will breathe new life into the MOM market if they did so. I have to investigate this, but I also think that AMQP could be used as a standard protocol to support reliable messaging in SOAP -- e.g., WS-RX over AMQP. (AMQP is a binary protocol that has it's own typing system, but my guess is that an AMQP message can convey any type of message payload.)

Information about AMQP is being hosted by TWIST, a non-profit organization focused on developing standards for the financial supply chain market. (The AMQP Working Group is a separate entity, though.)

The AMQP Working Group has published a preliminary specification (v0.8). The authors include JPMorgan Chase & Co., Cisco Systems, Inc., Envoy, iMatix Corporation, IONA Technologies, Red Hat, Inc., TWIST Process Innovations, and 29West. The specification grants a very open license:

"a worldwide, perpetual, royalty-free, nontransferable, nonexclusive license to (i) copy, display, and implement the Advanced Messaging Queue Protocol ("AMQP") Specification and (ii) the Licensed Claims that are held by the Authors, all for the purpose of implementing the Advanced Messaging Queue Protocol Specification."

Given these free terms, it seems likely that the open source and startup communities will readily adopt the protocol. But if the major players -- especially IBM, Tibco, and Microsoft -- don't get on board, AMQP may follow the path of BEEP. We'll see.

Where's the Code?

I'm a little confused by the constant reference to "open source" when people talk about AMQP. As far as I can tell, there is no open source project currently implementing AMPQ. I grant that the licensing terms for the specification are quite open, but the process to develop the spec has been far from open. Besides... open source typically implies source code.

Thank you Jonathan Schwartz!

2006-05-17T08:50:00.000-04:00

For the first time in 11 years, I did not make it to JavaOne this year. And now I'm really regretting it. I'm certain that there's a fabulous party going on at Moscone Center this week.

Yesterday, Jonathan Schwartz and Rich Green announced their intention to release Java under an open source license. Timing, licensing, and other details are still to be determined, but I am confident that it will happen.

I worked for Sun Software for 18 months in 2000-2001. I had 2 major objectives while I was there. Convince them to embrace SOAP and to open source Java. I was successful in the first objective, but my arguments for open sourcing Java fell on deaf ears. Or at least it felt that way.

But I know that the open source faction was heard. I always got the sense that Sun would eventually open source Java -- the question was when. Being part of the open source proponent faction was never considered to be a bad thing. Many of my most ardent and vociferous comrades-in-arms have done quite well at Sun -- folks like Simon Phipps, who is now Sun's chief open source officer, and Ingrid Van Den Hoogen, who is now Sun's VP of Brand Experience and Community Marketing.

I really hoped it would happen after the court settlement between Sun and Microsoft. (That was the only excuse I would accept for waiting.) But I guess we had to wait for Scott to step down.

In any case, thank you Jonathan.

UnREST over WS-* and other "enterprisey" things

2006-05-09T09:07:00.001-04:00

Mike Herrick, who just happens to be one of my Burton Group clients, has accused me of having "totally drunk the WS-* the Kool-Aid". He goes on to say, "I just was disturbed that given the history on things like J2EE she so easily assumed that WS-* will survive and thrive."

Let me make this clear:

I'm one of the folks responsible for mixing the Kool-Aid. I presented at the W3C Workshop on Web Services (representing Sun). I participated in numerous standardization efforts at W3C, OASIS, WS-I, uddi.org, and JCP. I have a vested interest in making sure that WS-* succeeds.

I had a similar vested interest in CORBA (I was working for DEC at the time), and I was just as enthusiastic about CORBA then as I am about WS-* now. At the time, CORBA was the state-of-art in distributed computing technology. And today, I think WS-* is the state-of-the-art in distributed computing technology. But I by no means assume that WS-* will always remain the state-of-the-art. I assume that something better will come along. Unfortunately, it hasn't come along yet, so we have to make do with what we have now.

The single, most important feature that inspires my enthusiasm about WS-* is that it has universal support from all the major vendors. The technology has become pretty much pervasive (although the industry is still stuggling with interoperability issues), and there's a huge ecosystem of vendors and products and tools that support it. WS-* also has some really interesting innovations (separation of header and body, the composability of the various SOAP extensions, policy-based management and control via intermediaries, etc), which I think make it particularly well-suited for enterprise-class service-oriented application systems.

There. I've qualified it. WS-* is enterprisey. But is that really such a bad thing? If you need comprehensive enterprise-class semantics (security, reliability, session management, transactions, etc), then it really helps to use an enterprisey middleware system.

People accuse WS-* of being too complex. (Somewhat remarkable when you think back to 2000 when everyone was extolling SOAP's simplicity.) Well -- if, as a developer, you need to understand the details of all 60+ WS-* specs, then, yes, WS-* is way too complex. But that's a symptom of WS-*'s immaturity. If we had proper tooling, the only folks that would need to be concerned with all the 60+ specifications are the folks implementing the WS-* toolkits. Developers should really only need to be concerned with a handful of the specs: SOAP, WSDL, and XML Schema--maybe WS-MetadataExchange. Everything else should be handled transparently by the toolkits. I think we'll get there. Microsoft's WCF ("Indigo") demonstrates how easy it can be to use WS-Addressing, WS-ReliableMessaging, WS-Security, WS-Trust, and WS-SecureConversation. All you have to do is specify an annotation, and everything is automatically implemented behind the scenes. I expect the other vendors to deliver better tooling at some point. Now that WS-Policy has finally moved into the standards track, we should start getting much better configuration tools.

But I can't ignore the debate between REST and WS-*. I'm a huge proponent of the KISS principle. So I don't recommend using WS-* for all service interactions. If an application doesn't require enterprisey infrastructure semantics, then it's much more appropriate to use a simpler middleware system, such as "plain old XML" (POX) over HTTP. In fact, for applications that require Internet scalability (e.g., mass consumer-oriented services), POX is a much better solution than WS-*.

But that doesn't mean that POX is the best solution for all systems, either. POX doesn't support a clean separation of business and infrastructure functionality, so if you are using POX and you need enterprisey infrastructure semantics, then you need to code the infrastructure functionality in your application code. Bad idea. The reason you use middleware in the first place is to help reduce the amount of infrastructure functionality the developer has to write.

The point is that you should always use the tool that best fits the job. Let the application requirements dictate your selection of middleware.

WS-Convergence

2006-03-27T18:03:00.000-05:00

Please also listen to my PodCast on this topic.

Remember a couple of years back when the vendors lined up in factions to fight over specifications?

WS-Reliability vs WS-ReliableMessaging
WS-CAF vs WS-Transaction
WS-MessageDelivery vs WS-Addressing
Liberty/SAML vs WS-Trust/WS-Federation

Inevitably, the lines were drawn with Sun and Oracle on one side and IBM and Microsoft on the other. Sun and Oracle made a habit of submitting the first versions of their specs to a standards body, while IBM and Microsoft closely guarded the first two or three revisions, while promising to submit them to a standards body "at some point in the future". Nonetheless, the IBM/Microsoft faction always seemed to win more mindshare.

The situation is much improved since Microsoft and Sun buried the hatchet two years ago, and IBM and Microsoft have finally submitted most of their specs (WS-SX, WS-RX, and WS-TX) to OASIS.

But there's still one outstanding competing specification stack that still need to be resolved: that of resources, events, and management. Unlike previous situations, in this case IBM and Microsoft are on different sides--and the dispute revolves around simplicity vs richness.

The two stacks line up like this:

Microsoft Camp

IBM Camp

Resources

WS-Transfer

WS-Enumeration

WS-ResourceFramework

Events

WS-Eventing

WS-Notification

Management

WS-Management

WSDM

The Microsoft stack is lighterweight and was only recently placed on a standards track. (WS-Management is now governed by DMTF, and WS-Transfer, WS-Enumeration, and WS-Eventing were submitted to W3C in mid-March.) The IBM stack focuses on richness of functionality and is being managed by OASIS. WSDM is an OASIS standard.

I find the management dicotomy particularly unsettling, so I was very pleased to see HP, IBM, Intel, and Microsoft publish a white paper that I refer to as WS-Convergence. It defines a roadmap for converging these specifications. (A realistic timeframe for completion of this roadmap is 24-36 months.)

The roadmap is divided into three sections, addressing resource management, event processing, and management.

Resource Management: The roadmap proposes using WS-Transfer and WS-Enumeration as the standard foundation for resource management. The roadmap also proposes developing two new specifications, WS-Transfer Addendum and WS-ResourceTransfer, as well as a revision of WS-MetadataExchange.

WS-Transfer Addendum will extend WS-Transfer to add support for WS-Addressing endpoint references
WS-MetadataExchange v1.1 will build on WS-Transfer and WS-Transfer Addendum in place of its current domain-specific protocol
WS-ResourceTransfer builds on WS-Transfer, WS-Transfer Addendum, WS-Enumeration, and WS-MetadataExchange, providing sophisticated resource management capabilities comparable to those of WSRF

All four vendors promise to deliver products that support these specifications. IBM further commits to influence the OASIS WSRF TC to refactor the WSRF specifications into extensions that build on WS-ResourceTransfer.

Event Processing: The roadmap proposes using WS-Eventing as the standard foundation for event processing. It also proposes developing a new specification, called WS-EventNotification, that will integrate many capabilities from WS-Notification into WS-Eventing. WS-EventNotification builds on WS-ResourceTransfer to support resource management of subscriptions.

All four vendors promise to deliver products that support WS-EventNotification. IBM intends to influence the OASIS WS-Notification TC to ensure compatibility between WS-EventNotification and WS-Notification, although WS-Notification will most likely continue on its own trajectory to support more complex use cases.

Management: The roadmap proposes the development of a new management specification that builds on WS-EventNotification and WS-ResourceTransfer. The new specification will replace both WSDM and WS-Management.

All four vendors promise to deliver products that support the new converged management specification. In addition, IBM will continue to support WSDM, and Microsoft will continue to support WS-Management.

Technoracle (a.k.a. "Duane's World"): The Nickull Threshold Service Oriented Architecture (SOA) and related technologies

2006-01-04T18:26:00.000-05:00

A must read: Technoracle (a.k.a. "Duane's World"): The Nickull Threshold Service Oriented Architecture (SOA) and related technologies

Evaluating Superplatforms / The Google Threat

2005-11-11T07:29:00.000-05:00

In a comment on my The future of the ESB market posting, Matt Gunter asked a couple of questions. The first question is:

I am curious what your latest thoughts are about the relative value of .NET vs. J2EE "superplatforms"

Can they be fairly evaluated due to their radically different degrees of openness, standards support, and ability to leverage the value of open source-style collaboration?

These features are just some of the many features that should be considered when evaluating a superplatform. Personally I don't think that there are such radically different degrees of openness and standards support between the superplatforms. All superplatforms "embrace and extend" industry standards. .NET is built on an ISO standard. The Java platforms are built on JCP standards. All superplatforms provide excellent support for the stable bits of the web services framework (SOAP, WSDL, UDDI, WS-Security, and WS-I BP). Likewise, all superplatforms add their own proprietary bits that pretty much lock you into the platform. Users can avoid using these proprietary bits, but then they pass up some of the unique value-add of using the superplatform in the first place. If that's the goal, then I suggest using JBoss rather than one of the superplatforms.

There is one important difference between the Microsoft and the other superplatforms -- .NET doesn't support Java, and therefore doesn't support the plethora of popular open source rebel frameworks out there, like Struts, Spring, and Hibernate. Likewise, the Java-based superplatforms don't support the .NET languages, and therefore don't support the plethora of .NET frameworks out there. Microsoft supplies a tremendous number of built-in frameworks, and there's a vibrant ecosystem of both open source and commercial add-on frameworks.

One way of looking at the situation is that the open source community had to developed a bunch of rebel frameworks for Java mostly because the J2EE standard doesn't provide a reasonable set of built-in frameworks. Very few .NET users complain about how inadequate ASP.NET, ADO.NET, Avalon, and Indigo are. I don't know anyone that thinks that JSP/servlets is adequate without something like Struts, or that think that EJB CMP is a stellar piece of engineering.

Openness, standards support, and ability to leverage the value of open source-style collaboration are important considerations, but just as important are things like:

ease of use
completeness of solution
cohesiveness of the environment
integration with user productivity applications (e.g., Office)
integration with collaboration services
price

Platform selection is dependent on a number of factors and is strongly influenced by an organization's corporate principles. Every company has a slightly different position on a wide set of issues, e.g.:

how do you feel about open source?
are you risk takers or risk averse?
Do you prefer to buy from a sinlge vendor or cobble together a best of breed solution?
Do you tend to build or buy?

And now on to Matt's second question:

The same trends that are propelling Google seem to be working against Microsoft. Do these same trends not affect the longer-term prospects for "superplatforms"?

I agree that Google is a tremendous force to be reckoned with, and Google may very well emerge as the first in the next generation of superplatform vendors. But of all the current crop of superplatform vendors, I think Microsoft is best positioned to compete with Google. Microsoft is the only superplatform vendor that has any type of focus on the consumer marketplace. And Microsoft has already proven that it has the ability to make a massive mid-course change (embracing the Internet in the late '90s). I have a lot of confidence that Microsoft will remain in the game.

As for the other superplatform vendors, I don't think they realize yet that Google is a threat to them.

REST and SOAP and document-oriented services

2005-09-17T16:45:00.000-04:00

There's been an interesting discussion of REST and SOAP and document-oriented web services starting with Mark Baker's post called Towards truly document oriented Web services. I think this is one of Mark's best and most succinct efforts to explain the subtle, yet important differences between REST and SOAP, which continue to befuddle so many people.

It all comes down to application semantics.

One of the primary tenets of REST is the use of a uniform interface between components. In his dissertation on REST, Roy Fielding describes the uniform interface as "the central feature that distinguishes the REST architectural style from other network-based styles". REST is closely associated with the HTTP application protocol because HTTP provides this type of uniform interface -- all components communicate using simple, generic methods: GET, POST, PUT, and DELETE.

In Mark's post he explains the different application semantics expected when using POST versus PUT to send a SOAP message. POST implies "process this message", while PUT implies "store this message".

SOAP is also an application protocol, with its own set of application protocol semantics. And these semantics are different from HTTP application protocol semantics. Even though SOAP messages are typically transferred using HTTP, for the most part SOAP hides/obscures the HTTP semantics from SOAP applications. The underlying SOAP runtime systems communicate using HTTP semantics, but SOAP applications communicate using SOAP semantics.

SOAP uses (some would say abuses) the HTTP application protocol. Even though HTTP is an application protocol, SOAP treats HTTP as a lower-level communication protocol. But SOAP is an equal-opportunity application protocol abuser. SOAP treats other application protocols, such as WebSphere MQ, SMTP, and Jabber, the same way. From the SOAP perspective, these application protocols are all low-level communication protocols.

The SOAP specifications define bindings of the SOAP application protocol semantics to other application protocol semantics, such as HTTP, SMTP, and WebSphere MQ (communication protocols). Simply put, SOAP uses HTTP and other application protocols to exchange messages between SOAP nodes. The SOAP nodes act as mediators between SOAP applications and the underlying communication protocols. Although there are some subtle differences between the various protocol bindings, SOAP does a fairly decent job of isolating the applications from the different semantics of the various underlying communication protocols. (SOAP 1.2 does a better job than SOAP 1.1 abstracting away the underlying protocol semantics.) In any case, the goal is that SOAP exposes the same application protocol semantics regardless of the underlying communication protocol.

SOAP does not fully exploit the power of the HTTP application protocol. In fact, SOAP 1.1 explicitly constrains its use of HTTP to that of the HTTP POST operation. SOAP 1.1 over HTTP requires that SOAP requests be sent using POST. The specification doesn't indicate how to process requests using PUT. Therefore use of PUT is not supported by the SOAP protocol. SOAP 1.2 adds a description of using SOAP with HTTP GET, but it still doesn't describe how to use SOAP with HTTP PUT. Mark's example of using HTTP PUT to store a SOAP message is outside the scope of the SOAP protocol. In this example, HTTP PUT semantics apply, not SOAP semantics.

Now -- getting back to the topic of REST and SOAP and document-oriented web services ...

In his post, Mark references one of my responses to an Ask the Expert question on TechTarget regarding the difference between Document and RPC style services. In my response I indicated that the difference between Document and RPC is fairly minor, but the more import consideration is the encoding style. Document style messages are encoded literally according to a schema. Back in 2002, when I wrote this response, RPC style messages were typically encoding using a data model called SOAP encoding. (Many SOAP engines now also support literal encoding of RPC style messages.)

Mark has a different perspective, though. He claims that the more important difference between Document and RPC style services is whether or not the message contains a method name. When using RPC style, the message always contains the method name. When using document style, the message may or may not contain the method name. When using the "wrapped" programming convention, the message does contain the method name. When using the "unwrapped" programming style, the message typically doesn't contain the method name.

To quote Mark's post:

While the encodings used were certainly different, each with its own not-insignificant pros and cons, what Anne failed to point out is that the RPC example included an operation name (”placeOrder”) while the document oriented example did not. This constitutes an extremely significant architectural difference, as it tells us that Anne’s document example uses a state transfer style, while the RPC example does not.

But I have to disagree with Mark's assertion. And here I have to go back to the differences between HTTP and SOAP application protocol semantics. Mark makes the assumption that if the message does not include a method name, then it must therefore be using a uniform interface -- an implicit "processMessage" operation. But that's not how SOAP works. SOAP doesn't require that you specify a method name in order to map the request to a specific method. Per the SOAP specification, the SOAP node determines what method to invoke based on the qualified name (QName) of the child element of the SOAP Body element. It really doesn't matter if the name of that element is a noun ("purchaseOrder") or a verb ("placeOrder"). The QName determines the action to be performed. These SOAP semantics are fundamentally different from HTTP/REST semantics.

In REST, the "method" that will be invoked is always determined by the URL to which the request is sent, not by the contents of the request message. REST has a uniform interface, therefore a POST to a URL will always invoke the implicit "processMessage" operation.

In SOAP, the "method" that will be processed is determined by both the URL to which the request is sent and the contents of the request -- the QName of the SOAP Body. So, for example, a single service might support multiple methods: placeOrder, cancelOrder, getOrderStatus. Each method is invoked by sending a different document:

purchaseOrder invokes placeOrder
canceledOrderID invokes cancelOrder
pendingOrder invokes getOrderStatus

I guess my point is that document-oriented doesn't mean that its RESTful. SOAP semantics are just different from REST/HTTP semantics.

The future of the ESB market

2005-04-23T08:25:00.000-04:00

There's been some interesting discussion of late regarding the value of ESBs.

Richard Turner, a Program Manager at Microsoft, recently posted To ESB or not to ESB, which asks some questions regarding the usefulness of an ESB once Indigo is fully baked, and the WS-* stack becomes fully mature. In particular, Richard asks:

Does anyone out there want to build their Enterprise infrastructure on a technology from a single vendor, supporting a single platform?
Does anyone out there see benefit from building their Enterprise upon a technology which is closed and proprietary?

These questions pertain to the fact that most of the ESB products on the market today are based on Java and proprietary MOM protocols. (Note that IONA Artix is based on C++, it provides native bindings for C++, Java, COBOL, PL/I, and .NET, and it doesn't use a proprietary MOM -- so not all ESBs are Java- and MOM-centric.)

Richard concludes his missive with this question:

What value, therefore, is an ESB? To my mind, an ESB is smart-plumbing to which to attach dumb nodes. To my mind, the ESB approach is less about providing customers with value and more about extending attempts to lock customers into a given platform. How, for example, would I add mainframe nodes, COM+ nodes, Web Service nodes etc. running on different platforms and technologies on top of JBI/Sonic/ without the use of adaptors and translators? And more importantly, if I chose to change vendors, how would I replace my ESB with that from someone else?

In response, Dave Chappell, renowned ESB evangelist for Sonic Software , posted ESB and the Road to Indigo. Dave makes a few good points about the value of an ESB:

an ESB is based on a philosophy that a SOA should be configured rather than coded
an ESB can mediate between different protocols, API conventions, and invocation styles
an ESB supports incremental adoption of a SOA

My take:
I think an ESB provides an important value-add today, but I view it as a short term solution, and people should use it with caution. Many ESBs promote the deployment of proprietary protocols, and in general, I think that's something you want to avoid. You don't want to lock yourself into a proprietary solution now that open. non-proprietary options are available. I also agree with Richard that once the core platforms (.NET, WebSphere, WebLogic, CICS, etc.) and application systems (e.g., SAP, Oracle, etc.) have inherent support for secure, reliable, transacted web services, the value of an ESB will be greatly diminished.

The ESB market is heading for a severe squeeze play; expect some significant market consolidation.

The first comment posted to Richard's post asks this question:

With WS, WSE and Indigo, aren't there still some missing "pieces", such as Monitoring, Auditing, Exception Management, Measurement, Definition and monitoring of SLAs, etc.? Isn't this the space that an ESB should cover?

I think this is a really interesting question. Today, none of the ESB products provide this type of functionality. Instead, this is the territory of the web services management (WSM) vendors (e.g., Actional, AmberPoint, Blue Titan, Infravio, SOA Software, and most recently Oracle [who acquired Oblix/Confluent]). Now what I find interesting is that some of these players -- particularly Blue Titan and SOA Software -- are starting to deliver ESB capabilities, such as reliable messaging and format/protocol/invocation mediation. And Systinet, Cape Clear, and IONA (traditionally web services platform [WSP] players) are also supplying ESB functionality. The major superplatform players also have plans to deliver ESB functionality (Microsoft "Indigo", IBM "Pyxis", BEA "QuickSilver", Oracle "Fusion", etc.) I just don't see the stand-alone ESB market surviving the combined assault from WSM and the superplatforms..

When it comes right down to it, a web services infrastructure consists of three types of entities:

endpoints
intermediaries
registries

Endpoints are typically implemented using a WSP, although you can also implement an endpoint using an ESB. Essentially, an ESB provides a WSP for legacy applications (via adapters), and an ESB can expose a composite application as a web service (most ESBs provide an orchestration engine). Some ESBs (including Sonic) allow you to create a new POJO service, host it in the ESB container, and expose it as a web service.

Intermediaries intercept web services traffic and enforce policies regarding security, reliability, routing, transformation, mediation, event processing, orchestration, transactions, monitoring, auditing, etc. Intermediaries can run either as proxies along the message path or as interceptors within an endpoint. Both WSM and ESB products provide intermediaries. WSM intermediaries typically support security, routing, transformation, mediation, monitoring, and auditing. ESB intermediaries typically support reliability, routing, transformation, mediation, orchestration, and event processing. (Obviously there's a lot of overlap between WSM and ESB.) You can also build custom intermediaries using a WSP. Most WSPs provide a mechanism to implement interceptors (handlers) that run inside the endpoint. And you can also develop your own proxy.

Web service registries (WSR) maintain information about endpoints and intermediaries. Registries can be used at development time to discover services and metadata; and they can be used at runtime for dynamic location resolution or runtime service selection. Many WSM products also use a registry for provisioning and runtime management -- Amberpoint, Blue Titan, Infravio, and SOA Software all use registries for management.

The future of the ESB market
I expect the pure-play ESB market to go away within the next 3-5 years. Today there are about a dozen vendors promoting their wares as ESB. I just don't see the market supporting this many vendors for very much longer.

Consider what happened to the WSP market. Four years ago, there were about a dozon independent WSP startups. The only survivors today are Systinet and Cape Clear. And, in fact, neither company really markets itself as a WSP player anymore. Systinet is the leading independent registry vendor. Cape Clear is struggling to make it as an ESB vendor now.

Also consider what has been happening in the WSM market. Three years ago, there were about a dozen WSM startups. But since then, CA acquired Adjoin, HP acquired Talking Blocks, Oracle acquired Oblix which acquired Confluent, SOA Software acquired Flamenco, and Actional acquired Westbridge. At this point, the survivors are Actional, Amberpoint, Blue Titan, Infravio, and SOA Software. I anticipate further consolidation.

The ESB market includes Cape Clear, Fiorano, IONA, Polar Lake, SeeBeyond, Sonic, TIBCO, webMethods, and I'm sure a few others. In addition, superplatform players IBM, Microsoft, BEA, and Oracle are heading into this space. And Blue Titan, SOA Software, and Systinet all provide ESB-lite solutions. Definitely this market will experience some serious consolidation. More to the point, I expect that the ESB, WSM, and WSR markets will merge.

In the long run, maybe 4-5 players will survive. My bets are on Sonic, Systinet, TIBCO, and webMethods.

Web services are not distributed objects

2005-03-29T13:57:00.000-05:00

One of the most important concepts to understand about the web services framework (WSF) is that it is not a distributed object system. Web services communicate by exchanging messages -- it's more like JMS than RMI. The WSF doesn't support remote references, remote object garbage collection, or any of the other distributed object features developers have come to rely upon in RMI, CORBA, DCOM, or other distributed object systems.

The fundamental purpose of the WSF is to enable interoperability across dissimilar systems that don't necessarily understand concepts such as method overloading, object inheritance, and polymorphism. Hence web service interfaces should not expose these OO concepts.

A service should expose a document-oriented interface rather than an object-oriented interface. The basic best practices are:

Flatten object graphs. Don’t expose language-specific object collections, such as maps, lists, or datasets. Instead convert all collections into arrays.
Don’t use overloaded methods. Each method should have a different operation name.
Expose a "chunky" interface rather than a "chatty" interface. In other words, don’t expose getter and setter operations for every member in the object class.

These best practices relate back to the differentiation between message exchange versus distributed object systems. When using distributed objects, the object resides on the server side, and the client invokes operations on the object using a proxy. The client does not have its own copy of the object. When using a message exchange system, the client side application should have its own object -- not just a proxy. (And – by the way – the client’s object may be different from the server's object.) When the client communicates with the server, it simply passes data, not behavior. It's much more loosely coupled.

It may be necessary to build an abstraction layer between the WSDL interface and the application that implements the service. This abstraction layer performs the necessary mapping between the document-oriented WSDL interface and the application's object model. It also provides much better insulation for flexibility and change.

For best interoperability, developers should use document/literal with the “wrapped” programming convention. .NET uses the “wrapped” style by default. The JAX-RPC specification also requires support for the “wrapped” style. The "wrapped" style supports a programming model that makes document/literal feel like RPC style. "Wrapped" style is very similar to RPC/literal, except for two important distinctions:

.NET supports "wrapped" style, but it doesn't support RPC/literal
"Wrapped" style defines a schema of the full soap body (which makes it very easy to validate), while RPC/Literal only defines type information rather that the full schema of the message elements (which makes validation slightly more complicated).

Please see my previous blog entry on the "wrapped" style for more information.

The "wrapped" document/literal convention

2005-03-20T08:39:00.000-05:00

In my First Stop: WS-I posting, I recommended that web service developers always use document/literal, even though the WS-I Basic Profile allows rpc/literal. Some people might resist this notion, thinking the document style is harder to work with than rpc style, but that just isn't true. For developers that want an RPC-like programming experience using document/literal, all you have to do is use the "wrapped" convention.

Most SOAP implementations now support the "wrapped" convention. .NET uses it by default (and it doesn't support rpc/literal). All JAX-RPC compliant implementations also must support "wrapped". The "wrapped" convention yields the best results for interoperability.

The "wrapped" convention produces document/literal services, and yet it supports an RPC-style programming interface (i.e., it performs automatic marshalling of input parameters and return values).

The rules for the "wrapped" convention are fairly simple:

"Wrapped" is a form of document/literal, therefore it must follow all the rules defined for document/literal. When defining a document/literal service, there can be at most one body part in your input message and at most one body part in your output message. You do *not* define each method parameter as a separate part in the message definition. (The parameters are defined in the types section, instead.)
Each part definition must reference an element (not a type) defined, imported, or included in the types section of the WSDL document. These element definitions are "wrapper" elements (hence the name of this convention). You define your input and output parameters as element structures within these wrapper elements.
A wrapper element must be defined as a complex type that is a sequence of elements. Each child element in that sequence will be generated as a parameter in the service interface.
The name of the input wrapper element must be the same as the operation name.
The name of the output wrapper element should be (but doesn't have to be) the operation name appended with "Response" (e.g., if the operation name is "add", the output wrapper element should be called "addResponse").
In the binding definition, the soap:binding should specify style="document" (although this is the default value, so the attribute may be omitted), and the soap:body definitions must specify use="literal" and nothing else. You must not specify the namespace or encodingStyle attributes in the soap:body definition.

The following WSDL shows an example of the "wrapped" convention. It defines a simple add operation that takes two ints in and returns an int . This WSDL permits you to invoke the service like this:

int sum = addProxy.add(arg1, arg2);

Notice that the portType defines an operation called "add". It takes the "addRequest" message in and returns the "addResponse" message out. The "addRequest" message has one body part called "parameters" (.NET always uses this name for "wrapped" style). It references an element called "add". (The name of this input element must be the same as the operation name.) The "add" element is defined as a complex type that is a sequence of two elements (the input parameters), "arg1" and "arg2", which are both defined as ints. The "addResponse" message has one body part, also called "parameters", and it references an element called "addResponse". The "addResponse" element is defined as a complex type that is a sequence of one element (the return value), "sum", which is defined as an int.


<wsdl:definitions name=’addWrappedLiteral’

    targetNamespace='urn:example/wrapped/add'

    xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/'

    xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'

    xmlns:types='urn:add/types'

    xmlns:intf='urn:example/wrapped/add'>

  <wsdl:types>

    <xsd:schema elementFormDefault="qualified"

        targetNamespace='urn:add/types'

        xmlns:xsd='http://www.w3.org/2001/XMLSchema'>

      <xsd:element name="add" type="types:add_t"/>

      <xsd:element name="addResponse" type="types:addResponse_t"/>

      <xsd:complexType name="add_t">

        <xsd:sequence>

          <xsd:element name="arg1" type="xsd:int"/>

          <xsd:element name="arg2" type="xsd:int"/>

        </xsd:sequence>

      </xsd:complexType>

      <xsd:complexType name="addResponse_t">

        <xsd:sequence>

          <xsd:element name="sum" type="xsd:int"/>

        </xsd:sequence>

      </xsd:complexType>

    </xsd:schema>

  </wsdl:types>

  <wsdl:message name='addRequest'>

    <wsdl:part name='parameters' element='types:add'/>

  </wsdl:message>

  <wsdl:message name='addResponse'>

    <wsdl:part name='parameters' element='types:addResponse'/>

  </wsdl:message>

  <wsdl:portType name='addPT'>

    <wsdl:operation name='add'>

      <wsdl:input message='intf:addRequest'/>

      <wsdl:output message='intf:addResponse'/>

    </wsdl:operation>

  </wsdl:portType>

  <wsdl:binding name='addSoapBinding' type='intf:addPT'>

    <soap:binding

       transport='http://schemas.xmlsoap.org/soap/http'

       style='document'/>

    <wsdl:operation name='add'>

      <soap:operation soapAction='urn:example/wrapped/add'/>

      <wsdl:input>

        <soap:body use='literal'/>

      </wsdl:input>

      <wsdl:output>

        <soap:body use='literal'/>

      </wsdl:output>

    </wsdl:operation>

  </wsdl:binding>

  <wsdl:service name='addService'>

    <wsdl:port name='addSoapPort' binding='intf:addSoapBinding'>

      <soap:address location='...'/>

    </wsdl:port>

  </wsdl:service>

</wsdl:definitions>

Sun's new Java licensing is disappointing

2005-03-19T13:17:00.000-05:00

Last week Sun announced a new licensing scheme for Java. It's part of a larger plan, referred to as "Project Peabody", designed to increase transparency into the development process of the Java specifications and reference implementations.

According to Sun, "Project Peabody" has the following goals:

Simplify licensing practices
Increase transparency
Give developers a chance to contribute
While maintaining Java compatibility

Sun has devised three new licenses to replace SCSL (Sun Community Source License), which is the extremely complex license Sun now uses for Java source code. These licenses will apply to J2SE 6.0 ("Mustang"). The three new licenses include:

Java Distribution License (JDL)
Java Research License (JRL)
Java Internal Use License (JIUL)

JDL applies to anyone that wants to distribute a J2SE implementation for any purpose other than research. The license requires that the J2SE implementation must prove J2SE compatibility by passing the TCK (Test Compatibility Kit).

JRL is (supposedly) designed to support the needs of the research community. It permits research groups to develop and share J2SE implementations for research purposes. If anyone wants to redistribute a derivation of J2SE for any purpose other than research, that entity must obtain a JDL license and pass the TCK. J2SE 5.0 ("Tiger") is now available under JRL. Sun plans to release weekly builds of "Mustang" under the JRL, also.

JIUL (pronounced "jewel") is designed to support the needs of the average company that uses Java. It permits "users" (personal, academic, or corporate entities) to make fixes and enhancement to the Java source code for their own internal use. Such users are not required to pass the TCK, but they also may not share their fixes with other users (except for research purposes). JIUL relies "on the honor system" to ensure compatibility, but what that really means is that compatibility is not assured if you make modifications.

Sun has also developed a new set of contribution agreements. Developers are "encouraged", but not required, to contribute bug fixes and modifications back to Sun. Contributing developers retain rights to their code, but they must also grant all rights to the code to Sun.

My take on all this

First and foremost: JRL and JIUL are not open source. The first rule of open source is that it allows developers to fork the code. These licenses clearly prevent developers from forking the code.

At least Sun is upfront about it. They clearly stated that these licenses are not open source. Sun made the usual excuses about ensuring compatibility as their reason for not open sourcing the code. But I totally reject this argument.

Sun protects Java compatibility through the licensing of the Java brand, not through the licensing of the source code. An implementation may not be called "Java" unless it passes the TCK (Test Compatibility Kit). Using a GPL license -- or even CDDL (the new Solaris 10 open source license) -- Sun can use a dual licensing strategy to open up the source code, and yet still maintain a commercial licensing practice.

Sun is being greedy. They want the benefits of open source -- getting vast hordes of developers to contribute fixes and new ideas to the Java code base for free -- but they aren't willing to actually contribute the source code to the open source/research community.

I explained the JRL to an acquaintance of mine that has a research position at MIT, and his response was, "Well that's of no use. And why should I contribute my work to Sun?". Researchers want the ability to fork the code, and Sun definitely doesn't want people to fork the code -- that's the essence of the compatibility argument.

JIUL does offer some value to users. One of the most valuable benefits of open source is that it allows users to debug, fix, and tweak code to suit their specific requirements, and the JIUL does give a company that capability. I doubt, though, that very many companies will take advantage of this opportunity. Java is a bit too complex for most companies to want to muck around in. It's also potentially dangerous -- because if user companies do muck around in the code, they are likely to break compatibility.

When dealing with this type of code base, the real beneficiary of open source is the research community, which would like to work on building the next, better VM. But Sun doesn't want someone to build a better VM. Not unless they own it. Now, if they did a GPL license, then all modifications would have to be contributed back into the code base. From my perspective, Sun would be better off using GPL rather than JRL and JIUL.

First Stop: WS-I

2005-03-19T11:43:00.000-05:00

From my perspective, the most important set of specifications that developers should pay attention to are the WS-I Profiles.

A WS-I profile takes an existing set of standards and/or specifications and goes through them with a fine-toothed comb, finding all possible ambiguities (any place where the specification says MAY or SHOULD rather than MUST) and all places where some important behaviour isn't completely specified, and then the profile constrains the specs and says "don't use these features -- always do it this way". This type of profiling is particularly important when dealing with non-standardized specifications, such as SOAP 1.1 and WSDL 1.1, because these specs have a lot of ambiguities. But profiling is also necessary with more formal standards, such as WS-Security, which offer a broad spectrum of options and choices, or with UDDI, which provides a basic registry protocol, but doesn't go so far as to provide a specific model for registering services.

WS-I's first deliverable was the Basic Profile (BP). The WS-I BP defines guidelines for developing web services using SOAP 1.1, WSDL 1.1, and UDDI 2.0. There are many ambiguities, contradictions, and errors in the SOAP 1.1 and WSDL 1.1 specifications, so it's critical that developers follow this profile if they want to build interoperable web services.

WS-I has also defined an Attachments Profile, which defines guidelines for passing attachments using SOAP with Attachments (SwA). Unfortunatley, because Microsoft refuses to support SwA, the Attachments Profile doesn't really enable interoperability. I can understand Microsoft position on SwA, though -- SwA is a remarkably insecure mechanism for passing attachments. In the future (probably 2006), most SOAP platforms will adopt MTOM as the standard mechanism to pass attachments, and Microsoft is implementing support for MTOM in Indigo. (I'll be posting more on attachment mechanisms in a future blog entry.)

As the name implies, the WS-I BP is a basic profile -- meaning that it supports only basic communications -- it does not define how to use security, reliability, or any other advanced features. But it is the bible for how to build basic web services. The biggest constraint defined by this profile is that it disallows use of the SOAP encoding system. The profile describes in detail how to build web services that use either Document/Literal or RPC/Literal style message formats. I'll go one step further and recommend that developers build only Document/Literal services. Developers should avoid using RPC/Literal because many SOAP implementations (including the two most popular implementations: .NET and Apache Axis) don't support RPC/Literal. (Axis 1.2 can support RPC/Literal, but it doesn't work very well. Microsoft is adding support for RPC/Literal in Indigo. But even so, I still recommend Document/Literal over RPC/Literal. I'll be posting more on message styles in a future blog entry.)

WS-I is currently working on the Basic Security Profile (BSP). The group has published a very interesting document that discusses the various Security Challenges, Threats and Countermeasures associated with using web services. The BSP profile (which is still in draft form) describes how to use transport-level (SSL/TLS) and message-level (WS-Security) security mechanisms to secure SOAP messages.

Back online

2005-03-19T11:08:00.000-05:00

After five months of being offline, I figure that I have no excuse anymore -- it's time to get my blog going again.

For those of you that followed my previous blog, you'll know I'm not a frequent blogger. According to Rebecca Blood's blogging taxonomy, I maintain a "notebook" blog. I tend to write longer (hopefully informative) posts on technical subject areas. My favorite subject areas are web services and open source.

In my book, Web Services: A Manager's Guide, I promised to post periodic status updates on web services standards and specifications, and I am using this blog to fulfill that promise. For all the latest news on things happening in the world of XML, I also recommend that you visit Robin Cover's Cover Pages.

I'm also a regular contributor to the Apache Axis user discussion list, and periodically I will capture some of my more informative missives from that list and post them here.