SOA for Idiots

by Paul Browne

Lost in the hype around Service Orientated Architecture (SOA) is the fact that the idea is really really simple. It's all based on the idea that most applications (and that includes websites) are built either to be used by people , or used by computers. The pictures below (a free preview from the Enterprise Java Briefing) show what I mean.


In a 'normal' application, such as a online banking website, we need to remember what the user did last (are they logged in, what account are they looking at, are they in the middle of making a payment). If we didn't , the user would get annoyed about having to repeat themselves every step of the way. It would also make for pretty complicated screens, to allow the user to enter all the information in one go. Instead , we allow the user to enter information in several steps, and remember where there are each time.


Soa Client


In an application designed to be used by computers, we don't have to worry about this. We can force the computer to give us all the information required all in one go - username , password, bank account to take money from , bank account to give money to, date to execute transaction. For a computer , this is actually easier ; we make one call to our banking service and we are told it has succeeded or failed. It's also easier for us to build our service:



  • Each service (transfer money, book flight , execute share trade) only does one thing.

  • Because each service 'forgets' after each call, we don't need to worry about trying to remember what we were doing before.

  • Because we have no memory, services are very scalable; we can make several copies of the same service and put them in a pool. Any client can talk to any service - no waiting for a particular server to become available.


Soa Service


So that's Service Orientated Architecture (SOA) : programs that do one thing (a bit like a function call to a method) exposed that other computers can call. So what's the big deal? Like all good ideas , a simple concept goes a long way.


Take a look at the picture below. It's like a Visio diagram, but in fact it's drawn by the Eclipse Based JBoss IDE. It shows a workflow for an online commerce store - pretty easy to understand. This example uses JBoss Java Business Process Managment (jBPM), but companies such Tibco, Cape clear and Oracle BPEL have similar products.


soa workflow


Here's the clever bit; each of these steps is executed by one of the services that we talked about earlier. This means that if the business process changes (and it will), then all you have to do is re-arrange the diagram ; little or no coding changes should be required.


This abilility to mix , match, combine and remix services leads us to a lot of other good things (and we're only scratching the surface here).



  • Because our services don't have to run on the same machine, we can use SOA to create a distributed application. This is the concept behind the BPEL (Business PRocess Engineering Language)

  • Services tie well to Ajax and Web 2: Our Ajax web page or portlet can call as many services as it requires to get the job done (it's one of the reasons Tibcom is sponsoring the open source DWR project)

  • We can call many services at once. If these this service calls are xml based ,or we send these calls as a message then we can filter, duplicate, pass and other distribute these calls as we set. These are the ideas behind Apache Synapse, Apache Servicemix and the Enterprise Service bus (ESB) in general.


What do you think? Is SOA useful , or over hyped?





20 Comments

Uday Joshi
2007-03-22 10:55:26
The link "Oracle BPEL" incorrectly(?) points to http://firstpartners.net/blog/technology/java/2006/10/30/enterprise-java-presentation-at-dcu/
Uday Joshi
2007-03-22 10:58:58
Also BPEL is not Business PRocess Engineering Language. It should be Business Process Execution Language.
Trevor
2007-03-22 11:12:13
Why do you keep adding a space before your commas and semicolons?
Paul Browne
2007-03-23 00:48:30
Uday: Link corrected , but I'll stick with the current definition of BPEL.


Trevor: Bad habit.

krishna
2007-03-23 01:00:52
lets see..first time i am working on SOA implementation.
Shudh
2007-03-23 03:46:09
Netbeans cleverly omitted?!
Paul Browne
2007-03-23 04:09:07
Shudh,


I've nothing against Netbeans (and respect anybody who uses it :-) , but I happen to prefer Eclipse.


JBoss IDE also comes as a plugin for Netbeans - I've never used it, so if you do check it out, let me know what it is like.


Paul

coredump
2007-03-23 04:47:49
SOA is not just some fancy diagram, you'd better explain some behide the scean. or you think all the readers are idiots?
BTW, I'm wondering does Any script lang. has SOA ?
Hate to loose my time
2007-03-23 06:23:12
BPEL (Business Process Engineering Language)???


What do you think? Are you useful, or over hyped?


http://en.wikipedia.org/w/index.php?title=BPEL&redirect=no

Mike
2007-03-23 07:05:23
"Uday: Link corrected , but I'll stick with the current definition of BPEL."


Lol, what??? I'm sorry, but I wasn't aware the definition of BPEL change from Execution to Engineering? It must have escaped Oasis as well because I'm pretty sure the 2.0 spec is about as current as it gets. BPEL 2.0 spec

Paul Browne
2007-03-23 08:58:34
@Mike - fair enough comment.
@'Hate to *loose* my time' - I'm hoping that you're being ironic by pointing out mistakes, but not spelling correctly yourself :-)
@coredump - ???! I presume you mean 'scenes' not 'scean'. Feel free to provide any detail that's missing.
Brennan
2007-03-23 21:44:07
Right now SOA is more of a buzzword than anything else, but I think it has potential beyond that. I tend to think of the real benefit of SOA as "encapsulation" at a higher level than objects. By forcing yourself to think of your architecture as a community of smaller, more discrete, communicating services, you are in fact increasing the reusability of the software you develop.
dwieb
2007-03-24 12:26:40
Thanks for that thought Brennan - I would agree.
Paul Browne
2007-03-26 03:47:44
@Brennan - it's a pity SOA is a buzzword as it has some useful stuff. Keeping it simple (a bunch of services that do one thing) is the key.
dennis wilson
2007-03-26 14:10:06
Am I missing something? How is this so different than the piping that can go on in unix/linux between programs, scripts, etc. It seems like the idea of linking things via an agreed standard has been done before.
Paul Browne
2007-03-27 01:52:19
@Dennis - you are exactly right. It's a simple idea that's been done before.


The unix analogy is good - see this blogpost - Is web2 one big unix box?


2007-06-20 05:26:34
Why it's for Idiots?
Vinod
2007-06-20 05:26:45
Why it's for Idiots?
Vinod
2007-06-20 05:26:46
Why it's for Idiots?
Dominic
2007-07-19 10:31:04
Thank you for the simple description. Very Good for a quick look.