Home > SOA > From JBOWS to JABERS – the holy grail called SOA is still nowhere in sight

From JBOWS to JABERS – the holy grail called SOA is still nowhere in sight

Joe McKendrick, that I’ve had the pleasure of working with on several occasions, created a new word a few years back. He called it JBOWS. I really like the sound of that word, try it by yourself: JBOWS [DJEYBOUS]. Anyway, JBOWS is not only a word it is also an acronym: Just a Bunch Of Web Services. Joe correctly identified some big gaps in the application of service-orientation in the new so called services and architectures of services that were to take companies closer to the holy grail called SOA

Web Services was seen as an almost failsafe path to salvation, and everybody was doing it. The problem was that while everybody was focusing on the new hot and cool technology called Web Services they forgot the really important things namely

  • Clear strategic leadership
  • Prioritizing business value
  • Corporate culture
  • Proper incentives
  • Service discoverability
  • Interoperability
  • Opportunities for reuse
  • Making the services evolvable
  • Service level agreements
  • Testing the service-oriented architecture
  • Monitoring services
  • + several other important things

If you’re not even close to target when it comes to these things you can forget about the true benefits of SOA. Most of, or perhaps all, those nice SOA goals and benefits will elude you. But you will still be subject to some of the extra work and other costs that attempting to build services and service architectures inevitably will bring along. Quite a few companies ended up supporting the JBOWS architecture instead of SOA.

During the latest years there is a new fire in the universe. It is considered to be better, simpler and more elegant than Web Services. It is called REST. Not all RESTafarians  are fanatics about REST, but they all agree that REST is more elegant. Actually, the RESTafarians may not be all wrong.

In spite of all this elegance and simplicity, if you miss out on the really important things, REST will not help you attain the goals of SOA or anything remotely similar. So I think that we need a new word to bring the balance back into the universe:

JABERSJust A Bunch of Elegant REST Services

(Pronounced [DJA:BERS] in case you wondered)

  1. 2010/05/10 at 13:49

    Great points! I will be checking back here often!

  2. 2010/05/14 at 16:16

    Hi Herbjörn

    good post and interesting neologism!

    I agree with you that you can get into services hell (JABERS or even JBOWS) without clear service development guidelines and governance. One aspect are data models – these you need in REST and WS. Other aspects include security token format, messaging patterns, policies, and so on. If individuals develop services purely tactical without a common vision and guidance you gain nothing and may end up with a gigantic SOA hairball. Therefore, I think it is essential that services are not just develope bottom-up (as is the case in so many integration projects) but that there is a complementary top-down modelling approach in place.

  3. 2010/05/14 at 18:33

    Just wondering: what’s the cathedral in the photo? the portal looks absolutely amazing. But then JABERS (!!!) may be hiding behind! uuaaahhhhh!!!

  4. 2010/05/17 at 08:02

    I agree to a certain degree only.

    Of course no technology approach will magically make everything better, and REST is no exception. But still, there is still something inherent in the the “correct” use of Web technology that furthers unplanned re-use without creating the typical JABOWS mess: The whole concept of URIs and links has been built to support bottom-up growth without losing integrity.

    That’s not to say that governance is unimportant when REST is applied to a company’s IT, but it’s more clearly assigned the role of regulating only what needs to be regulated, e.g. media types, link relation types, maybe some headers or other meta-data that’s standardized on a corporate level etc.

    • 2010/05/17 at 21:40

      The biggest problems with JBOWS and JABERS architectures are that services have overlapping functionality, are not interoperable (I do not agree that REST services are interoperable by default) and are not discoverable. The proper application of URIs will not solve any of those problems.

      • 2010/05/17 at 22:43

        I didn’t claim it did, just that there’s a difference between the models particularly related to unforeseen re-use.

    • 2010/05/18 at 19:48

      I think that the main reason why neither REST or any other approach in itself will ‘magically make’ anything better, as far as getting closer to SOA is concerned, is that REST is a technical solution. It sure makes life easier in some aspects when working with web services, but in itself does not do anything to bring us closer to a SOA (it may enable us to do so but it is all up to what we do with it).

  5. 2010/06/26 at 05:52

    For REST to be applied meaningfully you have to treat the uniform interface constraint with due respect. Resource identifier syntax, methods, and media types must all be standard to achieve the point of uniform interface: That you can configure connections between services and consumers dynamically in order to get information from point to point in the architecture, rather than having to write integration code to make this happen. Without standardisation of all facets you won’t see the kind of runtime discovery and exploitation of services we see when a browser interacts with unexpected web sites.
    Likewise: If you only apply the constraints of REST you can only expect to get something resembling the Web. As you say, that’s lots of overlap of functionality and different groups competing with each other. Well, that’s the point of the Web. It’s supposed to be that way. But if we want to make REST architecture work in the enterprise we have to look at it from a SOA perspective and do all those SOA governance tasks that we keep forgetting to do. REST won’t solve those enterprise efficiency problems, not by it itself. However, if you are doing the SOA part right then REST can take interoperability and development efficiency to a whole new level through better protocol consensus and reuse.

    • 2010/06/26 at 07:51

      Well put Benjamin. As you mention, the protocol part will need less of an integration effort. This is mainly due to the great level of standardization within the enterprise, as per the Canonical Protocol pattern. This means that if you achieve the level of standardization that you are referring to, using something else than RESTful HTTP should give you similar benefits. However, there will be quite a lot of integration work to be done thanks to great differences in data-model and process. Unless an SOA initiative is well on the way.

  1. 2010/05/11 at 19:03
  2. 2010/05/11 at 19:48
  3. 2010/11/19 at 10:30

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: