Showing posts with label soa. Show all posts
Showing posts with label soa. Show all posts

21 November 2007

Some Online Articles on Tags+Folders, Rule-based-Systems and Governance

Just minutes ago I struck a deal with SIGS-Datacom, publisher of the (German)
OBJEKTspektrum and JAVAspektrum, so that my recent articles in those magazines are now available as pdf-downlad for free...



  • Ordnung 2.0: Hilfe für den Info-Dschungel: Reality-Check von tags-versus-folders



  • Wohin mit der Logik: Regeln als Rettung. Der Artikel beschreibt, wie Sie Fachlogik mit Hilfe von Regelmaschien aus Ihrem Quellcode auslagern können - mit viel Flexibilität und signifikanten Risiken...



  • SOA Governance ist ein wesentlicher Erfolgsfaktor für SOA. (Mit Arne Koschel). Bei unserem Plädoyer für SOA-Governance gehen wir davon aus, dass für SOA

  • Regelbasierte Systeme (mit JBoss-Drools). Der Artikel stellt JBoss-Drools vor, einen bewährten Open-Source Vertreter Java-basierter Regelmaschinen.



SOA Governance: Crucial Necessity or Waste of Time?

As I occasionally worked on SOA Governance during the last few years, I took the time
to write up this article on InfoQ (did you know that is a great platform?)

From the intro:

The term "governance" has been regularly appearing in IT publications and conferences for some time, but among technical circles, such discussions are often yawn-provoking at best. This article provides a developer-friendly guide to SOA Governance, starting with the general notion of IT governance down through design-time and the second runtime Governance.


I'm eagerly awaiting your comments...

04 September 2007

Enterprise Service Bus - Features, Usage and Critique

I recently presented some statements about the mysterious concept of ESB, the under-defined enterprise service bus. People seem to expect different things from an ESB, so I'll try to summarize a few points here:

As our industry is not really sure what an ESB really is, I'll give you a few definitions:

Defining ESB
  1. "An ESB provides an abstraction layer on top of an enterprise messaging system which allows integration architects to exploit the value of messaging without writing code." (Abbreviated from Wikipedia).
  2. An ESB, a.k.a "service container is the physical manifestation of the abstract endpoint, and provides the implementation of the service interface. A service container is a remote process that can host software components. In that respect, it has some similarities to an application server container, but with the specific goal of hosting integration services" (from David Chappell, who actually invented the term ESB and has written a book on the topic).
  3. The OASIS SOA Reference Model calls the ESB a communication infrastructure and defines: The primary task of any communication infrastructure is to facilitate the exchange of information and the exchange of intent...Especially in the case where the exchanges are across ownership boundaries, a critical issue is the interpretation of the data. This interpretation MUST be consistent between the participants in the service interaction. (found on fantastic InfoQ, where ueber-blogger Stefan Tilkov is content-editor for SOA...)

Most likely, you're still uneasy wether to use an ESB or not... read on:

Functions an ESB can (and should) deliver

Again, quoting Wikipedia, an ESB has the following characteristic functions:
  • Support for invoking (remote) services, either sync or async, with a variety of transport protocols.
  • Capabilities to route messages to appropriate destinations (addressing, dynamic-, content- or rule-based routing)
  • Capabilities to transform messages (between protocols, data formats,
  • Service Choreography or Orchestration: Ability to create and execute complex (business) processes based upon existing services.
  • Integration of other service providers, like encryption, signing, authorization, authentication, data transformation, compression.
  • Management of services, like monitoring, logging, administration.

The problem persists: Do you (or your organization) really need that stuff?

ESB values
In his great article "ESB-oriented architecture: The wrong approach to adopting SOA", Bobby Woolfe (co-author of the famous Enterprise-Integration-Patterns book (excerpts of this available here)) argues that an ESB itself does not create value:

An ESB by itself produces no business value. An ESB is a means to an end, not the end itself. An ESB is like the electrical wiring or plumbing of an SOA. Plumbing does not produce value; sinks with water coming out of their faucets do. Wiring does not produce value; lights, especially lights connected to switches, are valuable. A road is not valuable except that it enables you to get from one point to another. An ESB without an SOA is like a road from someplace nobody is located going to other places nobody wants to be. People might eventually want to go to those places, but in the meantime, the road is all cost and no benefit.

He continues:

"Develop an ESB as part of developing the SOA. You will discover services based on business needs. Each service requires not only providers and consumers, but also a channel in the ESB to connect the two. That channel implements the service interface just like a provider (but acting as a proxy), including message formats for service requests and responses that enable remote invocation (such as interprocess communication) of the service. Differences in the consumers’ and providers’ service interfaces, message formats, scope, and qualities of service can be bridged and facilitated by mediations. All of this is the core of ESB design, and none of this can be done without knowing the services the ESB invokes. And knowing those services requires knowing the services in the SOA that will use the ESB.

In this light, connecting the applications is the easy part. Connecting their business functionality is the much greater challenge. That cannot be achieved by building only an ESB.

Potential Disadvantages of ESB

  • * You're stuck to a specific vendor, if your ESB does not adhere to open standards.
  • * Additional translation layer on top of conventional messaging systems - added complexity.
  • * No established industry standards, no clear product scoping, everything is pretty much vendor-centric.
  • * The current state of Open-Source ESB's, September 2007, is not amusing:
    • Both ServiceMix and Mule are pure horror to install and try-out. Both are, from my personal point-of-view, in research-state and not production-ready.
    • Corrected due to comments from Andrew P: I tried the Sept-07 versions of both ServiceMix and Mule, both can be installed without problems. Apart from having improved their install & config process, both now have excellent documentation. Sorry for calling them "research-statte" - my fault.
    • SOPERAs ESB cannot even be downloaded, they promised to snail-mail a DVD (which did not arrive so far, but it's only 6 weeks since I asked.).
    • Haven't tried JBoss and others yet...

Further Resources

25 August 2007

Want to understand the REST architecture pattern?

For you guys who never heard of REST - it might be time to have a deeper look...

Via Pete Lacey I found a cute presentation on REST resources (some are "behind a registration wall", but at least free).

Really great: The audio-enhanced REST Take 5:
A Take 5 is an audio enhanced five minute PowerPoint show on a pertinent topic. The REST Take 5 is really 15 minutes, but gives a good 40,000 foot, managerial overview of REST.


(the registration at Burtongroup DID suck, but their support fixed it within the hour... why don't they support OpenID or the like??)

30 May 2007

SOA-Expertenwissen erschienen...

ab heute (30. Mai 2007) gibt's fast 900 Seiten geballtes SOA-Expertenwissen
als Buch - herausgegeben von Stefan Tilkov und mir :-) verfasst von 50 namhaften (deutsch & internationalen!) SOA-Cracks...

Wir haben eine hoffentlich informative Website dazu aufgebaut (designed by Dirk Hesse).

Eine ausführliche Ankündigung mit vielen Download-Links hat Stefan geblogt.

22 May 2007

SOAX: Leseproben online

Der dpunkt-Verlag hat zum Buch SOA-Expertenwissen nun einige
Leseproben online. Viel Spass beim Schmökern.

Übrigens ist auch die neue Version der Website zum Buch seit einigen Tagen live, nunmehr basierend auf Textpattern und einem ordentlichen Design.

06 April 2007

SOAX: Our Toolchain for Editing and Writing

Together with Stefan I took the adventure of editing the 750+ pages (german) SOA-Expertenwissen book. It took us nearly 12 month to complete, time enough to gain some (further) experience with the various tools that helped us master this quest (btw: I'll surely talk about several aspects of the books' content in future posts here).
Let us start right at the beginning, some nice day in May 2006: Günther Fuhrmeister motivated both of us to start - and we began with sketching and refining the books' mainline, its goals, motivation and target audience. Call it distributed brainstorming what we did by then - Mindmaps (based on MindManager) provided the needed support for creativity and order. Just in case you don't practice mindmapping: start with it, no kidding!

Ok - we developed the initial structure and many ideas for prospective authors (around 40 by June/July 2006) - but how to organize that many (distributed) contributors? We used the web-only database DabbleDB to get things going: Both editors and the publisher could get a timely overview of the books' progress. It took about 2-3 month to discuss individual contributions with the designated authors, to re-align the structure according to the ongoing discussions with the authors.

When the structure stabilized and we received the first couple of contributions, we set up a subversion repository (remotely accessible) and transfered the contents of our Dabble-database to an outliner document (we editors both use Macs, so OmniOutliner was the first choice here). First little problem here: OmniOutliner documents are stored in directories (not in single files) - subversion sometimes doesn't like that... be prepared for trouble in case of conflicts...

Right - subversion saved our neck several times. Never ever begin a real-world IT project without version control in place. Never. (You DID know that, did you?)

Starting September/October, contributions (and new authors) flooded our desks. All authors stuck to Microsoft Word (tm) for their texts - but diagrams were drawn in a variety of formats (mostly Visio, Powerpoint and OmniGraffle, a few with OpenOffice). No problem here - the publisher could deal with those formats.

Mixing Word-files (doc-format) between Mac and Windows is no problem in just about 94% of all (our) cases. We had more then 50 files to deal with - 3 (three) made real trouble: Hangups and loss-of-formating - on our Macs... can you imagine our disappointment? We called NeoOffice (based on OpenOffice) to the rescue - which managed all problematic files without any disturbance. Changelogs and comments within Word files really helped all stakeholders, although version-management with Word is a nuisance. No way around manually verifying you have the correct document version at hand... which subversion could have done a lot better (merged, detected conflicts) with pure text files.

Then we began setting up the books' website. I initially used RapidWeaver - but we encountered serious problems in committing our website sources (rw3-format). RapidWeaver pretty often crashed upon trying to open updated files - therefore we had to compress them and check-in (commit) the zip-files. Unneccessary burden! We'll switch to the textpattern content management system (I'm still very happy with RapidWeaver for my own website, which I manage on my own... Conclusion: RapidWeaver is not ready for distributed workgroups).

My personal conclusion:

  • MindManager and OmniOutliner to structure and manage - yes, again, with pleasure.

  • Word (tm) for writing and editing: A compromise, and not a pretty good one: It distracts authors from producing contend, suffers from severe featuritis and (unneccessarily) motivates everybody (myself included!) to care about the most worthless aspect of writing: layout. We all wasted hours with layouting - let publisher care about that (they do it faster and better!).

  • Next time I will talk my publisher into some pure textual format (like markdown, textile or some of those evil xml-dialects)... just to refrain myself from that layouting mumbo-jumbo. Markup'ed files can be spell-checked as (least as) good as doc-files, changes between versions can often be resolved by subversionn.

  • Ok - once upon a time I tried DITA - which I found to be a straight overdose of markup.

  • RapidWeaver: Only for personal sites with one editor.

  • If you manage distributed teams and do NOT know skype, look for another job.

  • Writing books on a Mac is surely more fun than on other machines, but still a lot of work (oh - you could have guessed that before...).



Further references


  • A series of posts from Pragmatic Dave on writing books...

  • Frank Jagla pointed me to Ulysses - which I did not use so far, but it looks promising.
  • 26 March 2007

    SOAX: Gerade im Layout

    das Buch "SOA-Expertenwissen", (Hrsg. Stefan Tilkov & Gernot Starke) befindet sich gerade im (finalen) Layout beim dpunkt-Verlag. Wir rechnen mit über 650 Seiten - Erscheinungstermin ist momentan noch mit Anfang/Mitte Mai geplant. Alles wird gut :-)

    10 February 2007

    One more SOA-definition: "a mess waiting to happen"

    While editing our forthcoming SOA-book (german) I found a nice definition of SOA by Jim Kobielus in a Network-World article:

    "...SOA also is a mess waiting to happen.
    By encouraging widespread reuse of scattered software components, SOA threatens to transform the enterprise network into a complex, sprawling unmanageable mesh."


    He gives this definition in the context for his call-for-governance...