A Component-Based Solution and Architecture for Dynamic Service-Based Applications Alessio Colzi, Tommaso Martini, Paolo Nesi, Davide Rogai Department of Systems and Informatics, Distributed Systems and Internet Technology Lab (DISIT) University of Florence, Florence, Italy, tel 0039-055-4796523, www.dsi.unifi.it,
[email protected]
Abstract Recently many new middleware frameworks are going to enforce more dynamism to their component-based models and systems. In this context, an application is build as the composition of several components/services. The main challenge is dynamic deployment and update of such components, during the application lifetime, including the discovering of the suitable components in the network and the decoupling of application code from component’s nature, implementation. These features increase dynamism and the flexibility. In this paper, the main principles of a solution that allows the dynamic management, allocation and connection of remote service, including capabilities of deploying and updating of such components, during the application lifetime is proposed. The described solutions has been used to add those functionalities to a middleware based on .NET framework and has been accepted for defining the distributed services capabilities part of MPEG M3W (Multimedia Middleware) of ISO IEC230043, that is now becoming an official standard.
1. Introduction The first implementations of middleware [1], [2] have been mainly realized as interoperability layers among heterogeneous computer based systems for general purpose usage. Recently, more specific middlewares have been proposed while those with general capabilities have been deeply integrated into the most diffused development platforms and/or operating systems. This trend has provoked the production of middlewares and frameworks for workflow applications, peer to peer applications, GRID solutions, industrial automation, home automation, multimedia [2], etc. Most of the proposed component-based middleware models defines the same concept as building blocks, such as the (i) support for the reuse of components by specifying interface and contract of the offered services, (ii) portability of the framework among different platforms, (iii) interoperability of the framework by using different languages by providing “language bindings” of component access functionality, (iv) dynamic binding of component services in order to compose them in a suitable architecture, (v) exploitation of component
services over a distributed environment (notification of available services, activation and invocation). Other features can be required to acquire maximum benefits from the usage of a component-based framework for multimedia applications: real-time, robustness, security, interoperability, low-footprint, updating and trading. Some of the most important middleware models are (in some cases, specific for multimedia): CORBA\CCM [1], DCOM, .NET, EJB, JINI, Robocop, PECOS, RUBUS, MPEG M3W [2], PECT, PBO, UPnP, OSGI, HAVi, KOALA, etc.[1], [4], [5], [6]. The main challenge is dynamic deployment and update of such components, during the application lifetime, including the discovering of the suitable components in the network and the decoupling of application code from component’s nature, implementation. These features increase dynamism and the flexibility. In this paper, the main principles of a solution that address these aspects are proposed. This has been used to add those functionalities to .NET in relationships with AXMEDIS R&D IP FP6 project of the European Commission [7]. It inspired the definition of the “remote capabilities” part of MPEG M3W (MPEG Multimedia Middleware) of ISO IEC23004-3, that is now becoming an official standard. The paper is organized as follows. In Section 2, motivations and rationales of the distributing computing model are discussed. Section 3 reports the main principles of the solution for enforcing the proposed dynamism in the component-based middlewares. In Section 4, the usages of the solution proposed in a middleware based on .NET and its adoption by MPEG M3W (explaining also how this work contributed to the standardization) are commented. An example is reported as well. Conclusions are drawn in Section 5.
2. Motivations for Distributed computing and services In this section, the most relevant scenario is reported (it is related to the AXMEDIS project [4], and in general to network of embedded systems and PC for multimedia applications, see also MPEG M3W) as an example in which several component services, located on different devices should be usable in a transparent manner,
independently from their location in the home network of multimedia devices (as shown in Figure 1). In this case, the services are published functionalities of some components put at disposal of other components in the network. In this scenario, a component should use transparently any of the multimedia components/services. In this context, the PCs may act as a service provider (as a sort of multimedia center) for the several multimedia devices that are present and connected. On the other hand, some devices can only use specific component services, deployed on and provided by other devices. Furthermore, any service/component should be updated from a thirdparty. Applications may reside on any device and can be developed and/or reused on different platforms; their lifetime is guaranteed by software component maintenance and update (e.g., via Internet). Component vendors can simply reuse the middleware runtime features to deliver software components to the user and the latter can treat his/her own software as a resource to be archived in a storage device for further/different usages. Applications can be developed and/or reused on different platforms; the life time of these platforms is guaranteed by the middleware runtime features (i.e., simply requesting new services to the middleware runtime, which provides retrieving and installation). The services/components can be of coding, decoding, adaptation or media processing in general. In general, the component (see Figure 2b) groups a set of services. A service declares to implement some interfaces and models a functionality which is usable by an application. The component may also contain an additional set of information, which is relevant in order to properly use the included functionalities (e.g., documentation, formal specification of behavior, metadata, etc.).
Fig. 1 – Home multimedia device network
Following the example of Figure 2b, Service1 has been created to implement InterfA, InterfB. InterfC. Application is unaware about how these interfaces have been implemented and who is providing the required functionalities. This approach opens to manage service functionality extension without any impact on the Application deployment. For example, Service1 which implements InterfX, could be extended in a second step to
implement InterfY (with a richer set of methods). The Service can be easily updated, while the Application does not need to change, since it may continue to use InterfX. In this way, old and new applications can survive in the same distributed system. In this context, it is very important to have a high dynamicity in the replacement/update of the components and in making them independent from the implementation and platform. In the following section, the achieved programming model is presented. It presents, as the most relevant feature, the decoupling from the application code and the service implementation.
3. Principles of the Middleware In this section, the main architecture of the component based middleware is presented. It is mainly based on the concepts and functionalities of the: • Component Model, defining the component package and how to access those implemented functionalities; The component model has been described in [8] and includes the: o manifest is a XML metadata section information including identifiers of the components, offered services, description of their interfaces, a list of dependencies for each services (for example, a service may depend on several other services for its correct execution), and all the relevant information needed by the system to manage the lifecycle of components and services. o executable code of the component. o documentation: human-readable compendium introduced since a component can be sold for integration or packaging purposes • RunTime Environment, realizing a support service for the middleware capable of managing the compliant components in order to provide actual means to access their services. In Figure 2c, a simple usage flow is sketched: where an application, located on a device is using Service1 which has been deployed and installed on a remote system. In Figure 2a, an overview of the concepts involved in the modeling of the component based framework and their relationships is given. The decoupling of the applications from the components is possible by performing an “a-priori” standardization of the services in terms of “logical entities”, that is to define them as abstract functionality providers, as a set of implemented interfaces. In order to access to service functionalities, the Application depends on the interfaces, which are wellknown for the service standardization. The service is identified by a unique name, (e.g., namespace and name). The Application needs also to use some support services in order to obtain access to component services. Those services, according to the object-oriented paradigm,
are realized as object constructor, while in this case are referred to as “service activation”. After the activation, a given instance is put in execution and maintained running by the runtime environment, and thus, it is ready to fulfill the application requests. Thus the general services for managing component services have to be exposed by the RunTime Environment of the middleware. The typical component-based Application starts with a
code and the service implementation, (ii) providing general services for managing services in a transparent manner, (iii) managing and propagating the exceptions. The proposed solution allowed solving the requirements mentioned in the above section. In fact, any application depends only on the IServiceBroker, which is the gateway to any component service, and provides a class ServiceManager which implements such an
a)
b)
Local System
Application
any Remote System
other Application other Application
RunTime
RunTime
Service2
Service1
c) Fig. 2 – Programming model concepts: a) Entity overview b) Component c) Sharing of available services
given service activation, that is performed “by name”. The name is known by the Application as a standardized service ID (e.g., audio.mp3.MP3Decoder). The request has to be performed by the Application to the RunTime which produces an object instance that has to be cast to one of the interfaces implemented by the obtained service instance. The RunTime has the duty of finding the service in the network, making transparent the activities for the Application. In this manner, the Applications can be totally unaware about which host is providing the implementation it is exploiting. Thus, Applications can control and exploits the whole network environment. The RunTime Environment has to support the component-model components and to avoid dependencies among (i) Application development languages, (ii) the Run Time Environment implementation and deployment, and (iii) the network topology and protocol. In addition, Applications must be capable of using the remote service instances as the local ones, even passing them as arguments for any other service method invocation.
3.1.
An overview of RunTime Environment
The main functionalities/aspects of the RunTime Environment can be discussed in terms of Figure 3, and are the possibilities of: (i) decoupling from the application
interface. In order to allow reusing/exploiting of the running services/components, the Proxy design pattern has been applied. This allowed the Applications to work with any object which implements all the know interfaces for the related service and redirect them to IServiceBroker generic requests for a service method execution. The component manifest contains a list of the eventual other services that are needed to be activated to complete the required invocation. Other metadata information may refer to the execution profiling (e.g., computational complexity), and/or platform resource usage. All these data are readable at run-time (but also at design-time), when decision could be taken about which component/host is more suitable to fulfill a given request. Therefore, each component is enriched with a set of data attributes which are retrieved and processed by the Run Time Environment during the component exploration for service selection and connection. In order to retrieve and use component services, the RunTime works with different framework management service/interfaces: • IServiceLocator to find a service by querying the underlying distributed environment; • IComponentExplorer to obtain information about a given component and its available services; any kind
•
•
of package attribute can be returned back as information accessible by all the system entities; IServiceActivator, responsible of using the component for instantiating a specific service; it returns a generic instance handle which identifies that instance for further requests; IServiceHandler to redirect a generic request to a specific invocation on the target service instance.
3.2.
Distributed architecture for services
This section depicts how a distributed system is deployed over the network sharing service functionalities. The same RunTime is capable to fulfill service activation and handling requests from other RunTime services. The RunTime actually covers two main roles in this distributed system: • Unique gateway for Applications to access to all network services; it is the sole dependency of a service consumer in order to access the distributed environment; • Peer for the service sharing network; it serves requests from other RunTimes as they were issued by any application.
Fig. 3 –Main entities and relations
Moreover, the solution proposed is capable of propagating the service execution exceptions which could occur through any level of calling stack, without breaking neither the RunTime nor the running application. The deployment of the components which provide new services (or service updates) has to be simple, according to the philosophy of .NET framework: just copying them to a given path. In this manner, also dynamic download of new components has been easily achieved. The RunTime is based on set of available services, and it works as a crucial service for the whole system: if the RunTime breaks, than all the services are not anymore available. Due to the dynamicity of the system the availability level of the components cannot be taken for granted. Thus, the service instance execution has to be monitored, and unexpected crashes should not stop the RunTime service in any case. Any error/exception has to be managed in order to maintain availability of the component service access functionalities. Furthermore, on the basis of the proposed delegation policy, also error information should be propagated at any system entity involved in the invocation process. With this report, many different high-level policies could take place in order to recover a service fault (e.g. instance replacement, service update).
Fig. 4 – Invoking a service method on a remote platform
In Figure 4, details regarding the delegation process of serving an invocation request are shown. In this case, an Application has obtained a stub for a service instance hosted by a remote RunTime. Please note that, the request is forwarded to the proper RunTime that finally performs the invocation on the active instance. The active service instances are located with a set of data which uniquely identify an active instance: unique ID of the instance, location i.e. the URL of the host platform (active RunTime), serviceName including its namespace. With this information any ServiceManager is capable of retrieving an active instance even if the first activation has not been commanded by it. In Figure 5, a sequence of object diagrams is showing how a service stub, in the hands of the application code, is used as argument of another service method invocation. In Figure 5a, the starting condition is sketched: the application has already activated the instances of Service1 and Service2; the invocation is performed through Service1Stub by using the usual “dot notation” and directly passing Service2Stub as it is (i.e. s1stub.do(s2stub)). In Figure 5b, the ServiceManager, while handling the invocation request, extracts from
Service2Stub data regarding the localization of related Service2 instance and delivers them to the RunTime. Service2Data is the delivered information, which the RunTime can use requesting a ServiceManager to build another stub for a Service2 instance. Thus, the method implementation can also neglect that the passed argument is actually a remote active service. In fact, in Figure 5c, the RunTime is responsible of forwarding the invocation to the proper Service1 instance, and performs the opposite operation with respect to what ServiceManager did in 5b; that is: it builds a new Service2Stub (by using a ServiceManager) from the received information Service2Data and passes this stub as the actual argument of method invocation on the Service1 instance. In Figure 5d, the Service1 instance has received the Service2Stub and it will use it transparently (it has been assigned to a local reference).
4.1.
The .NET Framework has been augmented with the above proposed functionalities allowing to create a more dynamic component-based middleware. The proposed implementation in .NET adds a pervasive fruition of services in a distributed environment, while .NET Remoting supports only one-to-one interactions. Components have been modeled as .NET Assemblies; they are organized at higher level for usage of their attributes. Attributes are presently used to describe exposed interfaces in terms of what has been specified by the service standardization. Also dependencies among services are reported as Assembly’s attributes. The proxy, that has been realized, decodes the invocation (method name and arguments) and subsequently forwards it to the ServiceManager. Since .NET support “emit” feature, which is the possibility of programmatically defining a new class, it has been decided to free the application deployment from any additional dependency with respect to the used interfaces of any service. Any service stub class is generated at runtime, reading the component service description and listing the interfaces known by the application (i.e., reachable by the Application component). In the .NET Framework, the concept of protected memory execution is defined as “application domain”. Such a domain is actually managed as an independent process, while it belongs to a unique operative system process. New threads can be created inside an application domain. Since memory is protected, the communications among the application domain have to exploit network or file communication. The “execution” application Domain, where RunTime is running, is responsible of creating as many application domains as the service instances are. The communication among RunTime and its active service instance is performed with .NET Remoting. This communication support is capable to notify if an exception occurred, so that another application domain could manage the situation. In this case, the service execution never risks the RunTime for failures.
4.2.
Fig. 5 – Passing a Stub as a method parameter
Please note that, this architecture enables a real transparency in term of reusing of the same application code that works for a local environment. Stubs are treated as logical references to the service instances, emulating in all aspects local references to such instances.
4. Some applications The solution proposed has been used for enforcing dynamicity in two different middleware: .NET of Microsoft and the MPEG M3W ISO standard.
Solution Usage in .NET
Solution Usage in MPEG M3W
The solution proposed has been also accepted by the MPEG M3W standardization activity, so the major results has been directly included in the standard edition ISO/IEC23004-3 (actually still under editing phase). Since the target platform, conceived for such standardization, is a Consumer Electronics device, many of the realization artifacts cannot be included in the defined services. MPEG M3W includes the so called “reference software” as a compendium for understanding the information handling as depicted in the standard body text. The M3W component model is based on native binary products. The proposed concepts have been standardized in two built-in component services provides building blocks for remote invocation. Proxy service has been defined as the virtualization of the real component service
on a remote platform and Wrapper service has been proposed in order to wrap any interface under a generic IReflection interface (i.e. by name invocation). DCE RPC has been used as the support communication protocol. The serialization technology has been left free in order to cope with different requirements. The standardization activity has done together with Philips and ETRI as contributors of the required technology.
4.3.
services and components in the standard. The solution provided is mainly based on the control and execution of services that in turn may instantiate and manage remote objects. Thus the communication among distributed objects is still possible but managed as in terms of independent services. Application IPrinterSettings IPrinter
An example
Among the validation tests, the following simple core experiment can be reported in the remaining document space. It has been performed on a local area network where some services have been deployed. The test has been set up on three platforms, equipped with RunTime service, with an application and two components: A component, with PrinterService implementation, is deployed on platform 2 and another, with LoggerService implementation, is deployed on platform 3. The Application code is responsible of activating and using the required services. The sequence of the implementation instructions can be resumed as: • gathering of the ServiceManger instance; • activation (via ServiceManager) of a PrinterService instance; • activation of a LoggerService instance; • use of PrinterService instance as IPrinterSettings to specify a new text colour (setColor(Color)); • use of PrinterService to print colored text (print(coloredtext));; • use PrinterService as IPrinter to print a text while logging this operation (print(string, myLogger)), passing LoggerService instance as second argument; • release of active service instance by releasing local stubs (release()) All the service instances are activated and managed on their platforms. Furthermore, the PrinterService instance has been a service consumer for the LoggerService, actually using another stub for the unique active instance. In Figure 7, the object diagram presents a snapshot of the three platforms status, before releasing.
5. Conclusions The recent trend has led to the production of specific middlewares for industrial automation, home automation, multimedia, etc. In this paper, a solution to enforce in those middlewares a higher dynamism, in terms of the dynamic management, allocation and connection of remote service, deploying and updating of such components during the application lifetime, is presented. The solution has been developed on the basis of the requirements coming from MPEG M3W ISO standardization effort and to satisfy the needs of AXMEDIS IST FP6 Research & Development of the European Commission [4]. Thus, it has been accepted as valid contribution in the MPEG M3W for the definition of a component model which allows remote utilization of
ILogger
PrinterServiceSTUB
LoggerServiceSTUB LoggerService
ILogger
ServiceManager
RunTime
RunTime
platform 1 platform 3
RunTime
platform 2 IPrinterSettings
PrinterService
IPrinter
LoggerServiceSTUB
ServiceManager
ILogger
Fig. 7 – Example: platform status
6. Acknowledgements The authors would like to thank to all MPEG M3W contributors and the AXMEDIS project partners including the Expert User Group and all affiliated members, for their contributions, funding and collaborations. A specific acknowledgment to EC DG INFSO for the partial funding.
7. References [1]
CORBA Component Model 3.0, June 2002
[2]
R. Baler, C. Gran, A. Scheller, A. Zisowsky, “Multimedia Middleware for the Future Home”. Proc. of the 2001 int. workshop on Multimedia middleware, Oct. 2001, Ottawa, Ontario, Canada
[3]
ISO/IEC JTC1/SC29/WG11 N6835 “MPEG Multimedia Middleware: Requirements on the MPEG Multimedia Middleware V2.0”, Oct. 2004.
[4]
Crnkovic and M. Larsson. “Building Reliable ComponentBased Software Systems”. Artech House Publishers, 2002.
[5]
J. Muskens and M. Chaudron. “Integrity management in component based systems”. In Proc. of the 30th EUROMICRO conf., Rennes France, Aug. 2004.
[6]
K. Sandstrom, J. Fredriksson, and M. Akerholm. “Introducing a component technology for safety critical embedded real-time systems”. In 7th ICSE Workshop on Component-Based Software Engineering, May 2004.
[7]
AXMEDIS: www.axmedis.org
[8]
T. Martini, P. Nesi, D. Rogai, A. Vallotti, "A Component based Multimedia Middleware for Content Production Factory", 11th Int. Conf. on Distributed Multimedia Systems, DMS 2005, Banff Springs Hotel, Banff, Canada, Sept. 2005
