Pattern-based design of a service-oriented middleware for remote object federations

Uwe Zdun
2008 ACM Transactions on Internet Technology  
Service-oriented middleware architectures should enable the rapid realization of loosely coupled services. Unfortunately, existing technologies used for service-oriented middleware architectures, such as Web services, P2P systems, coordination and cooperation technologies, and spontaneous networking, do not fully support all requirements in the realm of loosely coupled business services yet. Typical problems that arise in many business domains are for instance missing central control, complex
more » ... operation models, complex lookup models, or issues regarding dynamic deployment. We used a pattern-based approach to identify the well working solutions in the different technologies for loosely coupled services. Then we reused this design knowledge in our concept for a service-oriented middleware. This concept is centered around a controlled environment, called a federation. Each remote object (a peer service) is controlled in one or more federations, but within this environment peers can collaborate in a simple-to-use, loosely coupled, and ad hoc style of communication. A semantic lookup service is used to let the peers publish rich metadata about themselves to their fellow peers. context of such business applications these goals lead to a set of recurring, technical requirements for the SOA middleware: -Dynamic invocations: In a loosely coupled environment, we cannot always foresee all interfaces of remote objects or services before runtime. Instead new remote objects or services or new versions of them can get deployed at runtime. To cope with such situations, the middleware should support dynamic invocations. -Central control: We require some level of control to ensure that a business service cannot be misused. Consider an e-commerce service that should be provided only to service users who have paid for the service. The middleware technology should offer means to easily define and ensure a suitable control model. -Dynamic deployment: New services or new versions of a service can get deployed and removed at any time. The middleware technology should support the easy deployment and announcement of services at runtime. -Simplified cooperation model: Within a company, it should be very easy to cooperate with other loosely coupled services, for instance, to easily connect services to workflows or rapidly wrap legacy systems. Compared to OO-RPC middleware approaches, such as CORBA, RMI, or DCOM, a simplified cooperation model is needed, but it must not violate the central control requirements. -Lookup support: If interfaces can change and be added at runtime, a flexible lookup service for interface lookup is needed, so that business applications can find out about changes in the service landscape. Because any interface detail might be unknown before runtime, a flexible lookup based on properties and/or flexible lookup queries are useful in more loosely coupled situations. -Service separation: It might optionally be useful to support a clear model for service separation within the local scope of an application. This way the middleware can enforce that the service interaction model is not violated. This eases the implementation of higher-level service interaction models or security features. -Quality attributes: A SOA middleware technology should not have -in comparison to related approaches -a highly negative influence on important quality attributes, such as security, performance, scalability, complexity, or performance. Each of the existing middleware approaches has its particular strengths in some of these areas, but weaknesses in other ones. For instance, Web service approaches offer dynamic invocation models and central control at the server side. But today's Web services stack architectures are already relatively complex. They follow the classical client/server model, and hence do not offer a simplified cooperation model. The deployment model and the lookup approaches are rather static and inflexible. These problems are to a certain extent resolved by P2P systems, which provide a simpler cooperation model and allow for more spontaneous connections. Current P2P environments offer only an "all peers are equals" model, which makes central control hard to achieve. The same can be assessed for spontaneous networks. Coordination and cooperation technologies offer a shared tuplespace as a central, simplified cooperation space. However, they are not specifically designed for dynamic service deployment and standard lookup support is not provided. We propose a novel middleware concept for SOAs and claim that this concept addresses the holistic set of requirements summarized above. Even though each Let us consider a non-trivial example of using a SOA middleware for a company that sells custom applications built upon workflow solutions and other business As its basic communication resource, each Leela application uses a class implementing both a client request handler [Voelter et al. 2004 ] and a server request handler [Voelter et al. 2004 ]. These two patterns are responsible for the basic tasks of establishing connections and message passing between client and server. That is, the class RequestHandler is responsible for sending requests across the network and receiving responses (see Figure 1 ). At the same time it receives incoming requests, dispatches the requests into the server application, and sends the response back to the client side. Each Leela application instance acts as a client and server at the same time. The Leela application instance (a subclass of the request handler) can be accessed by each peer. A SOA should be independent from the protocol used internally. Thus, at the communication layer, represented by the client request handler and server request handler, we require a high flexibility regarding the protocols used. These communication protocols might require different styles of communication, such as synchronous RPC, asynchronous RPC, messaging, publish/subscribe, and others. Variation at the communication layer is usually handled via protocol plug-ins [Voelter et al. 2004] . protocol plug-ins extend the client request handler and server request handler with support for multiple, exchangeable communication protocols to be configured from the higher layers. Leela's request handler contains protocol plug-ins [Voelter et al. 2004] for different protocols that actually transport the message across the network. For each protocol supported, the RequestHandler instantiates a pair of corresponding plug-ins, a client plug-in for sending requests and receiving responses, and a server plug-in for re-
doi:10.1145/1361186.1361191 fatcat:4kcws2uqmzfxpb2cm2e4gukgoe