Current Trends in SOA

Introducing Middleware.

In many ways, humans have been integral to the operation of computer networks, since the dawn of the computer age. In the early 1980’s computers had moved beyond governmental, military and research institutions, and were becoming more common among corporations.

At this stage of their evolution, computer applications were stand-alone. The finance applications of the world lived inside mainframes, and interacted with humans via green screen terminals. The order management systems of the world interacted likewise. Humans were the network, as information could only flow between systems through human intermediaries. For example, a clerk would run a report on one system and re-key the results into the other.

Humans being intelligent, could enforce policies on the flow of information. They could decide what information was appropriate to flow between systems, how quickly it should flow, and how the flow should be achieved.

On the other hand, humans, being error prone, caused this flow of information to be slow, laborious and costly. One day while typing yet another report, a clerk dreamed of letting the computers talk to each other directly. Suddenly, the network revolution had begun.

While the idea was sound, the reality of facilitating this was difficult. Henning (2006) notes, that “persuading programs on different machines to talk to each other was a nightmare, especially if different hardware, operating systems, and programming languages were involved: programmers either used sockets and wrote an entire protocol stack themselves or their programs didn’t talk at all”. What was needed was some sort of automated intermediary between systems.

More than just a translator was required, this intermediary would have to assume responsibility for enforcing the information flow policies which humans had heretofore administered. Hence middleware was born.

The core requirements for middleware have changed little. It is still responsible for marshalling communications between disparate and often incompatible computer systems, while ensuring that information flows between systems, where necessary, in a reliable, secure, and dependable way.

Introducing Service Oriented Architecture.

Issarny, Caporuscio and Georgantas (2007) give a good introduction to the evolution of middleware systems since the network revolution. In many respects, Service Oriented Architecture can be seen as the latest generation within this evolutionary process.

The demands placed on computer systems have also grown since the early 1980s. While middleware began as a way to facilitate communications within a corporation’s network of computer systems, end users and corporations are increasingly expecting systems across corporations to communicate. Sarna-Starosta, Stirewalt, & Dillon (2007) use a travel booking application as an example of service oriented interaction. Perhaps is one of the best examples of this type of application. Using expedia, you are aggregating information from several individual airline, hotel and car hire corporations into one location so as to book flights, hotel and car hire for your next vacation or business trip. Without middleware and specifically service oriented architecture, building an application like this would be prohibitively expensive if even possible.

As Issarny, Caporuscio and Georgantas (2007) note,

[The] Service Oriented Architecture (SOA) paradigm supports the development of distributed software systems in terms of loosely coupled networked services. In SOA, networked resources are made available as autonomous software services that can be accessed without knowledge of their underlying technologies. A key feature of SOA is that services are independent entities, with well defined interfaces, which can be invoked in a standard way, without requiring the client to have knowledge about how the service actually performs it’s tasks.

Middleware Challenges

When we begin to treat individual software systems as autonomous software services, we begin to wonder who can access these systems and what restrictions if any should be applied. Cotroneo, Graziano, & Russo (2004) address the security requirements for SOA applications in the ubiquitous computing space. The same security requirements that are necessary for communications between computers on a network, are also required for safe and secure communications between individual services. The triad of confidentiality, integrity and availability still apply to SOA interactions.

Hosamani, Narayanappa, & Rajan (2007) broach the subject of trustworthiness in Service Oriented Architectures. This is perhaps exacerbated to an extent in that services need to discover each other before making requests of each other. Clients need to know that the service they are communicating with is in fact the service they expect. Security of the service registry is important so that interlopers cannot register malicious services in the hope of capturing service requests in future. Cotroneo, Graziano, & Russo (2004) note the general lack of research specific to security within SOA, so much work is still required in this area.

The performance characteristics of networks of services is also to be considered. SOA applications eventually have to interact with humans and/or the real world. Taking the example from earlier, a human will not be prepared to wait more than a few minutes for the system to suggest flights and accommodations. This brings requirements for performance and predictability to SOA applications.

To this end, Verdickt, Dhoedt, Gielen, & Demeester (2005) discuss a means by which middleware can be modelled so as to provide some metrics for system performance. This is useful for the early stages of system design when choosing a particular middleware system. While Duran-Limon, Blair, & Coulson, (2004) show that SOA is unsuited to mobile, multimedia, embedded and real-time systems because of the lack of performance or predictability guarantees. Sarna-Starosta, Stirewalt, & Dillon (2007) go further to suggest that performance characteristics of services should be written declaratively so that performance requirements can be negotiated before services make requests of each other.

Adaptability and stability are aspects of software that SOA applications are also expected to meet. Meehan, & Livny, (2007) tackle this by suggesting that services should be made resource aware so they can refuse requests or self-terminate when they are overloaded so as to maintain the effectiveness of the network at large. Most modern application servers can be configured to intercept a service request and restart a failed service when necessary.

New Applications

SOA seems to have a symbiotic relationship with developments in application structure. SOA is enabling Grid computing, Ubiquitous computing, and Web Services, and because of the needs of these applications, SOA is itself being changed to meet those challenges.

Corsaro & Schmidt (2003) note how application servers of the day were unsuitable for real time applications such as streaming multimedia, and stock trading applications. With a stock trading application for example, time is literally money, so a trade must be guaranteed to succeed within an acceptable time frame. Since Corsaro & Schmidt wrote their paper in 2003, the Java language has continued to develop support for real time programming and applications by publishing a Real Time Specification for Java (, though perhaps the reference implementation is too new to have been used by current Java application servers.

Ubiquitous computing also presents challenges to SOA. In recent years economies such as Brazil, Russia, India and China have been large consumers of mobile devices. These countries also don’t have widespread adoption of broadband networks such as western economies. The net effect of this is that the majority of people in these countries, and in the future in general, will interact with the Internet through their mobile devices (ABI Research, 2007).

SOA and web services are ideally suited to this type of application, though by comparison with personal computers, mobile devices offer less memory and computing power, so more computation and data storage and caching has to occur on the server side. Such applications also have specialised security requirements (Cotroneo, Graziano & Russo. 2004).

Arunachalan, & Light (2007) give a good example of such a new, mobile device based, service oriented application. They give details on the implementation of a patient care system where everyone from ambulance staff to hospital based nurses and doctors can track and share patient care information through the use of hand held mobile devices. A beneficial effect of the speed of information transferal, a doctor can be appraised of a patient’s condition as they are traveling to a hospital by ambulance for example. As mobile phones, and other hand held devices continue to be expanded with more and more capabilities, such as photo and video, the benefit to a doctor of an early multimedia information update of a patient’s status is obvious.

Human Factors

Middleware in general, and SOA specifically as mentioned above, are tools which humans use to allow disparate and heterogeneous systems to communicate. As we have already covered, middleware is being pushed into new and exciting applications, while individual challenges such as networking, security, scalability etc., are being solved. The final challenge facing SOA is that of software engineering as Issarny, Caporuscio & Georgantas (2007) note:

The advent of middleware standards contributed to the systematic adoption of the technology for distributed software development. However, mature engineering methodologies to comprehensively assist the development of middleware-based software systems, from requirements analysis to deployment and maintenance, are lagging behind. Indeed, software development accounting for middleware support is only emerging. Still, the networking infrastructure is evolving at a fast pace, and suggests new development paradigms for distributed systems, leading to new middleware platforms and further calling for novel software engineering methods and tools.


SOA is an exciting, disruptive technology which relieves software developers from low level networking implementation details, and allows for higher level abstractions, perhaps even offering quality of service guarantees and/or domain specific functionalities through reusable middleware -level services (Issarny, Caporuscio & Georgantas. 2007).

Though perhaps we are only at the beginning of the SOA revolution. As older CORBA and mainframe based systems are decommissioned, it would be fair to assume that SOA could grow to replace those systems, or perhaps even elongate their lifetimes. As demand for SOA based applications grows, more and more software developers can expect to have to deal with the technology, perhaps expediting the software engineering approaches to the use of this technology, as Issarny, Caporuscio & Georgantas (2007) note:

Major system requirements posed by today’s networking infrastructure relate to openness and mobility, and context-awareness. This leads to investigate next generation middleware with support for universal interoperability, open coordination, and context aware adaptability. Further, with the middleware becoming central in software development, software processes shall evolve to integrate middleware features at all phases of the software development.


  1. ABI Research. (2007) Nearly 95 Million “Ultra-Mobile Devices” to Ship by 2012. Retrieved Nov.13 2007 from
  2. Arunachalan, B. & Light, J. (2007) Middleware Architecture for Patient Care Data Transmission Using Wireless Networks. Proceedings of the 2007 International Conference on Wireless Communications and Mobile Computing. 182 – 185.
  3. Corsaro, A. & Schmidt, D. C. (2003) The design and performance of real-time Java middleware. IEEE Transactions on Parallel and Distributed Systems. Vol. 14, Issue 11. 1155 – 1167.
  4. Cotroneo, D., Graziano, A. & Russo, S. (2004) Security Requirements in Service Oriented Architectures for Ubiquitous Computing. Proceedings of the 2nd Workshop on Middleware for Pervasive and Ad-hoc Computing. 172 – 177.
  5. Duran-Limon, H. A., Blair, G. S. & Coulson, G. (2004) Adaptive Resource Management in Middleware: a Survey. IEEE Distributed Systems Online. Vol. 5, Issue 7.
  6. Henning, M. (2006) The Rise and Fall of CORBA. ACM Queue. Vol. 4, Issue 5.
  7. Hosamani, M., Narayanappa, H. & Rajan, H. (2007) Monitoring the Monitor: An Approach Towards Trustworthiness in Service Oriented Architecture. Proceedings of the 2nd International Workshop on Service Oriented Engineering: in conjunction with the 6th ESFC/FSE joint meeting. 42 – 46.
  8. Issarny, V., Caporuscio, M. & Georgantas, N. (2007) A Perspective on the Future of Middleware Based Software Engineering. Proceedings of the 2007 International Conference on Software Engineering. 244 – 258.
  9. Meehan, J. & Livny, M. (2007) Environmentally Responsible Middleware: An Altruistic Behaviour Model for Distributed Middleware Components. Proceedings of the 16th International Symposium on High Performance Distributed Computing. 209 – 210.
  10. Sarna-Starosta, B., Stirewalt, R. E. K. & Dillon, L. K. (2007) Contracts and Middleware for Safe SOA Applications. Proceedings of the International Workshop on Systems Development in SOA Environments. 5 – 10.
  11. Verdickt, T., Dhoedt, B., Gielen, F. & Demeester, P. (2005) Automatic Inclusion of Middleware Performance Attributes into Architectural UML Software Models. IEEE Transactions on Software Engineering. Vol. 31., Issue 8. 695 – 711.

Tags: , , , , ,

%d bloggers like this: