Avoid JaBoWS as the Basis for your Enterprise SOA

Posted by Hartmut Wilms on Mar 21, 2008

Community

SOA

Topics

Web Services

Tags

Business/IT Alignment

Nick Malik declares JaBoWS (Just a Bunch of Web Services) are the enemy of Enterprise SOA.

In an earlier post on his blog Nick Malik first asked the question if your SOA is JaBoWS. With JaBoWS he does not want to start a discussion on technology, but on the general approach and goals of an Enterprise SOA:

I'm not asking from the standpoint of technology (are services secure, available, composable, etc) but rather from the business.  In other words, if the business wants to achieve flexibility through the SOA, do the available services represent the correct interaction end points to accomplish that goal?

In his opinion "Evaluating “how good” a SOA is means modeling out the competitive opportunities that are actually in the corporate strategy and seeing if the SOA can react to both expected and potential competitive moves". The SOA story is mainly about Business/IT-Alignment:

SOA saves money in some environments (especially ours), but it’s greatest value happens when the business can add a capability to meet a competitive opportunity quickly and inexpensively.  Speed is important.  Cost is important.  A Good SOA is structured to deliver on that promise.

He points out that traditional IT did a good job on "processes that changed rarely" and might or might not occur frequently. "The SOA Sweet Spot" is on the processes that occur frequently and change frequently.

In his recent post he declares that JaBoWS are not a bad habit of unsuccessful SOA initiatives of architecture teams that merely got it wrong:

JaBOWS is the dead end that kills value.  It is all that is wrong with top-down approaches that produce unusable services, or bottom-up approaches that produce overlapping and badly coordinated piles of services.  JaBOWS is the costly, time-consuming, valueless exercise that so many companies have taken upon themselves in the name of SOA.

Moreover according to Nick Malik JaBoWS poses a threat to the whole SOA community:

We all lose when any one company kills their SOA initiative for lack of value.  In the SOA community, we are all invested in the success of each company that has bought the hype.

Nick closes by calling on the community to start "writing about JaBOWS, and talking about JaBOWS, and sharing experiences about how to effectively avoid JaBOWS" and by defining a simple formula for JaBoWS:

It's not a tools problem.  It is a process and people problem.

Tools + existing processes = JaBOWS.   And that is baaaaaad.

Nick Malik's post is in line with Anne Thomas Manes' search for SOA success stories. As she points out all those beautiful (technologically driven) architectures, tooling and products "have yet to demonstrate how all this infrastructure yields any business value".

Scott Wilson  thinks that Malik's manifesto is a "simplistic characterization of what is bad and leads inevitably to JaBoWS":

I feel as though part of the problem with many of the tools which he rightfully decries is that they attempt to do exactly that; but I think that it is those restrictive, imposed definitions which cause many of the problems in enterprise SOA implementations. Instead, I feel about SOA as I do about ITIL: it's a concept that needs some flexibility to be useful in every instance. Imposing restrictive stamps on what it is and is not makes a lot of sense within a given organization, but I'm not sure it's a good idea for the concept as a whole.

Mike Kavis makes a case for BPM as the main driver for any SOA initiative:

The problem with SOA isn't SOA, it's people. People must understand SOA and the importance of aligning their initiative with a key business driver. BPM is the killer application that can get your business sponsors on board. And finally, you need strong leadership with a focus on change management to pull it off.

What do you think about JaBoWS, tools, BPM, and Enterprise SOA?

1. Back to top

   About time...

   Mar 21, 2008 11:09 AM by Lars Tackmann

   It is about time that this was brought up. Most SOA solutions I have come across are hideously ugly and generally broken. They all seam to be lacking in one or more of the following areas:
   
   
   
   - testability: just like messaging solutions are hard to test so are most SOA architectures. It is hard to run tests with services that uses queuing (i.e. having to wait on some thread to swing though a work queue). Also remote service calls often triggers so many side effects that tests cannot be rerun.
   
   
   
   - documentation: I have seen a endless stack of outdated XML specifications. Sure this can be fixed with WSDL, but often people just have a Plain Old XML Service (POXS) and resort to hand written documentation. REST also fails in this area (although publishing a WADL document and a xml schema can partly make up for this).
   
   
   
   - development speed: this is perhaps the biggest problem. Often the impact of change in existing SOAs is so unpredictable that development slows down considerably. Versioning might help to a certain degree, but often proves to inflexible (i.e. the trouble of getting existing systems to deal with multiple remote versions). This often leads to quick fixes (like exposing new service via a stored procedure) which then leads to software rot, leading to increased development time
   
   
   
   In general:
   
   1) Design for change, think versioning in from the start. How would you expose the same business logic via multiple service interfaces ? (ROA can help)
   
   2) Design for testing. It should be possible to execute a series of remote calls and then reset the system. Either by exposing a transaction service or simply by exposing clean up methods.
   
   3) Keep it Simple. Most SOAs are heavily over over-architectured, requiring massive system knowledge about before beeing able to implement even simple new functionality. I use the "work from home test" to judge a systems complexity. If I am able to pack a few VMWare/Xen images on my laptop, bring it home and start hacking right away then the architecture is properly well designed - if not then it is neither designed for testing nor for simplicity.
   
   4) Performance. Concepts like work queues, transactions, guarantied transfer all implies degenerated performance. Think about why you need them, their configuration (how does one system get speedier access than another ?, how do we implement reliable transfers for only certain systems ?....).
   
   5) Be RESTful. The best services are those who survives multiple applications and are used in ways they where never designed for. Learn the virtues of RESTful design, even if you are a SOAP head.
   
   6) Don't make it a service unless it has to be. I have seen functionality exposed via services, that should obviously have been a stored procedure or REST/SOAP services that was much better of as Corba/JMS.- the list is long so in short use the best technology for the job, if it does not fit into a service then perhaps it should not be one.
   
   
   
   These problems does not mean that all SOA is bunk, I am still confident that it can e done right. I am just yet to experience it myself.
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

   Reply

2. Back to top

   Two new viewpoints

   Mar 22, 2008 8:08 AM by Hartmut Wilms

   I just added links to Scott Wilson's and Mike Kavis' views on the topic.

   Reply

• Older >