Bruno Fernandez-Ruiz

SOA means a lot of different things to different people. Now, if I go by the W3C’s definition, it’s about processes that assemble services and an organisation that owns the processes and the services.

However, to me, SOA is simply distributed computing over web services. I have been building distributed component applications since 2000 that were exposed as business processes. We did not have web services, but the facade was a process interface, and the execution was managed by a simple workflow engine. BPEL and SOAP were not yet mainstraim, still our application was based on a SOA.

So what makes a SOA different from good practice in doing distributed components (the service facade, service locator and state machine have been published design patterns for a while now). I think the only difference is the message encoding protocol (SOAP).

So, what’s with SOA scaling?

Many organisations are adopting SOA as almost the holly grail that would enable them to achieve reuse. For a SOA to succeed, one needs to think about processes and data.

Organisations that start now modeling on the process side, and construct processes assembling services exposing existing legacy systems, will hit a big performance wall. You need to think about data: ensuring a given entity ownership sits in one or few known parties. Otherwise, each service part of a larger process will access records which are not necessary for the ‘whole’. A little performance overhead summed up over a bunch of services that constitute a process results in possibly non acceptable overall service performance.

Those organisations that decide to focus on the data side encounter the reversed problem - you can’t work in your information architecture if you don’t know who is using you. So if you just build services and processes that expose existing data, you are doing it in a best-effort basis. It may, or may not, fit the interface and data needs of the service consumers. If they don’t, they will need to go against your datasources directly, and this will defeat the whole reason for an SOA.

I believe the following development methodology for services could work:

1. Model your processes, analyse the required data and use those requirements to create a data model.
2. Create a true component architecture, with proper entity relationships and ownership to encapsulate and abstract your data model.
3. Create services and assemble services according to your process design (which you may/should revisit by now).
4. Iterate the previous steps, starting from the core business processes, and adding processes to the SOA.

Interesting enough, this is how agile web 2.0 development is happening! Start off with HTML screens, then model your DB, then construct your model, controller and revisit the views. Which brings me back to the web 2.0 == SOA. We’ll eventually get there …

I have spent some time over Christmas period playing here and there with Ruby on Rails and getting an overdose of AJAX. I really wanted to see whether all the hype and marketing from 37things.com and associates makes any sense.

I have two objectives in mind:

1. Should I throw away J2EE for Rails?
2. Should I throw away PHP for Rails?

My impression of Rails has been extremely good so far. However, I am really more pleased with Ruby than I am with Rails itself. Rails is interesting, don’t get me wrong, but far from being revolutionary. All concepts and patterns in Rails have existed for a while in the Java and J2EE world for a while now. If so, why is Rails so cool and sexy? I’ll give you a few reasons I found for myself:

• Ruby is a very expressive language for those like us coming from strongly typed language background.
• Rails makes agile development easy. It is extremely easy to come up with a concept in the morning, and have a prototype in the afternoon to show to your client. This is because development and execution architectures are tightly coupled.
• Rails principle of convention over configuration works great for 99% of the cases. No need to know how to define or configure something - it just works as long as you follow the principles.
• Rails provides a really easy-to-use and lightweight structured MVC architecture for those PHP addicts hacking web site after web site.

Would I throw J2EE away now that I encountered Rails? No. J2EE is a distributed component on steroids - so if you don’t need distributed components, you don’t need J2EE. But if you rely on JMS, JCA, JTA and distributed components, then Rails is not your medicine. Rails is a pure web application framework, with some quick O/R mapping facilities to ease the pain of DB access — it’s great for those web applications only backed by one database custom developed for the particular application. Rails is more of a pain relief for PHP folks than for Java programmers.

If you have been doing pure web frontends in Java using JSP and JDBC, well, sorry, I think you should go back and examine Python (Django), Ruby (Rails) and PHP (Yellow Duck, BlueShoes) and stop wasting your time.

Then there is Trails, a Java replica of Rails, using the “best-of-breed” Tapestry-Spring-Hibernate (yeah, fits my resume). However, I feel there is no much meaning in Trails nor TRAX. If I have complex problems (integration, distribution, transaction management, and messaging), I’ll use Spring or directly the J2EE APIs, and will not rely on a generation framework and convention. I will want configuration, and full control.

Finally, there is also PHP On TRAX, a Rails version for PHP. It might have a niche market, for those loyal to PHP. But given Ruby is sooo expressive, why would anybody program in PHP?

Bottom line, Rails and J2EE cover different needs and developer populations. There will surely always be an overlap - and over time they will both mutate to copy features from each other. But it is more likely that we see Ruby 2.0 running on the JVM, than iBatis or Hibernate on Rails!