Saturday, July 23, 2011

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

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.

Tuesday, January 27, 2009

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.

Thursday, January 22, 2009

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

Thursday, January 08, 2009

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 web site to
  • 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".)

Monday, November 19, 2007

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

Friday, June 01, 2007

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:

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:


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.

Sunday, March 04, 2007

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.