• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
1. Introduction
 

1. Introduction

on

  • 235 views

 

Statistics

Views

Total Views
235
Views on SlideShare
235
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    1. Introduction 1. Introduction Document Transcript

    • A Polyarchical Middleware for Self-Regenerative Invocation of Multi-Standard Ubiquitous Services M. Yu, A. Taleb-Bendiab and D. Reilly School of Computing and Mathematical Science Liverpool John Moores University Byrom Street Liverpool, L3 3AF UK {cmsmyu, a.talebbendiab and d.reilly}@livjm.ac.uk Abstract have been designed to support the distributed applications and systems, which are capable of Whilst the vision of a robust Service-Oriented automatically adapting and/or evolving their Architecture (SOA) is very seductive it engenders many behaviours due to the availability of resources within technical challenges. The main challenge is the the execution environments. Through a high-level development and support of runtime cross-standard programming model, distribution middleware service activation and interoperation. Such architectures provide sufficient protocols and utilities, interoperation will provide a vital stepping-stone which allow application developers to concentrate on towards the integration of the emerging SOA standards programming required application’s logic with no and legacy services – those developed using existing concern of lower-level runtime environments middleware architectures such as DCOM, COBRA, including; operating system and networking. Relying J2EE, Web service, JXTA, and Jini. Much related on such architectures, developers can build their own works already exist including WSIF framework, which runtime failure-detection and recovery [3] strategies, provides APIs to support design-time invocation of which enable applications/systems to recover from cross-standard Web services deployed on multiple variations in the execution environment such as: SOAP packages. However, this paper focuses on a network fault, service update, replacement, failure runtime self-regenerative mechanism related to and/or evolution. As a result, the systems can still adaptive service invocation code. The paper will operate in the event of failure by discovering alternate present a runtime service adaptation mechanism, services and reconfiguring the communication or which supports end-users to dynamically adapt to invocation mechanisms to match those found services. variations in the execution environment, without For example, the Jini Multicast/Group Discovery altering their original design, crossing multiple mechanism can be used to discover alternate services standards (both synchronous and asynchronous by lookup within a certain range of Jini Lookup servers invocation models) and middleware architectures. This at runtime. paper also introduces a proposed “Polyarchical However, such middleware technologies often Middleware” architecture to support such self- require that components and applications implement a regenerative service adaptation. An illustrative single programming standard (e.g. Jini Technology example will be used to describe the approach and the uses Java RMI) or adhere to a certain definition (i.e. current implementation. The paper will conclude with CORBA Interface Definition Language). If service general remarks and mention of further work. adaptation occurs within the same standard, these distributed middleware technologies can still flexibly respond to runtime on-demand requests and enable 1. Introduction systems to self-configure and recover from unpredictable changes. We argue, however, that in Static distributed architectures have reached their practice, components may have been developed and limits to cope with dynamically changeable and deployed using different activation standards—even unpredictable execution environments, especially in for a given middleware platform. Thus, at the cost of the military applications [1]. In order to accommodate equipping software infrastructure with every possible such needs, the distributed architectures of the next activation adapters or translating to whatever is the generation (CORBA, Jini, Web services and UPnP [2]) prevailing trend current distribution middleware
    • technologies are unable to spontaneously discover and The paper also describes a developed Polyarchical bind to heterogeneous software services -- thus, they Middleware architecture, developed to support the unsuitable for seamlessly support self-healing of cross- adaptation middleware service by managing the standard applications and software components runtime construction of the adaptation behaviours and models. In short, such multi-standard service monitoring its performance. To do so, the architecture interoperation and adaptation would require a provides a set of integrated utilities for cross-standard considerable amount of manual configuration and services such as: dynamic service discovery/lookup, adaptation. Ideally, if services can be transparently sufficient self-diagnosis on the service invocation discovered and subscribed to regardless of their native instruction, reliable service adaptation generation and activation model, it would enhance cost of high- interoperation management of the given end-user availability through runtime software self-healing. By applications. The Polyarchical Middleware is intended eliminating the need to redesign the system to to provide core middleware service models (both accommodate the unpredicted changes, the distributed Object-Oriented and Message-Oriented middleware) system can reconfigure/update the services without and support self-healing support for ubiquitous disrupting the system’s processing. In short the system computing applications. is capable of performing on-demand discovery and The remainder of the paper is organized into six subscription to the given services of choice. sections: Section 2 describes several ongoing related Several ongoing related works such as; Web research and development themes. Section 3, describes Service Invocation Framework (SWIF) [Ref], the dynamic service adaptation mechanism. Section 4, OpenWings [Ref] to name bust a few have recognised presents the development of the Polyarchical and addressed such cross-standards interoperation and Middleware architecture, which mediates the on- activation concerns. Where distributed systems demand service requests and hides the adaptation deployed using such frameworks and associated APIs technical details. Section 5, describes a recent case have typically featured design-time support for cross- study conducted to evaluate and test our framework. standard activation. We believe, however, that there is Finally, Section 6 draws overall conclusions and a need for a self-generative programming model, mentions directions for future work. which enables runtime and on-demand invocation of available software services via template meta 2. Related Works programming and/or automatic model-based code generation. Web Service Invocation Framework (WSIF) [4], is In this paper, we describe a self-regenerative documented to supply developers with standard APIs adaptation middleware service, which is based on a to invoke Web services through an abstract developed mechanism for distributed systems to adapt representation model, rather than that of the automatically to their execution environments conventional Web Services programming model regardless of services’ protocols, standards and closely tided to Simple Object Access Protocol SOAP middleware technologies used for their deployment protocol. Thus, providing a degree of flexibility for and/or management. This novel middleware service multi-standard service binding and adaptation. Current supports distributed systems to restore their release tested by the authors, however, it assumes communications with remote services through SOAP as the underlying wire-protocol whilst allowing automatically generated mobile code (in the form of developers to adopt their own programming model adapters, filters and/or wrappers) in the event of regardless of which SOAP packages used. Such service interface heterogeneity. As a result, our distributed adaptation and protocol-independence requires the end- systems have high-runtime adaptation and users to implement the WSIF special APIs. However, interoperability features, hence suitable to support and our approach tends to adapt the service connector class interact with deployed ubiquitous and legacy services relying on runtime auto-generated mobile invocation (in varieties of styles and standards). The developed code support many standards including SOAP-RPC, automatic mobile code generation is based on a RMI. Template Class design model1. Open Grid Services Architecture (OGSA) initiative 1 is still in its early stage, has been introduced by IBM to The service binding information is self- integrate Grid-enabled Web services across the diagnosed/reflected by our model from service Internet. The transport protocol SOAP is used to invocation instructions/signatures, and filled into the connect data and application on Grid service discovery, template classes to finalize the concrete service sharing and composition in a dynamic distributed adaptive components (adapter) at runtime. environment. The standard interface of Grid service,
    • described by Web Service Description Language at runtime. Which wraps all the technical (WSDL), includes multiple bindings and implementation details inside a Java Object. As a implementations. Such Grid services can be deployed result, the client application can ignore the service on different hosting environments-even different adaptation details, and simply invoke the service via operating systems. As one of the invocation proxies, the adapter to solve the integration problem. Here, the existing WSIF has been used to dynamically detect template class files are reused to generate the concrete the SOAP binding protocols and construct the service adapters by bundled with the customized appropriate invocation code. Our approach intends to service invocation information (e.g. service method integrate multiple standards services into the grid name and parameters). Such information is interpreted interoperation by self-regenerating adaptive invocation by our Polyarchical Middleware using a varieties of code for the demand services. service interfaces, which are normally used to specify OpenWings initiative [5] was first set up to how to invoke a given service type. Figure 1, shows investigate the military computing dependability the anatomy of service adaptation sequence. requirements, one of its focuses was the discovery and replacement of software services in modern critical and volatile environment. This uses a component-connector model to represent the inter-communication between two different standards. By creating a protocol abstract layer, both sides need to implement special APIs to translate method calls to and back from that layer, where all the data and information is transmitted. Whilst, our approach has a similar overall goal, it focuses mainly on enabling the open distributed systems with high adaptiveness and interoperability features at runtime, by self-regenerating the adaptive Figure 1. Service Adaptation Sequence code to the given services of the choice. Both end- Where as shown in Figure 1, the protocol 1 method users and service providers can still retain their original call can be adapted to the protocol 2 call via a Service design and bindings without having to translate Adapter. Thus, Application 2 can be invoked by the invocation call to a chosen/universal encoding through protocol 2 method call using the normal data encoding any special APIs or sender/receiver proxies. (i.e. serialization/deserialization in Java RMI or In this paper, we present a middleware service marshalling/unmarshalling in SOAP-RPC of based on a developed self-regenerative programming parameters and results). model for self-healing applications. Here, the programming model is focused mainly on the runtime code generation for cross-standard grid services 3.1. Template-Based Self-Regenerative invocation. In this paper, we argue that such a novel Adapter middleware service will extend existing approaches for autonomic computing to cope with variety of not only In contrast to our own work, other researchers, operating systems, platforms, but also architectural including OpenWings, intend to translate method calls styles and middleware standards. to a standardized protocol transmission [Ref]. However, in our approach a service adapter is automatically generated at runtime using a selected 3. Dynamic Service Adaptation Mechanism template class together with retrieved invocation information from the required service description file We begin by considering a scenario, in which two (for example a Web Service Description Language). applications services designed using different Our Polyarchical Middleware bundles these programming models (e.g. client-server/peer-to-peer) template classes with the service invocation require to require each other as a network resource. information to generate the concrete service adapter Obviously, they can’t launch the communication files at runtime. These adapters alleviate the need to directly, due to their differing service interaction implement any special APIs or proxies or classes on semantics (Fig. 1). Assuming that no runtime alteration both sides. to their original designs is allowable or adapters are As in Figure 2, a SOAP-RPC template class is used available. In such a case, the proposed Polyarchical to illustrate the mechanism, which require access to the Middleware is used to generate the appropriate Service following information contained in a service WSDL Adaptation Code (referred to here as Service Adapter) document namely:
    • The URL of the SOAP-RPC rpcrouter which enables runtime adaptation code generation The request URI for the service using defined template classes (Section 3). In this The service method name architecture, code generation service integrated with a The parameters for the invocation set of components including; dynamic service lookup manager and service adaptation manager, to monitor the performance and construct the adaptation behaviour. Figure 3. Framework Architecture Figure 2. SOAP-RPC Adapter Code Clips This polyarchical middleware architecture is based on a three-layer model, through which runtime requests As shown in Figure 2, all our service adaptation for service adapters (invocation service utility) is template classes will implement an interface Adapter, access through a common HTTP access service. In which declares a single “invoke()” method to addition, the framework enables the dynamic lookup standardize and hide the exact invocation mechanism for and invocation of required services abstracting details. Each individual service adaptation template service discovery and invocation. Through the class can override that standard method to implement framework, end-users may concentrate specifically on their own specific service invocation details. The end their application without having to worry about result of using such interface is for the service inconsistencies or mismatches between component mechanism independence. At runtime, any adapter file standards. A detailed description of the polyarchical can be initialized and cast to an instance of that middleware is outside of the scope of this paper and interface, through which the “invoke()‖ method will be can be found in [6]. This paper, however, focuses on called individually with different invocation the main functionalities of this polyarchical mechanism. middleware including: integration of both synchronous and asynchronous service models. In addition, an 4. Architecture of the Framework illustrative example is here used to describe the middleware operation including; code self-generation This section presents the ongoing development of and mobility through a self-healing behaviour. the framework, which currently prototyped using Java programming language. 4.2. Main Functionalities 4.1. Brief Introduction of the Polyarchical 4.2.1. Synchronous and Asynchronous Service Invocation Integration. For decades, synchronous and Middleware asynchronous invocation mechanisms have been used for distributed systems programming. Synchronous The Polyarchical Middleware is designed to support invocation models (such as SOAP-RPC, Java RMI and the self-regenerative adaptive invocation service, CORBA IIOP) provide a tight client/server model,
    • which normally blocks the client process during the middleware service as the core service to dynamically remote invocations. Asynchronous invocation based on discover and invoke the synchronous services. message-oriented models including: Java Messaging Service and JXTA, frees the client to continue 4.2.2. Dynamic Service Discovery. Dynamic service operation processes while waiting for the results. To discovery/lookup, monitored by the service lookup accommodate such diversity, we provide a simple and manager, is designed here to support distributed intuitive model, which integrates both synchronous and systems to discover cross standard services. Where, asynchronous mechanisms supporting service service discovery can be achieved through either a activation such as: dynamic service discovery, service local/centralized registry server, or other individual description interpretation and interoperation across registry servers (in varieties of types and standards) if standards. required. To support such dynamic service lookup Synchronous invocation model: fully utilizes the process, a Universal Description, Discovery and template class design to provide adaptation activations Integration (UDDI) compliant registry server was across varieties of service invocation mechanisms. The introduced, which holds two types of descriptions Service Adaptation Manager generates the adapter namely: (i) Individual ubiquitous services – objects for the matched available service components, descriptions about the service components individually by bundling the invocation information into the in standard service description language (in the form of template classes. The code mobility is also designed to a WSDL document); (ii) Existing Service Registry enable client services to download the auto-generated Servers: like Java’s RMI registry server, Jini’s Lookup adapter objects from our polyarchical middleware, in server or Web Service’s registry server (usually in which, client services can invoke the target services via format of UDDI). These registry servers can be the adapters individually without further intermediary accessed through the polyarchical middleware through of polyarchical middleware. All the adaptation the Internet/Intranet. technical details are hidden away from the end-users through a standard interface, which can be overridden 4.2.3. Service Description Interpretation. Vital for by any specific service invocation mechanism. the accurate characterization of types of discovered Asynchronous invocation model: a JXTA-based services the middleware uses a diagnosis service to prototype is developed and outlined here to illustrate identify the end-to-end services invocation protocol the integration of the asynchronous model into our and requirements including where and how to deploy runtime dynamic service discovery design. This it. In the considered scenario (Sec. 3) the invocation provides a flexible architecture to publish and information are retrieved or reflected from the service subscribe to services via a peer-to-peer model. Where description files or the interface files, which will any peer member can act as a server to a given service trigger the self-generation process provided with the request. The self-regenerative adaptation Middleware appropriate type of template class file retrieved from service is here prototyped as a JXTA peer providing the codebase. self-healing, code generation and/or invocation The service diagnosis utility is also based on intermediary party. template model, where each diagnosis template class In this model, first a new peer group is created to provides generic structures or source codes for register and publish our adaptation middleware service. interpreting invocation information bound with an Then, JXTA peers can discover our new peer group individual service standard/mechanism. Such template through the peer group advertisement over the classes extend a same abstract class parser, which network. After establishing an identity and joining into declares common parameters and abstract methods to our group, peers can discover and utilize the adaptation save/set the invocation information. This information service as a normal core service. A ServiceListener will be used to drive the service adaptation object is also designed here to listen and notify the construction in the next stage (i.e. self-generation of incoming adaptation request messages from the peers. adaptation). Any derived template class can override Thus, the polyarchical middleware acts as a third- those abstract methods with their own implementations party system, which can facilitate the distributed to interpret and save the invocation information from a systems to discover and invoke service components variety of service description documents/interface deployed on both synchronous and asynchronous objects. models. For instance, a synchronous service system Currently, several parsers have been developed to can post asynchronous request messages over the interpret invocation information from service network for adopting JXTA peer service through our description documents (such as WSDL) and interface polyarchical middleware. On the contrary, the member objects (such as Java Remote Interface). peers within our peer group can use the adaptation
    • The benefits of doing this as the following: 4.2.5. Extensible Service Adaptation Ability. As Robust runtime self-diagnosis on service mentioned in the Section 3, the template class design invocation across-standards. This enables end- model is used here for runtime generation of the users/distributed systems to auto-adopt any service adapter file. One danger of such design is that it type of varieties of service components, might be easy to meet a limited range of service especially for those small footprint adaptation ability, relying on the numbers/types of devices/systems without having all the available adapters. With this in mind, our Polyarchical functionalities preinstalled. Middleware is desirable to extend its adaptation ability Abstract interface to solve the service by adding/updating new adapters as and when new integration problem by hiding the technical service component standards are introduced in future. details away We intend to introduce a XML-based Template Index Extensibility on service description Language (TIL) into the framework. It is used here to interpretation. There are varieties of service organize/register the information (e.g. Template Class description mechanisms that may have been Name, Class Location Path or brief functionality available/deployed to describe the service introduction) for our current adapters and register new components. Our polyarchical middleware ones, as existing or new service mechanisms are can feasibly extend its interpretation ability by required. Working closely with the TIL, the Service adding/designing more parsers for existing or Adaptation Manager can remain the same emerging description mechanisms, which programming structure and dynamically launch an efficiently provides the instance of any matched adaptation template class with translation/interpretation ability between the given string. multiple services for end-users/distributed systems without altering their original 5. Case Study designs. The above framework is still under development. 4.2.4. Service Adaptation Code Mobility. Code To date, several service adapter template class and mobility is supported to facilitate clients to download components of the framework have already been middleware auto-generated code. Thus allowing clients implemented and tested on an existing case study, from to invoke the targeted services via the generated which illustrates how the self-regenerated service service adapter without the need for a third-party adapter works at runtime. intermediary host (service). As a result, parts of the We considered a simplified service assembly of service adaptation processes are shifted from the three services (text editor, spell checker and print) that heavily-loaded polyarchical middleware to the lightly- represent a given distributed application. The service loaded end-users hosts, and enabling decentralization. components are integrated by using Java RMI The current prototype is limited to Java-based code (synchronous communication) as the underlying mobility (Fig. 4)., other approach for Java Serialization protocol. A service manager/system controller was to XML [7] is under development for end-users responsible for monitoring the service failure and without JVM. sending the service adaptation request to our polyarchical middleware. It assumed that component2 (spell checker) has failed for some reasons: service failure, service update or moved from the network. Restricted to the resource availability, the alternate services are only bound with the standards other than Java RMI. Without halting the distributed system process for waiting the recovery of service component2 or manually configuring on the service adaptation, our polyarchical middleware supported this user application to be self-aware/diagnosis the alternate services and construct the proper invocation calls through a self-generated adapter at runtime. Here we assumed a SOAP-RPC bound service is available for interaction. First all, the Service Lookup Manager will discover Figure 4. Adaptation Code Migration the available service and retrieve the service invocation
    • details through its description files. After making a 6. Conclusions connection with our UDDI registry server (http://localhost:8080/RegistryServer), the Service In this paper we have argued for the need for cross- Lookup Manager queried the UDDI server using the standard service invocation, and described a keyword ―SpellChecker‖, retrieved from the user polyarchical middleware service for runtime cross- application. The BusinessQueryManager interface standard service invocation. The approach is based on returned an organization object, which contains the a self-regenerative programming model, which is binding information about that SOAP-RPC service. illustrated within the context of self-healing The Service and Servicebinding object associated with applications. that organization were used to store the service details Where, it enables end-users to recover from a including: the URL of the WSDL document. Calling failure, by finding and self-regenerating proper for example the following line of code will return the adaptive invocation classes regardless of their native URL of the WSDL document for that SOAP-RPC and/or supported invocation model. service. Development is still underway to extend the ServiceBinding sb = (ServiceBinding) sbIter.next(); prototyped middleware services in a number of String url = sb.getAccessURI (); directions including; The value of the string url will be passed to the Integrate the asynchronous invocation model WSDLParserSOAPRPC.java class file for interpreting with the synchronous model through our invocation information of that SOAP-RPC service. Polyarchical Middleware. After that, the Service Adaptation Manager was To offer a good user interface for registering capable to generate the SOAP-RPC adapter by the grid service individually with our initialising an instance of the template class embedded registry server and a good user SOAPRPCAdapter.java (mentioned in Section 3) and interface to organize our service adaptation appending the SOAP-RPC invocation information into template classes associated with the proposed it through its constructor. At the next stage, that Template Index Language (TIL). generated adapter will be downloaded to the distributed Best-fit matched stage: Find/Discover the application side. The WriteMarshalled class file, called ―best-match‖ service component from those by the Service Adaptation Manager, launched an services returned by the Service Lookup instance of the class java.rmi.MarshalledObject to Manager. serialize that adapter into a marshalled file (adapter.ser). A Tomcat HTTP Web server was used here to publish that adapter.ser and enable the service 7. References manager of distributed application to access and download it through the http protocol. The JVM at the 1. Guy Bieber, L.A., motorola ISD C4I; Jeff user application’s side deserialized that adapter file Carpenter, Software Engineer, Motorola ISD C4I, back from the bytecode (adapter.ser) by calling get() "Openwings A Serivce-Oriented Component method. Because all the invocation information have Architecture for Self-Forming, Self-Healing, already been set into that Java Object, the service Network-Centric System (Rev 2.0)". manager can directly invoke the SOAP-RPC service by 2. "Universal Plug and Play Device Architecture", calling a standard method invoke() reflected (using accessed: Jan,2004, last updated date: Jun 2000 Java Reflection) from that returned adapter file. http://www.upnp.org/download/upnpda10_200006 In this test, our Polyarchical Middleware recovered 13.htm the user application from the service failure and 3. C. Dabrowski and K.Mills. "Understanding Self- maintained the system process by finding/invoking healing in Service-Discovery Systems". in ACM alternate services after offering the self-generated SIGSOFT Workshop on Self-Healing Systems adaptation files at runtime. The user application was (WOSS'02). Nov 18-22, 2002. Charleston, South able to continue working without having to half /wait Carolina, USA. ISBN: 1-58113-609-9, for the recovery of Java RMI bound service or 4. Matthew J. Duflter, N.K.M., Aleksander Slominski implementing any special APIs at design time, as it and Sanjiva Weerawarana;IBM T.J. Watson was possible to invoke SOAP-RPC bound service as an Research Center, "Web Service Invocation alternative through the self-regenerative invocation Framework (WSIF)", August 9, 2001, accessed: adapter. July 2003, last updated date: http://www.research.ibm.com/people/b/bth/OOWS 2001/duftler.pdf
    • 5. Wade Wassenberg, S.E., Motorola ISD, "Protocol Independent Programming Using Openwings Connector Services", accessed: Oct 2003, last updated date: http://www.openwings.org/download/specs/Openw ingsConnectorWhitepaper.pdf 6. M. Yu, A. Taleb-Bendiab, D. Reilly and Wail Omar. "Ubiquitous Service Interoperation through Polyarchical Middleware". in 2003 IEEE/WIC International Conference on Web Intelligence. 2003. Halifax, Canada: IEEE Computer Society. 0- 7695-1932-6, 7. Macmillan, B., "Java Serialization to XML-JSX 2 branch", accessed: Aug, 2003, last updated date: October 10th 2000 http://freshmeat.net/projects/jsx/ 8. Kishore channabasavaiah, K.H.a.E.M.T.J., "Migrating to a service-oriented architecture, Part 1", accessed: Jan, 2004, last updated date: 16, Dec, 2003 http://www- 106.ibm.com/developerworks/webservices/library/ ws-migratesoa/