Idiots guide to Service Orientated Architecture (SOA)
March 10, 2007 6 Comments
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.
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.
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.
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?
Java and those pesky Google APIs
January 23, 2007 6 Comments
Recently one or two people disagreed with what I had to say about the impact that the Google, Amazon (and other) API’s will have on Java. Considering the ratio of positive to negative comments (about 3 for and 30 violently against), I obviously need to express myself in a clearer way. The link to the original post is at the end of this article, read on before you consider flaming me.
So , deep breath , here goes.
Compare the the way you develop now , with the way you built software 10 years ago. Do you remember having to manage your own memory? Or the pain of trying to deploy your software on different machines without a JVM? Or the hassle of trying to write distributed software using Corba? Or using a text editor instead of the fine IDE’s (Eclipse, Netbeans or JDeveloper – take your choice) that we have today? Would you consider building your software without a tool like Ant or Maven?
(Shudder). Things have moved on ,and I am very glad they have. Likewise, the way we develop 10 years into the future will be very different. I don’t know what the future will look like, but here’s a simple guess.
The biggest trend today is the move from software running on your computer , to software being delivered over the web. I’m not talking about the buzzwords being thrown about regarding ‘Service Orientated Architecture’ or ‘Enterprise Service Bus’. I’m talking about simple API’s that are available for use over the web today. Like the API’s and products from Google – including their Documents and Spreadsheets, and their Authentication service.
As a good Agile Developer you’d probably agree with these quotes. But what if the most simple way of doing things was not to develop in Java at all? Most people don’t build their own operating system – they use Linux, Windows or OS X instead. Most people don’t write their own Java Server – they use Tomcat, JBoss or your server of choice. The pattern is the same. A small, dedicated core of developers builds the product, and the rest of us say ‘thank you very much’ and use it to get things done.
This range of ‘off the shelf’ solutions is increasing all the time , even before the online services arrived on the scene. As a Java developer , you’ve said ‘thank you’ , downloaded the latest version and integrated it into your solution. The time you save means you deliver other cool features instead. Java is very good at this ‘download and integrate’ process – not only is it a key benefit of Object Orientated Software, but Java has the widest range of solutions available (if you don’t believe me , just check out Sourceforge).
Java can also let us build our solutions (either partly or fully) around the online API’s. Java has great networking and XML handling ability already. In time this will become as normal as the idea of using a JVM. Great – we use these API’s pretty much like we do libraries today, and we can continue developing pretty much as before, right?
Wrong.
Remember, what is the most simple way of doing things? What if the most simple way of doing things was not to use Java but to use a more simple language (like Ruby or PHP) instead? Until now there were a couple of advantages that Java had over these ‘simple’ (and that’s a compliment) languages. When using online API’s these advantages disappear, or worse, become a liability.
So do we face a form of developer apartheid, where a ‘hard core’ of Java Experts develop web API’s that the rest of us use via scripts? Let me know what you think. Like the original blogpost said, it may not be the end of Java, but perhaps the end of Java as we know it.
Filed under architecture, Articles, blog, comment, design, EAI, eclipse, enterprise web 2.0, EnterpriseWeb2.0, ESB, grails, Information Technology, IT, j2ee, Java Enterprise Edition, jruby, jvm, ruby