Thoughts of an IT professional

Inca o chestie care dispare…

Recently I started perusing literature concerning SOA  - Service Oriented Architecture, the latest buzzword in the IT industry. As any other new concept it is pretty vague and in the process of getting defined. I find it very interesting and I read on it heavily.
I cannot consider myself an expert in the domain mainly because the concept is pretty new and it applies to enterprise-wide concerns; in order to get hands-on experience you need to work close to the board-room level. However, I came across a few misconceptions that I think I can straigthen out. One of them is that SOA is the new CORBA, a particular type of CORBA that runs on XML, some CORBA on web-services, in order to connect to .NET systems.
Well, this is wrong. SOA is not a new CORBA and these would be a few reasons:
1) SOA is about empowering business users. SOA is as business-like as IT gets. CORBA is/was for techies, SOA is for business analysts, policy-makers and domain experts.
2) Some technological advances have occured since CORBA was released, one of them is the ESB. CORBA was essentially a point-to-point technology while ESB is all about diffussing information to different partners. CORBA was never taken above simple relationships.
3) SOA is partly about managing complex relationships between different actors in an enterprise, CORBA is all about simple relationships (point-to-point relationships).
4) SOA is much more in tune with the environment outside the server farm, CORBA is in the server farm.
5) SOA is concerned with business evolution, adaptability to a changing environment, efficient resource allocation, CORBA is concerned with implementing a pipe over which messages are streamed.

CORBA is probably the first communication protocol that noticed the  variety of systems that were trying to communicate with each other and presented a solution to this problem. SOA is concerned at its foundation with this problem, but rather than solving it it assumes it is solved and moves on to determine what should happen once the systems do start communicating one with another.

JBoss is a very unusual open source project. It is an open source project that behaves more and more like a corporation. It doesn’t shy away from money, in fact it sold itself to Red Hat for a lot of money, the price tag being somewhere in the vicinity of 400 million dollars.
What makes it look more like a corporation than a traditional open source project is the lack of organic growth. Once it secured the initial VC funding JBoss has gone on a shopping spree. It has purchased Hibernate, Drools, Arjuna and today Rosseta ESB from Aviva. The vertical integration of its stack is also another facet of the corporate mindset that directs JBoss. JBoss, and Red Hat along the way, seems concerned with the creation of an open-source stack that will supposedly provide their customers with a one-time stop for their enterprise computing needs, they only fall short of a database.
Lack of organic growth, vertical integration, VC funding, etc…, well these are concepts you come across reading Wall Street Journal, not your typical open source online-forum/wiki. JBoss is a corporation (actually, it has been one for a long time) and is very much acting like one, much to the dismay of a large number of developers. This corporate behavior runs counter to what most people think about when thinking about open-source and led to some virulent “Boycott JBoss” campaings.
However, one thing that I find strange the way JBoss Inc. chooses to grow its business is the fact that they are growing a huge stack and charging for training and services (to a certain degree). JBoss seems to be trying to make money by managing the behemoth that you downloaded free of charge, installed and ran into problems with.
This runs counter to the current development mindset where you develop small pieces of software agnostic of the operational environment, you create contracts for plugging them into the operational environment and then adapt the software to the contracts you have created. The world is moving away from large elephants to small and highly adaptive software. JBoss is moving towards the large elephant. It is probably moving from mom and pop IT shops to Fortune 500 companies. Talk about a corporate mindset…

I was in an interview with another BU when the question popped up: "What are the differences between DOM and SAX XML parsers and when would you use one or the other?". I started with a brief description of DOM (tree-like representation of an XML document that loads an entire document upfront) and SAX (slim, event-based XML parser). The answer that I gave was that I would choose DOM for XML documents that are complex and prone to change while I would favor SAX for simple documents which are not prone to change (memory was not an issue). The reason that I gave this answer was that trying to keep track of where you are in a complex document while SAX events are firing is pretty complicated and that once you created a SAX event handler that maps onto a document format is pretty hard to change it in order to map it onto a new format. The team interviewing me agreed and passed to another question.
Now that I’m thinking about it, the answer was wrong. The right answer would have been that I would choose an object-to-XML mapper that would translate a XML document into objects and viceversa and that I would delegate all processing and resource management to the OX mapper. The days when we would have to deal with DOM or SAX are over for the most of us, we should be working with what are comfortable with, that is with objects and not DOM Nodes or SAX events.

Later edit: SAX is a parser really close to the metal begging to have some extension layered on top of it in order to make it more developer-friendly. The fact that no such extension exists or is not popular (I, for one, do not know of any) leads me to believe that SAX is not so widely used. Probably the reasons for which it was conceived (small memory footprint being the most important one) are not important anymore or the XML documents that are usually manipulated do not require a lot of resources.
Even later edit: It looks like the size of the XML documents and the number of formats grow pretty rapidly as SOA matures. A SAX-based OX mapper would not be a bad idea after all…

S-a dus pe conducta.

I’ve been away from my blog for a while. I am in the process of getting a SCEA certification and this kept me pretty busy.
Now I’m back, ready for writing more about enteprise computing.

This is obviously not the first time someone points out the deficiencies in the EJB spec but I just could not help it.

I have started my SCEA certification process and for the first exam I had to revisit the EJB architecture. I read EJB 2’s spec and at the end I was left in wonder. I could not believe that a corporation like SUN came out with such a spec.

The first (huge) surprise was the fact that there are interfaces that go against their contracts is a first (as far as I know) for SUN. For example, the MessageDrivenContext interface extends EJBContext and as a result it provides the MDB with access to its home. Except that an MDB has no access to a home since it is not referenced thru a home. Accessing the home thru a MessageDrivenContext would throw a system exception. I was in shock when I read this. You just have to wonder, what other methods are invalid in what interfaces? An API should provide a bullet-proof contract with no room for ‘buts’ or ‘maybes’. Well, this time SUN took a short-cut.

Another thing that surprised me was the breadth of the spec. The spec tries to address quite a few issues: transactions, security, concurrency, timer services, distributed computing, persistence and resource management. Addressing all these issues is obviously not trivial, and in this case the end-result in this case is a hodge-podge of an architecture. SUN made quite a few assumptions about the applications that will be built using EJBs and hard-wired these assumptions into the spec.
For example, concurrency is addressed in the simplest manner: all calls to a session bean are serialized. You cannot isolate calls based on state that is shared between calls as you would want in order to create a better-performing architecture.
Resource management assumes that 10 years after the first JRE garbage collection is still a big problem in enterprise computing.
In the persistence area: requiring that some tasks are carried out by pooled beans and others by pooled or active beans seems more like a hack than serious design, I don’t understand why persistence issues should be inter-twined with lifecycle management.

One thing that attracts developers to the so-called light frameworks is the fact that these frameworks do not make any assumptions about the applications getting built with them. Instead, they provide a way to assemble applications and bind behavior to various parts of an applications. They let you integrate outside components more easily into your application.

I think this is a more sensible approach to enterprise computing than trying to create this solution that tries to solve all the issues important to enterprise computing.

Finally, another failure of the EJB model is the collaboration between different technology providers. The EJB model was supposed to encourage application assembly: you would get some beans from a provider, put them together with some beans from another provider and create an application. I do not know of a successful application which got assembled this way.
However, the level of integration the lightweight frameworks have with outside technologies (such as the Acegi security framework) puts them in huge contrast with the EJB architecture. It looks like the IoC containers are much better applications assemblers than an EJB container.

The EJB spec leaves behind the image of an elephant mired in the moors of enterprise computing, trying to provide a solution for every conceivable problem, ending up with no clear answer to anything.
Looking at the picture that the EJB spec presents today it is not clear how another version – even the annotation-enhanced, transparent, lightweight version 3 – will fix the systemic problems that this bloated technology poses. I am skeptical that the on-going effort for refining EJBs will ever bear the fruit it was supposed to.