Idiots guide to Service Orientated Architecture (SOA)

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?

related posts

Enterprise Java Presentation , Stephens Hotel , Dublin

You may remember we did the Enterprise Java presentation at DCU back in October for the wireless skillnet in Ireland. We’re doing a follow up presentation, this time in Central Dublin, on the 22nd January. The audience is mainly business people with some sort of interest or connection with technology.
Irish Dev has more details.

The topics covered include:

  • What Problem are we trying to solve?
  • Enterprise Java Architecture Overview.
  • Benefits to the Enterprise.
  • Alternatives (.Net , PHP , Oracle , Lightweight Java Frameworks , scripting)
  • Vendors (IBM, Oracle, Sun , Bea , JBoss and SAP)
  • Market Trends – Resource availability (can we get the people to do this?)
  • Enterprise Web 2.0 and Service Orientated Aritecture (SOA).
  • Integrating with other Systems ( Legacy Systems, Oracle etc)
  • Enterprise Java Beans 3 (EJB3)
  • Middleware (MOM, Rule Engines, Workflow)
  • Security – Application and Server Level including Java Access & Authorization Service (JAAS).
  • Frameworks (Struts , JSF, ADF, DWR, Spring, Hibernate)
  • .Net interoperability
  • What’s next for Enterprise Java?

Must not Copy and Paste …

I must not copy and paste program

I must not copy and paste program

I must not copy and paste program

….

You get the drift. Currently doing a Struts – DWR – JBoss Rules Web application, and there is way too much copy and paste programming going on in there. It’s a web page that needs to pass information to a JBoss Server – how difficult can that be? Maybe it was interesting the first time, but 7 years on the buzz is no longer there.
Grails Logo

I was tempted by a non-Java solution (Ruby on Rails , or JRuby) ,but a similar approach within the Java mindset) is Grails (Groovy on Rails). It gives you all the enterprise Java frameworks (Spring , Ageci, Hibernate) , but with a rapid turnaround.

Oh dear … too many web frameworks …. head hurts … only time to learn one … more head pain … must make mercenary decision about which will be the likely market leader.

Watch this space. 

(For the record the problem isn’t DWR which is excellent, but more the version of Struts / JSP that is being used. )