Proceedings of the 2nd workshop on Middleware for service oriented computing: held at the ACM/IFIP/USENIX International Middleware Conference
Service Oriented Computing (SOC) is a computing paradigm broadly pushed by vendors, utilizing services to support the rapid development of distributed applications in heterogeneous environments. The visionary promise of SOC is a world of cooperating services being loosely coupled to flexibly create dynamic business processes and agile applications that may span organizations 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 by the ObjectWeb consortium as the software layer in a distributed computing system that lies between the operating system and the applications on each site of the system. Middleware is the enabling technology of system and enterprise application integration (EAI) and therefore it clearly and evidently plays a key role for SOC. 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, quality properties (in particular dependability and security) 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 administrative heterogeneity, the loose coupling between coarsegrained operations and long-running interactions, high dynamicity, and the required flexibility during run-time. Recently, massive-scale and mobility were added to the challenges for Middleware for SOC. 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 or atomic transaction), the middleware also has to provide explicit and configurable means to change between different strengths of coupling and various communication paradigms. This will enable servicebased applications to take the best from both worlds by dynamically adjusting the interactions between the composed services. The highly dynamic modularity and need for flexible integration of services (e.g. Web service implementations) may require new middleware architectures, protocols, and services. These considerations also lead to the question to what extent service-orientation at the middleware layer itself is beneficial (or not). Recently emerging "Middleware as service" offerings, from providers like Amazon or from the open source community, support this trend towards "infrastructure services" that can be purchased and consumed over the Internet. However, this model may not be suitable for all kinds of middleware functions, including those addressing dependability (availability, reliability, integrity, safety, maintainability). Providing end-to-end properties and addressing cross-cutting concerns in a crossorganizational SOA is a particular challenge and the limits and benefits thereof have still to be investigated.
Read more
5