Simplifying SOA

We’ve seen a lot of buzz around the SOA acronym lately. Service Oriented Architectures are one of the hottest topics in IT today, and for a series of reasons. Some of them are legitimate, and others not quite.

More and more vendors strive to gain space into the SOA Infrastructure market. They push you ESBs, they push you Portals, they push you Repositories, Registries, they even repackage their fancy old EAI hubs into a new “SOA” packaging and try to get you into believeing it’s a must-have.

Lie #1 – You need SOA Infrastructure

The truth is, SOA can be realized with NO TOOLS. All you need to do is create services while you are developing (Stateless Session EJBs anyone?) in a manner that they are reusable. Reuse and encapsulation (sounds familiar from object orientation principles eh?) are the major drivers for an SOA to be effective, and that can be accomplished without any tools, and more than that, it CANNOT be accomplished through tools alone. You current language of choice probably also provides all you need for out-of-the-box interoperability with other systems through Web  Services, but that leads us to lie #2.

Lie #2 – SOAP over HTTP is slow

Some vendors claim that multi-protocol support is a must-have, and preach that HTTP/SOAP is slow. Most of those vendors try to push you into using SOAP over JMS, because it’s oh so much faster. Now think with me, you will be trasmitting XML either way won’t you? So how is JMS faster? OH you know what? They don’t want you using the “new” stuff, because they spent so much money in creating a nifty JMS engine back in the EAI days. That’s why HTTP is slow… get it? 🙂

Lie #3 – The main benefit in SOA is reuse, and using our “governance” tools you can have that

Back from lie #1, you cannot achieve reuse with tools. Reuse depends heavily on developer discipline to check all the available and under construction services before creating a new one. It also depends on the people creating services having a “vision” to not overspecialize services or service operations. Will a service Registry help? Well only as much as a text file with a list of all of your services. Ohh and what about repository, how can I keep track of service artifacts such as documentation? Well, use subversion, as you do for code… Quite obvious and simple isn’t it? You can even create a repository using maven that will be browsable and with just enough metadata in project descriptors (pom.xml) for people to find what they need.

Lie #4 – Portals are the past, present and future of web apps

Sincerely put, and you may already have read it in this blog, server-side web UIs are dead. It’s just too cumbersome to create and control a server-side UI while all the action is going on the client side. In the case of browsers, this mean we will be, and already are, writing a lot more JavaScript than in the past, and the creation of client-side frameworks such as dojo, Prototype, jQuery, etc, make it even more clear that JavaScript is the de-facto interactive language for the browser. People want richer and faster UIs, and that means they don’t want to wait for a page post after they do something as simple as creating a record in some database application.

Google has created an specification that is being widely adopted for web 2.0 applications. It has a lot of nifty “social” stuff, but it also has one main component, the Widget Container. Everyone reading this blog must be familiar already with iGoogle, yourminis, pageflakes, or some other sort of start page that contains a lot of widgets. Well in my own vision, that is the portal of the future. A couple small, JavaScript driven applications that are aggregated and served together, client-side. An implementation of this is available TODAY under the Apache Shindig project.

Lie #5 – You need an ESB to orchestrate your services

Well the problem with this is the ORCHESTRATE word. Web Services Orchestration is covered by a number of specifications, but most notably WS-BPEL. BPEL was concieved from the ground up to represent an orchestration of services in order to achieve a final goal, be it producing a joint message of all the services it invokes, or executing a whole business processes.

Don’t be afraid though, ESBs are not a bad thing. They allow you to centrally manage, secure and monitor your services, while mantaining a service inventory that might even allow you to ditch excel and trust the ESB for you service catalog. They are also useful for infra-structure stuff such as fail-over, load balancing and throttling services, or for adding in asynchronisity to a synchronous service. Service “polishing” is also useful, for turning bad looking WSDLs into a nice canonical model that represents its real goal and not the technology it uses.

Despite all that, Martin Fowler and the ThoughtWorks team seems to think that squid is the only SOA infrastructure you’ll ever need, as can be seen on this presentation. Watch it, and let’s discuss that.

Deployment or Distractment?

I was discussing with a fellow java-head the other day about the odds of Java EE life. Us javaneers take quite some pride on what we do, on the frameworks we have, on the solidness as scalability of the Java EE platform, so on and so forth, but still we hate do admit one single thing: Deployment in Java sucks.

If you have ever used a Java EE server such as BEA Weblogic or JBoss you know the pain. Change something in your app, compile, package it up – a quick cycle that takes no longer than 30 seconds running ant – and then wait up to 5 minutes for the thing to be deployed!

Although some tools do help, like Eclipse WTP or server-specific ant tasks, to automatically deploy your app, you still can’t help that it takes forever to get it deployed.

I am quite fond of the RIA interface + EJB 3.0 Facades exposed as Web Services + JPA persistence triad, but having to redeploy my webapp whenever I change a single line in a JavaScript file is overkill.

Even worse, having to wait for deployment cycles knocks you out of “the zone” and leads you to distraction. Waiting for a build/deploy cycle is the perfect time for you to reach for your RSS reader or favorite social networking website and spending something from 15 minutes to hours distracted.

What can we do to get our productivity back to its heels and stay focused? Well there a few options you could try:

  1. Pair Programming;
  2. Copy changes to the deployed application directory straight up;
  3. Use a scripting language and maybe get groovier.

I’ve witnessed the power of keeping people in focus with pair programming. Two people working at one screen, with the same codebase, and frequently changing who’s steering the wheel are commited to one another in making things happen. Even with the deployment times, it’s a good time for some discussion around the code, to call a customer and check if you’re sailing to the right direction, or start writing new unit tests.

Going with the forceps approach and sticking stuff into the deployed app path could work for a few scenarios, but if you change something in a Java EE component, you’re out of luck. Without redeployment your Servlets, Seesion and Message-driven beans won’t get reloaded because they’re already classloaded. Your JSP pages will be already compiled and won’t get loaded again.

Or you could use something with a scripting language, like groovy. I happen to have liked Grails and how it still uses the Java infrastructure under the hood while giving you the same agility you’d get from using CakePHP or Ruby on Rails. They even have a service facility. Now if only those services could be made into Session EJBs… oh well guess you can’t have everything all the time. Still, Grails allow you to change anything in your app while it’s running and see changes instantly, as can be seen on this screencast.

I by no means endorse the use of Grails, or think it’s the definitive solution to all problems, but it surely has a point. I will look into it for my next personal project, and the odds are I’m gonna be hooked. If you too got interested on it, you may want to read this nice book from InfoQ.

Service Versioning

It has always seemed to me that the weakest link in the SOA chain is how to version services and ensure that you don’t break clients/consumers when updating the WSDL interface. Up to now, I have been keeping the old service up, and creating a new copy of the service, running on the new interface (I know, I know, this break the DRY – don’t repeat yourself -principle).

So I came across an article from Adam Trenaman at IONA technologies, the company behind Apache ServiceMix, that suggests a methodology for evolving services using the same WSDL, schemas, and versioning them according to XSD best practices.

Check out his article and the paper linked there, and help me get the following: Most of us use generated WSDL’s, not hand-crafted ones. So how would that be applied to real-life services, and how can you use WSDL to do it with a language that does not support WSDL-to-service generation?

Of Monkeys And Suits

Sara Chipps has published an article regarding the differences between passionate programmers (Natural Programmers or Code Monkeys) and as she calls it, carrer programmers or “Geeks in Suits” although I think the term Geek isn’t appropriate.

I always felt as if I was some sort of freak for not being able to do mundane things such as keeping my desk clean, do some degree of paperwork or get to work on time, but it seems at least her, and I believe a lot more people involved in creative activities and innovation have the same problems.

So, without further due, I invite you to read her article and share your thoughts.


I have been fiddling around with the idea of skipping the server side UI model completely for buildling web apps for a year. With the advance and acceptance of client-side toolkits such as Dojo, Prototype +, Yahoo Widgets, extJS, jQuery etc, client-side rich widgets are becoming increasingly popular and growing in number.

JavaScript is also becoming easier to use due to standards like DOM and ECMAScript and improvements in the development model, such as Dojo’s package and dependency system, class definition facilities, prototype’s aliases and development model, just to name a few.

The original MVC pattern created by the Small Talk community was made for GUI clients, and was re-vamped – in a not so good way if you dare – as MVC Model 2 for web apps. The problem with MVC Model 2 is that it’s not MVC at all! Ok so MVC is about having your view render your model and update itself as the model changes, and have its interactions handled by the controller. In this sense I do have to agreee that MVC Model 2 adopts this concepts.

What people don’t get is that models are NOT about your application data. A model isn’t database data, although it may contain some of it. A model is simply holding the data the view needs to display. Take Swing as an example. Every single widget has a related model which holds the data it’s supposed to present.

Also controllers are NOT about your business logic. They are supposed to be the bridge between the user’s actions, and the execution of business logic, but not orchestrating multiple uncoordinated pieces of business logic spread around various classes. If your business logic is spread out like that, create Façades for it, don’t try to push it all into the UI controller. Did you notice I said UI? Well that’s what MVC is meant for, not application-wide architecture.

One of the reasons MVC Model 2 was created is that there are no means of implementing the Observer pattern, crucial for View updating on Model changes over the HTTP protocol. By that time, JavaScript was very little used, as before the DOM and ECMAScript standards it was heavily browser dependent and brittle to use, so HTML and forms were all we used.

Enter JavaScript MVC. You can implement, with very little effort, the original MVC pattern using widgets from your JS toolkit of choice, my current favorite is Dojo. I’ll post some code samples from an application I’ve applied this concepts to later.

So you’d say “ok, but if MVC is for the UI, what should I do with my business logic?” The answer, my friend, ain’t blowin’ in the wind, it’s SOA. Your company may have already invested, or chances are it’s looking into investing on a Service Oriented Architecture. Now if you already have services available, why not use them from inside your RIAs?

Why not go full-on client-side on your UI and use your services for business logic? This way you skip all the risks of building a business logic heavy UI controller, and also enable reuse throughout applications of that very same logic using services.

Anyhow, I made you read all this babble because I finally did find someone who shares my vision. The CTO from AppCelerator, Nolan Wright will be publishing this article on the SOA World magazine next month. Read it and leave your comments.

Parking Spaces and Human Behavior

Watching the effects of an individual’s actions in the spaces he shares with others is an amusing thing. Now you wouldn’t expect your actions changed the behavior of 20 people working on the same building as you do, would you? Well neither did I.

The parking lot in my workplace’s building is comprised of a set of spaces organized in 2 cars per column, but there aren’t enough cars to fill all spaces, so only 1 space per column is usually used, except in the days that the garage is crowded. People used to park in the back space, leaving the front row free for others to drive around the place and occasionally park behind them if necessary.

So this one person, new to the parking lot, comes in and parks his car, in a column of his own, but parking in the front row. The first day, he’s the only one to do that. Second day, 3 cars are already parked into the front row. In a month, ALL cars in the garage are parked into the front row!

Now when asked why did he park into the front row, he said he’s trying to avoid that someone parks behind his car, because it’s too big for him to be able to move to the adjacent column while going out of the garage. Also because a workmate of his used to park his car in front of him, but always left work way later than he did.

I’m still trying to understand what happened. Did his actions cause everyone to be afraid of people parking behind them? Were they in fear they were “loosing” some sort of advantage by not doing it? I guess us humans are defensive creatures by nature, and also need to be smarter than our peers for some odd reason. I’d be glad to hear your thoughts on this, or other stories of individual actions that changed a group behavior.

Hello world

Hello all, I am Alex M. Reis, currently the Enterprise Architect for Brasil & Movimento S.A. The company’s known through its trademark Sundown® and crafts Bikes and Motorcycles for the brazilian market.

My passion is writing software, but not only that. I have a passion for writing good software, that’s easy to mantain and understand. I have a passion for patterns, standards and most of all, I have a passion for accomplishing big things doing small ones.

I’m a passionate advocate of Agile methodologies, XP to be more exact, and also a proud Open Source enthusiast. My intrest also lies in Service Oriented Architectures (well software architecture in general), Web Services and Rich Internet Applications.

I’m a no-thrills no half-words person so please bear with me if the opinions I state in this blog are too bold for some of you, but I’m just like that, black and white. I don’t wash things out with nice words such as “may, should, probably” so beware. There will be x-rated content here for non-purists, as I am a die-hard purist.

I will also add my thought and findings about life in general, as it never stops to amuse me, usually one thing or two about community behavior and whatnot. I am also a gaming enthusiast, and spend most of my free time playing games or making music, which is my other hobby.