Distributed Computing and Service Oriented Architectures
Few days before I had a discussion with Jostein from Markus Data Norway regarding distributed computing architectures. These days he is involving in designing the system architecture for next generation Procasso system. We were discussing about inter-component and B2B communication technologies such as RMI, Web Services, Remoting, ASPX and their usage in different scenarios. So I thought of making a blog post on Destributed computation and discuss to where it is heading today.
We know OOP approach has made a major revolution in programming models. It has been great success and therefore people tend to look at every problem in an object oriented way. So people came up with the concept of distrubuted objects to solve the distributed computing (DC) problem. Then we started to hear about technologies like java RMI, DCOM, CORBA, .NET Remoting used in solving destributed computing problems.
But in practice organizations started facing lots problems with OO approach of DC, and the messaging systems such as IBM MQSeries, MS MQ technologies, Web Services became much more popular due to the flexibility it provides.
So what is the problem with Destributed Objects. In my openion the concept it self has some problems. Think in this way.. The interface my organization provides to the outside world should present a service but not row data. For an example If my organization is specialized on creditcard processing then I should provide a creditcard processing service to the outside world. But objects are the representation of my business entities and they should be manipulated withing the organization boundry to provide a service. That is on the theory side.. Now on to practical issues..
Distributed Objects (DO) provide very convinient way for developers to work with as they can think and work on remote objects in a similar way as they work with general objects. But the problem is tight coupling between communicating parties. When we talk about tight coupling there can be different type of coupling in DO approach.
a) Code Coupling : In Distributed Objects approach both parties share common interface, i.e actual code. We see DOs works well in the lab, but once u deploy it on production, it is very defficult to evolve one side independent of the other side due to sharing of code. Assume i want to provide a new method on my DO interface because my new business partner wants a new service from me. Addition of this new method will break all my contracts with the existing partners as I have to change my interface code.
b) Time Coupling : DO works in a synchronous manner, i.e the caller waits for the callee to finish the operation. This is obviously not the way to perform a B2B operations.
c) Location Coupling : Assume u call a business method of another company but the response you need to direct to another party not back to you. This kind of addressing issues are not possible to handle with DO model.
On the other hand Web services being XML (text) based messaging technology provides a loosely-coupled communication betweens two parties. We do not share code but messaging meta-data (WSDL). We can define our transport mechanism making asynchronous invications possible. We see Web Services running on HTTP, SMTP, JMS and even on plain TCP. Web service addressing specification provides convinient way to loosen the location coupling between parties.
Due to these reasons we see Service Oriented Architectures based on loosely coupled messaging systems taking over the interconnection domain. But still I think DOs will still has a major role to play on inter-process or inter-component communications withing a sofrware system.