Tag Archives: SOA

You did what with your ESB!?

Posted on by

I’ve seen many enterprise service bus (ESB) implementations that are, well, quite extraordinary.  Sadly, they are extraordinary for more wrong reasons than right.  Given that we had a SOA frenzy not too long ago, many developers got caught in that feeding frenzy.  Hey, when you’re a shark off the south coast of Kwazulu-Natal in winter, everything looks like a sardine.  In fact, if you were a tiny sole, just wandering around at the bottom of a big sea, chances are you also wanted some of them some sardines.
That was a long time ago, but now that we get to see the extraordinary things that developers built with their ESB.  Here are my top five extraordinary things.

#5 Look, we can synchronize our databases with our ESB

You have two application databases and you want the changes in one to be propagated to the other.  The ESB seemed like a perfect way to spray data around.  Hey, just give me an end point and I’d pump some data through it.  Well, syncing data is a replication problem with different challenges such as change detection, conflict resolution, retry or abort strategies, and bulk materialization on both ends when things get horribly out of sync.

#4 You can call my stored proc from the other side of my ESB

Somewhere in your app you had something that called a stored procedure. The ESB seemed like a really easy way to wrap that SProc with a service and hand out a new end point.  Cool, now everyone can call your stored proc.  Well, perhaps that original thing that was calling your stored proc was a wrong architecture decision in the first place.  If it was the write decision, suddenly opening it up to multiple callers that you have no control over means you got to be certain about whether your SProc is re-entrant, can handle the concurrency, and a whole lot more. 

#3 My ESB now manages my transactions

Enough said.

#2 My authentication runs as a centralized service on my ESB

Login seems like an easy enough “hello world” service to get up and running.  Hey, since our ESB has all of these apps hanging off it, we can get our Login Service to do single sign on (SSO).  We just need to call all the login services for each app and front it with our single sign on service and then this service will dish out authentication tokens.  Oh, we might as well put in a centralised authorisation service too.  Well, firstly, login is not a service.  You can take that thought further from here.

#1 I replaced my call stack with my ESB

To be fair, most developers don’t know that they did this.  Let me explain.  You had some app that called a method that calls a few more methods and so on.  We all know that this builds up a call stack that gets popped on the return path.  When you take those classes that have those methods and dump them as services on your ESB, the call stack has not changed, but now there is an ESB in between.  Well, you can’t just shift classes wrapped as services to your ESB.  You actually have to get service oriented in your architecture.  Only then will that call stack change.

It’s not surprising that we see this now.  It takes a long time for an architectural style to be understood.  Unfortunately, there are some costly mistakes along the way.  We also can’t blame the ESB, but, beware, the sardine run happens every year.

Your ESB is going to kill you

Posted on by

Recently I wrote about the fruitless plight of a schizophrenic service.  Now, I think that some of that schizophrenia exists in the ESB too (or is it rubbing off onto the ESB?).  I’ve always felt that the ESB was just another pattern that showed how to isolate things and deal with routing and transformations.  The most common implementation was a messaging gadget with some pluggable framework of sorts for the transformations, and some configurable framework for routing.
With such isolation of parts, it was convenient to not worry about what happened elsewhere when something was thrown to this gadget for processing.  And we started wondering about scalability things and decided that asynchronous was the way to go … disconnected, stateless, etc, all good, well-intentioned things and useful things.

Then the pattern became a product.  And on top of this product we had more products like business process orchestrators or workflow managers.  And below this product we had applications and databases and ftp locations and all sorts of things that catered for every imaginable protocol.  And around all of this we had some enterprise-ish sort of management thing to keep on eye on everything that was happening inside this very busy product.

Then, services moved from applications to the ESB product.  After all, it’s a service and that’s an enterprise service bus, right?  And when the services where moved over to their new home, all the dependencies had to come along too.  And then we started arguing about getting granularity right in the ESB.  I used to just think that the ESB had a proxy of sorts to the service that still was at the application.  Maybe I got it all wrong.

Now this ESB is starting to feel like an Application Server with a messaging gadget, workflow gadget, transformers, routers, protocol handlers.  And some ESB’s have a web server too, since they have browser based management consoles.

Some people also like the idea of a rules engine for their complex domain rules and embedded those in their applications.  Hold on, those content based routers in the ESB also used a rules engine.  Ok, let’s move our rules over to the ESB too.  Cool, my ESB is also a rules engine.

Now, I see people writing the most hellish XML that is meant to do everything from configure routing, define transformations, execute code, persist messages, fire off sets of rules and more.  It reminds me so much of those weird and wonderful stored procedures and cascading triggers that we wrote.  The other day I got a laugh out of a friend when I told him that ESB’s are now DB servers and everyone writes sprocs in XML.

And we tried to do everything in the database server – rules, custom types, defaults, constraints, sprocs, triggers, batch jobs … even jump into a shell and execute something else.  It did not work out very well then.

If I was an ESB, I’d be very confused.  I started life as a pattern with a reasonable implementation using messaging and transformation and routing.  Now all of this.  In fact, I’d be more stressed than confused.

Then again, maybe the ESB is not confused, and maybe the people that use the ESB that are confused.  In fact, if I was one of those people, I’d be stressed too.

Domain Specific Reference Architectures

Posted on by

Many big vendors have invested a lot on blue print or reference architectures.  I came across another in recent months.  I witnessed a vendor team moving from client to client implementing this reference architecture as part of their SOA solution.
What were they actually doing? They were mapping the client’s domain to the reference architecture domain and thereby identified reference architecture services that supported the client’s needs.  This most probably works for some people.   But I feel uncomfortable with it because…

  • It means translating from one domain to another and back again.  It’s like having one massive bounded context around the reference architecture with a gigantic set of adaptors and transformers.
  • There is a very real possibility of semantic impedance on the boundary of the two domains.
  • There is likely to be two domain vocabularies or one large polluted vocabulary with synonyms, etc.

There are other reasons but these few are just old problems and habits coming back again.  Things that we accepted as dangerous and limits success in creating good software.

So, are reference architectures bad? Yes and no.  Maybe you should consider adopting its domain vocabulary as a first step.  A reference architecture with a rich metamodel is more likely to be more valuable than one without a metamodel.

And the moment you start thinking at a meta level, then you’re moving into a higher level of abstraction.  In this higher level, you will have a greater opportunity to describe your intentions agnostic of the reference architecture and the vendor’s technology stack.

The way I see it, services are defined at a meta level.  They describe your intentions and are independent of a reference architecture.  However, if you chose a reference architecture up front, then describe your intentions in the vocabulary of the reference architecture.

Does this make sense?  Because I’m just hypothesising here.

The Reincarnation of SOA

Posted on by

Anne Thomas Manes wrote a farewall for SOA in her blog post SOA is Dead, Long Live Services.  InfoQ asked for comment from SOA thought leaders and architects on this matter which created quite a stir and the usual amount of noise as well.  One of the most interesting responses I read was from Stefan Tilkov in his blog post Defending SOA.  Now I cannot resist, but give my perspective.
SOA is an attempt to create an architectural style that embodies the heart of the business – the domain.  In any business the domain is vast and so there are many subdomains or even very distinct domains.  In my workshop on Bootstrapping Your SOA Project, I defined a service very traditionally as providers and consumers connected by some execution context that hides implementation.  Now, I like to abstract it a bit more and think of services as business intentions.  These intentions cut right through the fat and get very close to the bone which is all about the domain.  That’s why I think DDD is at the heart of SOA.

Is SOA dead? Not yet but the vendors are doing a great job of killing it with implementations.

Should SOA die? No.  it’s an architectural style worth cherishing since it deals with legacy and new software at the same time, hence spanning multiple systems (like Stefan Tilkov nicely explains).

Does SOA need an ESB? Not necessarily. I think the ESB is just a pattern that happens to have an implementation called the ESB (vocabulary that sucks!).  I have seen some some really complex solutions with an ESB that would have worked just fine with, for example, a simple RMI call instead.

Is it about Business Process Management? Partially.  When you span multiple systems then you will likely do so with processes.  But it’s all about managing state across multiple systems and what nicer way is there than transferring state, i.e. being RESTful (and I am not talking about REST over HTTP).  This also suggests that you should think asynchronously as well.

Is SOA heavyweight? No.  But the vendors make it very, very heavyweight because that is the core of their economic model.  I like to think about all the little Unix command line tools that you can string together to solve a particular problem, like the FindAndDeleteAllOldLogs capability that is part of the FileManagementService 🙂

What is killing SOA? The lack of readiness for existing systems that comes from existing software development thinking in most teams.  SOA demands that you think about state, scalability, ownership, backward compatibility, testability … things that go towards creating decent API’s for your systems.  And the more vendor swagger we have, the less development teams think about API’s.

Is SOA Dead? Yes.  It was still born.  But it will be reincarnated as SOA when vendors focus on tools to help people discover domains and increase automation, and not creating heavyweight obstructions;  and when developers figure out that domain understanding is vital and writing good API’s  still count – more than ever before.

Services are Intentions

Posted on by

I was talking SOA – again! I was arguing that modeling of services in UML, BPEL, and any other fancy acronym immediately constrains you to a specific implementation.  For example, UML means that your are thinking OO already, BPEL means that your are thinking business processes already.  But are those (and others) the best ways to model or represent a service?
In SOA, I have a suspicion (as yet untested!) that a service is closer to an intention than anything else that I can think of because it describes the latent value of the business that invariably is lost by SOA implementations and product stacks.  Now that leaves us with a problem – how do you describe intentions consistently across any domain?   I don’t know how to do this because to describe intentions in a domain, you need to understand the vocabulary of the domain.  Until we can represent vocabularies then only can we create a metamodel for these business intentions.

So how do we model intentions in a single domain since I cannot use UML (implementation!), XPDL (implementation!), BPEL (implementation!) etc?  Since the domain is constrained by its vocabulary, we need to create a language that uses this vocabulary.  And that, my dear folks, is nothing but a DSL.  If we, therefore, model intentions (the services) with a DSL, then we are in a position to translate or transform that intention into any implementation that we like.  Realistically, we will likely need additional metadata surrounding the intention described in the DSL to satisfy UML, XPDL, BPEL, WSDL, RESTful APIs, etc.

When we think of the business as what they intend to do or achieve, then we are actually working at a higher level of abstraction – at a meta-level.  That is hard to do, but if you do it reasonably well, then you have more freedom when it comes to implementation.

SOA is so screwed up at the moment and most are climbing into or out of rabbit holes because the business intentions are being ignored or forgotten far too early or thought about far too late.  Perhaps the most effective SOA implementations will be realised with a suite of DSL’s and the only toolset that you really need is a language workbench and some very skilled language oriented programmers.

SOA is a wicked problem

Posted on by

I had a really interesting discussion this morning with two bright people about their SOA journey.  They are responsible in many ways for moving their rather massive company to SOA.  So we chatted about all sorts of things and argued and disagreed and converged and disagreed again and got confused and converged again and diverged again … and then we realised 2 hours had gone by and we all had other things to do.
Driving back to my office, I was bothered by the fact that we were struggling with how to implement this thing called SOA.  And I also have a feeling that there are more SOA failures than successes in the world.  And all these contribute to experiential knowledge for the greater good of our geek community, blah, blah, blah.

But I did not have a clear cut solution, neither did they, neither does their vendor partner (for sure!), nor their management, nor anybody!

So, I am now convinced that a SOA implementation (not theory!) is a wicked problem.  Wicked problems come from social sciences to describe an extremely difficult problem to solve, even impossible because of contradictory or ever-changing factors or incomplete requirements.  Some characteristics of wicked problems include:

  • every solution is a degree of goodness (or badness) but there is no distinctly right or wrong solution
  • every solution is a one-shot solution because you don’t have room for trial and error
  • consequently, every solution attempt counts immensely … positively or negatively
  • there is no uber-test of a solution, so the proof is in the execution (my TDD blood froze about now 🙂 )
  • each problem is symptom of another problem, indefinitely, i.e. there is no stop rule.
  • stakeholders all hold different understandings of the domain
  • there is no solution, but the problem is understood only after a solution has been crafted.

And last, but not least … maybe the most telling is

  • Those that are held accountable for the consequences of the solution have no right to be wrong ! Ouch 🙂

I think that some architectural things feel like wicked problems.  Read the work of  Jeff Conklin and Robert Horn, two guys that spend a lot of time researching tools for solving social messes.

Øredev 2008

Posted on by

I’ve mentioned it in bits and pieces before but now that the nice folk at Oredev have more or less finalised their program, I can put the down the talks I will be giving in November 2008.

I certainly did not expect to be doing 4 sessions!  It’s going to be a busy conference but also immense fun.  I hope that I get the time to attend the other talks and learn from some amazing people.  I certainly will be catching up with old friends as well

Top Down SOA: Aligning Business Functions

Posted on by

Yesterday I had a really fun time running a workshop at the IQPC SOA conference on Structuring your SOA Project.  It was interesting to see that SOA is still not clearly understood and that the “silver bullet” answers are a still being sought after by a few.
The heart of my workshop centered on the theme that you cannot steer clear of business or domain knowledge, even if you try to design your services by wrapping existing software assets.  It just has to align to reality in the business, otherwise you will just create another architecture that has a fractured line to the business needs.

The other interesting theme that arose, unintentionally, was that it may well be easier to sneak in SOA by thinking in services and building some solutions covertly.  Once value is delivered and becomes noticeable, then start spreading out to the next cell … almost virally.

I summarised the main thoughts in the article on DZone at http://architects.dzone.com/articles/top-down-soa-aligning-business.

IQPC SOA Conference in Johannesburg

Posted on by

I will be speaking at the IQPC Service Oriented Architecture conference from June 30, 2008 to July 2, 2008 in Johannesburg.
I will be running a full day workshop title Understanding How an SOA Project is Structured. It’s actually a wee bit more than the title suggests … look at the workshop page and see what I mean.

Why not sign up and join in?  It’s going to be fun 🙂

Launching the Services Support Group

Posted on by

“Hello.  My name is Hope and I am a Service.  Last week I was asked by a View to do something.  I told the View that I can’t do it.  So he asked the Fat Controller.  The Controller sent me the same message and I just took exception.  What kind of service does he think I am?”

“Hello Hope.  We are glad you joined us.  You are not alone.  Look around the room.  We’re all struggling to find our own identity.  Those of us that have been around for a long time are still recovering from being forced to convert DomainObjects to DTOs.  The more recent ones feel like meaningless proxies, and last week we had a guy who thought he was a Service but he was just a HelperClass.”

“It’s as if I am losing touch with reality.  My own DomainObjects don’t even interact with me directly.  Now processes want a piece of me too.  I think I am schizophrenic.  Am I now a process?  A wrapper point for Transactions?  I swear to you, there are days when I even think I am a stored procedure!”

“Ohhhh, noooo!”

“But I know who I am. I am a Service.  I like working with DomainObjects.  They need me.  Somethimes they can’t do everything on their own, so I help out.  I complete their world and it makes me feel like I belong in the right place.  One guy even refactored me from the domain package to a services package.  Can you believe that!  Actually, now that I’ve said it aloud, I am not surprised that I feel more and more disoriented.”

“Disoriented?  Oh boy, we really can’t help you here.  You see we’re recovering from abusive Controllers and Views and when you told us the story in the beginning, we thought we could help you but you’re just a …”

“But that story is true.  Apparently there was this Process on other side of  this MessageBus that needed something and he asked the Fat Controller who got involved with View and then I got sent this message and …”

“WTF?!!  The Process asked the Controller…”

“Yeah!  You won’t understand … it’s after your time.  It’s really a WebServices Controller but I hear that he also feels abused and just wants some REST.  You think there’s a support group for Controllers?”

“Wait.  I remember this other crowd … uhhmmmm … sorry – those weren’t Controllers, those were Presenters working with Models and Views, but I used to be confused as a Delegator and I can …”

“You’re NOT HELPING!!!  I told you I am a Service!  And I am confused!  I want to be part of the domain again!  I feel disoriented!  And I …”

“And I told you that we can’t help you.  The truth is that you are DOA.”

“Dead on Arrival?”

“No! DisOriented Architecture.  You know … they don’t know where to put that, so it becomes a service.”

“But, but … I am a Service … <sniff>”

“YOU WERE NEVER A SERVICE!  YOU’RE ONLY HOPE!!!”