Thoughts of an IT professional

I have moved my blog to my site.

I have started reading on REST-type architectures (I recommend this intro in particular). It is an interesting exercise to compare them to SOAP, one of the main differences being the amount of information a client has to know about the remote system it is interacting with. With SOAP the client must know the whole API stack in order to be able to carry out a series of actions while a REST client gets passed the resource for its next actions as it progresses. To go back to the example in the above intro: as the REST client searches the catalog it is given URIs which can be used for carrying out certain actions (viewing an article, adding it to cart, etc…). A REST client just needs to agree on the semantics of the data (how do you specify the URI for viewing an article or adding it to the shopping cart) with the server and then it just needs to call those URIs when it needs a particular action taken.
In contrast, a SOAP client needs to know the whole server API before engaging in a conversation with the server. It needs to know what method to call and what types to use in order to retrieve a product, get product information, add it to shopping cart, etc… It needs all these before else it doesn’t know what to do.
The REST architecture is very similar to the world wide web: a human being browses a page, sees some links, if they are interesting it follows them, etc… The SOAP architecture is, to a certain extent, similar to a human being using Microsoft Office: if you do not know the bazillion buttons and dropdowns MS Office comes with you cannot use it. In order to use MS Office you need to know its user guide, similar to having to know the API of a SOAP server in order to use it.
I like REST, conceptually for now, because it gives me the same feeling as when I was studying distributed computing in university: you have a node, you specify its relationships with other nodes, you set it up it in the network and before you know a whole web of relations comes alive. In REST you have to think in local terms (to what other nodes am I connected now that I am on this node and what can I do now?), while with SOAP you have to think in global terms (I know the whole application, I have this data, what do I do with it now?).
That being said, I am wondering how will REST architecture scale when the number of connections between nodes will increase. Let’s say that I have the product node and for now I have to other nodes (or URIs in REST-speak) attached to it: ordering the product and viewing it. What if I need to add 15 more actions to this node, will that affect the size of the message I am sending the client and effectively consume a lot of resources? What if these actions are not that different one from another, how will the clients be able to make a decision about where to proceed next?
Another point I’d like to make is the fact that when programming to a REST-architecture you are intimately tied to it. You cannot download the API, put a layer of abstraction on top of it and plug it into your application as you would do in a SOAP scenario. With REST you get a node, you parse it for its relationships to the rest of the application (and you have to make this all the time because the REST server may decide to change the URIs of those relationships) and then you are ready to do something. In SOAP the relationships are expressed in the API, in REST they are discovered every time you process a remote node. You are dependent on the remote server a lot more than in a SOAP scenario. Interacting with REST-servers may result in tight-coupled systems*.
One last thing (related to the above) would be the fact the REST is so different from SOAP to the point that a customer wishing to communicate with a REST-based system may have to alter its application entirely (not only the layer it uses for communicating with the rest of the world). REST doesn’t let people get their feet wet, you are either in it or totally outside of it. This could hamper mass adoption.
I am waiting to see how this unfolds. Given the fact that most corporations grok SOAP I would be surprised if this technology will make a beach-head in the enterprise space. But you never know… I, for one, wouldn’t mind getting that feeling I got in university again…

Later edit: A REST application is probably best used for distributed computing where various nodes talk to one another. In this scenario the concept of a REST client and a REST server doesn’t exist, basically the REST client is emerged in the network the REST server(s) are running. You cannot have an external (at least I don’t think so) REST client, the REST client is similar to a spider that goes from node to node carrying out certain actions at each node and finishes by becoming part of the network. I think it is for this reason that trying to connect an external system to a REST-network fails, because the external system is to intimately tied to the REST network that it finishes by becoming part of it.
Comments welcome!!

* I am not sure about this, please drop a comment if you want to talk about it.

You wouldn’t have guessed that this post is about EJBs, right? I wrote a rather critical post about EJBs, but I’d like to take a second look at them.
I was looking at EJBs from a historical point of view and I realized that the EJBs are probably the first managed environment. Their intention was noble: to free the developer of any operational concerns and focus exclusively on the business logic. The developer was not supposed to worry about securing an application, about propagating credentials in a cluster, the environment was supposed to do this. The developer was not supposed to code for concurrency, the environment was going to do this. The developer was not supposed to deal with resource management, the environment would have done this for it. The developer was not supposed to code TX behaviour, but rather declare it and let the environment enforce it and propagate it in a cluster. The developer was not supposed to connect to a DB manually, but rather delegate this to the environment. The aim was really high, the functionality that this managed environment was supposed to implement was not trivial. On top of this, the spec defined this managed environment to be a distributed managed environment. Very high goals…
The result was disappointing: in order to embed your component in this managed environment you had to code to a series of interfaces and design policies which had to become second nature to a developer, in other words the environment was very intrusive. Embedding your component in the environment also came with a very large overhead: for some beans no less than 6-7 files were required in order to be able to turn an ordinary class into an EJB. Working with entity beans was particularly hard on anyone who had to use collections in the early days of EJBs: I remember scanning the log of the application and waiting forever for the app server to load 20 entities. This managed environment also came with some perverse side effects, the most known of which was the vendor lock-in: transporting an application from one app server to another was an undertaking that very few organizations had the resources to carry out.

Now, if we look at it from a “historical” point of view, the above doesn’t seem so bad for a first try. One cool thing about EJBs that resonates well with me is the fact that EJBs promoted the use of interfaces. One very good use of this would have been the abstraction of a business process behind interfaces, unfortunately this didn’t take off, most of the implementations were going the other way around, from concrete class to interface, XDoclet-style.
The “mistakes” that this operational environment made would be that it was advertised as “enterprise” and that it was too inclusive. Trying to address every issue important in enterprise computing on your first shot is prone to failure. The fact that this was done in a “democratic” fashion with each industry vendor pitching in his customers’ needs didn’t make defining the spec easier.

Some people look at EJBs as an abject failure. I look at it as the first step on the road to something new, a first step loaded with mistakes as all first steps are. Currently everything is running in a container, in a managed environment if you wish, which you get to define and tinker with if you wish. The lessons learned by working with EJBs provided valuable when the current successful containers were designed. It’s an evolution if anything else.

Anyone remembers this? Before .Net, before ActiveX, before COM there was OLE, the way that various software products could communicate one with another. The idea was that a software product would delegate various tasks to another product which was better equiped for it.
I remembered it a few months ago when I went to a head-hunting agency and I watched the secretary punching in my information. She was jumping from Word to Excel, back to Word, back to a different Excel file, etc… Very, very ineffiecient. I could not help having the feeling that she was actually taking on the role of a software program, that all the repetitive jumping from one file to another could have been analyzed as a business process (it is a business process after all), abstracted and implemented.
Back in the days when desktop computing ruled one way to implement this business process would have been by using OLE. You would have basically created a shrinkwrapped product (anyone remembers this one too?) that would have delegated thru OLE various tasks to products that did them best: Word would have taken care of CV editing , Excel would have taken care of managing the client information, Access would have managed the CV repository, etc… Your product would have concerned itself with the management of the tasks of a head-hunting agency. Your product would basically take different existing software products and put them together in a meaningful way, effectively implementing a business process. This approach would have been better than creating proprietary software for all the parties: the developer would not have had to be concerned with creating a good text editor and the customer would not have had to retrain its staff because they were already familiar with the various pieces that make up the product. If your product was well designed it could have been able to plug different products (let’s say different word processors) in your business process so that the secretary would continue to use WordPerfect instead of Word if she was proficient in it. Your software product would have been tailored to your customer and its business process.
Unfortunately, this type of desktop mashup never occured. More and more proprietary software was churned out at great costs for everybody involved. Small customers continued the mundane practice of copy and paste (in some cases to this day) while big customers shelled out big bucks for `solutions` which were sent to the recycle bin the moment the web revolution took place.
Hopefully, the current `mashup` mindset will put an end to developing huge elephants and make developers concentrate on processes rather than on infrastructure. Anyway, it is more fun.

I was thinking about the "Keep It Short and Simple" mantra applied to UI for desktop products and I was wondering how you could build a large desktop application and have your users manage a large array of components very different in functionality one from another. I was thinking mostly about applications such as Netscape 7 (anyone using it anymore?) where the user has to choose between a large number of components: stock quotes client, email client, RSS feeds client, AIM and whatever other AOL software is bundled in Netscape.
So far the approach for managing large number of components was to basically swamp the user in an ocean of checkboxes, radio buttons, dropdowns, etc… which they would have to click in order to get to the component that they need. Microsoft Word is the perfect example of it: at an UI work-shop I saw Word with all its menus expanded and the text area was shrunk down to the dimensions of a stamp. This approach obviously doesn’t scale: there is only so much room on your user’s computer screen and the user’s  attention span and patience can stretch only so much.
A far better approach would be to have the user discover what it needs from what you have to offer and make the management of those components easy for the user. I am thinking that a product should have a component search capability that would let the user search for its components. A component registry with search capabilities would probably solve this. Also, the user could tag various components and search components tags in order to find what it needs. Basically, every known form of collecting and searching for information should be used for letting your user manage the components easily. Whether collecting and querying this information is done locally or remotely is, obviously, particular to the application being developed and its operational environment.
The big number of components that your application would have to manage would imply that your application should exhibit a certain degree of plugability: the application’s components should interact with one another seamlessly and should be set-up very quickly. Various plugability contracts should be set-up: a component should be able to be demo-ed (without a demo a user would not be able to decide quickly if it needs the component or not), installed, un-installed, re-installed, loaded into the application at runtime, discarded/hidden at runtime, etc…
The product would then become a platform on which various plugins are set-up and assembled together, very similar to the Eclipse IDE. This leads me to say the following: one way to see how the interaction between different UI components will be implemented in the future would be to check out Eclipse’s source code. Eclipse has a certain level of UI plugability and it has the lowest barrier of entry for a developer: it is open-source.
Hey, if your UI requirements match Eclipse’s plug-and-play skeleton you could even use its skeleton for your application (*). The skeleton of the Eclipse IDE would become the free or low-cost infrastructure that you would use for setting up your application.

P.S. Along with the Web 2.0 buzz some sort of a revival in UI is taking place. It looks like interacting with users is being thought about again. Martin Fowler’s GUI Architectures is worth checking out.
P.P.S. When writing this I kept thinking about the launch of Google Talk and the spartan user interface it had at the time. I was wondering how would an user of this product find its various services if the interface was kept simple.
P3.S. This article is concerned with UI management on desktop applications. I think these UI management requirements apply to web-based products but the implementation would be very different. A web application would be transformed into a portal that is easily to be managed by the user. For example, I would like to go to Yahoo’s page and have in the upper right corner some stock quotes, next to them press releases or news about those stocks and in the middle of the page general news. When I’m planning my vacation I would like the middle of the page to be a list of various trip packages rather that the news I usually have. I would like to put up these components and shut them down very easily.

* As far as I know Eclipse’s plug-and-play architecture is intrusive, you have to implement various interfaces, etc… Using Eclipse as a skeleton for building desktop apps would couple your application strongly to Eclipse unless you abstract the interaction between your UI components and create a bridge which will be used for having Eclipse boot-strap your application’s UI. This way you could use other plugable UI frameworks, such as Firefox, for assembling your application’s UI.

A while ago I wrote a post regarding the difference between SOA and CORBA. I saw this assertion on a few bulletin boards a few times and I felt I needed to write about it. Well, if SOA is different from CORBA then what would it be similar to?
Let’s say that you have an enterprise-wide service. Let’s say that a financial institution needs to apply taxes to every financial operation it makes. The enterprise-wide service would be the tax program and the actors would be the software programs that trade currencies, stocks, bonds, accrue interest, etc… Every trade that gets made has to get taxed so your tax service has to interact with all pretty much all the software in the enterprise.
Now suppose that you have this gigantic application that a financial institution uses for making stock trades, buying bonds, applying interest to accounts, etc… Obviously all the financial operations must be taxed. The easiest way to implement tax across all the financial operations would be thru AOP. You would define a tax cross-cutting concern and bind it to the appropriate methods.
The cross-cutting concern would exhibit the same relationship to the application as the SOA service exhibits to the enterprise: they are identical pieces of functionality that apply to very different actors. The cross-cutting concern applies to various methods in an applications, the SOA service applies to various silos in an enterprise information system. From a functional point of view a cross-cutting concern is very much like a service. There is a huge difference in scope between the two concepts, but at the bottom of it they are very similar.

One more thing. SOA is considered the domain of business analysts, the business analyst driving most of the interactions between different services and applications in an enterprise information system. Given the similarities between SOA and AOP it would seem that AOP would be best effective when the interactions between aspects (or services as they are known in SOA) and methods (or applications as they are known in SOA) are managed by business analysts rather than developers…
Good food for thought…

Later edit: I understand that currently the advices used mostly in AOP are concerned with infrastructure issues (concurrency, security, transactions, etc…). However, AOP leaves the door open to assembling applications so that you can bind a piece of functionality to another piece of functionality like the above example with taxes. In this case the usual pointcut semantics will probably not suffice (unless you use annotations) because the advices will not be applied to objects which are related by infrastructure issues (such as persistence or concurrency) and are grouped together by namespaces (such as package names), but rather to objects which are related by business-logic issues (such as manipulating funds). This grouping is probably harder to translate into pointcuts.
Anyway, I think the interesting development in AOP lies with applying advices because of business-logic affinity rather than because of infrastructure needs.

I am looking at AOP as an example of applying the theory of Division of Labor to development. With AOP it is possible to have different types of professionals working on the same project at the same time.
In theory a security expert would secure the application or even better a security expert in one domain would secure one part of the application, while a security expert in another domain would secure another part of the application, a transaction expert would trace transaction boundaries within the application, a concurrency engineer would serialize calls to a state repository in order to implement concurrent access, etc… I say this is possible in theory because managing this interaction takes some good managerial skills and processes, processes with which I am not familiar for the time being.
The division of labor is a process that scales very well in diversity and ultimately in complexity. Various tasks are assigned to people trained specifically for them and are executed in an efficient manner. At the end of it the process has managed to put together a product which is quite complex and has received input for people of various backgrounds. This could be very well the solution to managing complex interactions when developing software: dividing them into tasks which can be performed individually by experts and assembling them at the end. Just like when you have a coffee you don’t have to worry about growing a coffee tree, harvesting the beans and roasting them because someone else did that for you when you are writing an application you should not concern yourself with securing it or implemeting failover thru exception handling because someone else would do this as well.
The division of labor pulled the human race out of the Middle Ages and into the industrial age. Hopefully AOP will be able to pull large, complex projects out of the quagmire of pointless meetings, weekly merges, versions, etc… and into functional, deployed applications.

P.S. I wrote this post on the most horrible coffee I had in a long time. If it had an effect on the post itself I am sorry.
P.P.S. Separation of concerns resembles the division of labor as well.

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…

I am following the dynamic vs static debate and its by-product, the debate of Ruby vs Java, not really understanding what the fuss is all about.

I think we could say that the language used in the XML descriptors of a package using declarative programming (such as an EJB XML descriptor, a struts-config.xml or bean-definitions.xml for Spring) fits the definition of a dynamic language.
You can change the behavior at runtime, you can create new classes and call them from different points in your program, you can even pass invalid objects to your program and find out that your program is not working because you didn’t XML-program (I have to admit ‘XML-program’ is an atrocious name) it correctly.

Declarative programming and the descriptors that enforce the contracts specified declaratively could be viewed as the place where a Java app would act in a dynamic way. The language of the application would be Java + various XML descriptors rather than only Java and this language could be viewed as dynamic.

So far declarative programming has been used mostly for infrastructure (EJB, Struts, etc…) but it would be interesting to see what results if it is being used for describing an application. I am thinking particularly about organizations that write programs that have to be easily customizable (such as a B2C shopping cart, a content-management system, etc…). It would be a good thing if I could describe this application in a declarative way so that I could describe and incorporate a customized business-process easily into the application. My app would be changed dynamically, customized behaviour would be created and passed to the appropriate components, etc… It would be written in Java and described and assembled in XML descriptors. It would be dynamic.

For example when the user presses the submit order button on an e-commerce site I should be able to specify in a declarative fashion that the DB will get updated, the credit card will be charged and the back-office system will know to send the product to the user and ask for replenishment. I want to add this and other functionality and turn it on/off at run-time.

To go back to the debate of Ruby vs Java, I think that Ruby will not get much penetration into enterprise development. The reason is that by now a huge investment has been made in JEE applications, an investment of the size of a few millions line of code that have been developed and, more importantly, tested and debugged. Assuming that you need to add some dynamic behavior to your product you could do so by applying declarative programming to your existing code base rather than re-writing the application once more in the language that happens to be popular. The debate of Ruby vs Java is a non-debate, it debates the current Ruby development environment and Java’s development environment as it was 4-5 years ago, i.e. Java running on its own. However, today most applications written in Java are usually run in some container that allows for loading behavior dynamically. Ruby vs Java + some frameworks would seem a more rational debate, however I have not seen anyone taking part in it.