[Back]

K. Göschka, S. Dustdar, F. Leymann, S. Tai (ed.):
"Proceedings of the 1st Workshop on Middleware for Service Oriented Computing (MW4SOC 2006)";
ACM, 2006, ISBN: 1-59593-425-1; 53 pages.

Service-Oriented Computing (SOC) is an emerging computing paradigm utilizing services to support the rapid development of distributed applications in heterogeneous environments. The visionary promise of Service-Oriented Computing is a world of cooperating services being loosely coupled to flexibly create dynamic business processes and agile applications that may span organisations and computing platforms and can nevertheless adapt quickly and autonomously to changes of requirements or context. Consequently, the subject of Service Oriented Computing is vast and enormously complex, spanning many concepts and technologies that find their origins in diverse disciplines like Workflow Management Systems, Component Based Computing, "classical" Web applications, and Enterprise Application Integration (EAI) including Message Oriented Middleware. In addition, there is a strong need to merge technology with an understanding of business processes and organizational structures, a combination of recognizing an enterprise's pain points and the potential solutions that can be applied to correct them.Middleware, on the other hand, is defined as the software layer that lies between the operating system and the applications on each site of the system in a distributed computing system (ObjectWeb consortium). More generally, the term is used to describe Web servers, application servers, content management systems, and similar tools that support the application development and delivery process. Middleware is the enabling technology of Enterprise Application Integration (EAI) and consequently integral to service-oriented computing. Current middleware in general is challenged to support adaptivity and dependability while maintaining scalability and mastering complexity. Of course dependability and adaptivity can not simply be added to a system like a plug-in module. Rather, middleware needs architectural principles and sound methodologies, as well as appropriate container services, service coordination and composition standards, and possibly consideration of software aspects to help application developers to integrate their services with a configurable distributed middleware instead of re-inventing the wheel each time.While the immediate need of middleware support for Service-Oriented Architectures (SOA) is evident, current approaches and solutions mostly fall short by primarily providing support for the EAI aspect of SOC only and do not sufficiently address composition support, service management and monitoring. Moreover, non-functional properties (like dependability and security) and Quality of Service (QoS) need to be addressed not only by interfacing and communication standards, but also in terms of integrated middleware support. But what makes these issues so different in a SOA setting? Why - for instance - is traditional middleware support for transaction processing different to transaction processing in SOA, reflecting different types of atomicity needs? One answer lies in the loose coupling, high dynamicity and flexibility during run-time, enabled by a significant increase of meta-data, like explicit requirement- and constraint-negotiation during run-time.However, loose coupling is not always the best approach to solve a particular problem. In order to temporarily allow for a stronger (traditional) form of coupling (like group membership agreement) of a set of services, the middleware also has to provide explicit and configurable means to change between different forms of coupling and communication paradigms. This will enable service-based applications to take the best from both worlds by dynamically adjusting the coupling of the composed services.The highly dynamic modularity and need for flexible integration of services (e.g. Web service implementations) may require new middleware architectures. These considerations also lead to the question to what extent service-orientation at the middleware layer itself is benefitial (or not). Recently emerging "Middleware as service"-offerings from the open source community support this trend. However, providing end-to-end servicel-level agreements (SLA), dependability, and autonomic capabilities in a heterogeneous, dynamic, potentially cross-organizational SOA is a particular challenge and the limits and benefits have still to be investigated.