Architectural Translucency in Service-oriented Architectures

Architectural Translucency in Service-oriented Architectures Vladimir Stantchev and Miroslaw Malek Institut f¨ ur Informatik, Humboldt University of Berlin Unter den Linden 6, 10099 Berlin, Germany Phone: +49 30 2093 3030, Fax: +49 30 2093 3029 {vstantch|malek}@informatik.hu-berlin.de

Abstract. In this paper we describe a concept of architectural translucency and its applicability in service-oriented architectures (SOA). We first look at the development of distributed computing from RPC, through middleware, component frameworks to service-oriented architectures and their level of support for non-functional properties such as availability, dependability, mobility and adaptivity. Then, we present the concept of architectural translucency – the ability to best influence certain nonfunctional property by identifying and controlling parameters of the architecture in a cross-layered way. Thus, improvement of mobility, dependability, or security aspects can be addressed at the layer that will bring the best optimization of these aspects. The evaluation insofar we can support it in SOA starts with the definition of non-functional properties where translucency is achievable throughout the architecture. Furthermore, we present a prototype implementation for translucent SOA based on a model that can be evaluated analytically and/or by simulation. We have evaluated the prototype implementations for J2EE and for embedded devices using factorial design and present important results. Finally, we assess our progress so far and outline the future work. Keywords: services, dependability, translucency, components, responsiveness

2

1

Introduction

Current research in the area of systems architecture properties focuses on issues such as performance, availability, dependability, mobility and security. These objectives are often regarded in the context of certain architectural level, e.g., network throughput, fault tolerance of a machine, security of an operating system, mobility of a device or of a business process. Applying a system-wide view to monitoring and control of such properties is a difficult and costly endeavor. Due to the different technologies involved at every layer of the system there are no universally applicable approaches to handle these properties throughout an architecture. Modern middleware and operating systems provide a certain level of configuration of non-functional properties, such as transactions and security. There are also possibilities to configure Quality-of-Service (QoS) parameters for different networking protocols. Another important development is the emergence of service-based environments such as Web services as an approach for tackling the complexity of distributed computing. As shown on Figure 1 service-oriented architectures are not something fundamentally new, but are rather an evolutionary step. A service-oriented architecture (SOA) offers native capabilities, such as publication, discovery, selection and binding. Since services are basic building blocks for creation of new applications, service composition is introduced on top of native capabilities. It governs the way applications are developed from basic services.

3

SOA environments are often based on component frameworks such as J2EE and .NET that require higher administrative effort compared to the traditional client-server approach and therefore need a rich supporting infrastructure. They offer infrastructural support for enhancing the WSDL contract every Web service provides with important non-functional properties, specified in horizontal protocols such as Business Process Execution Language (BPEL) [1], WS-Coordination [2], WS-Transaction [3] and Enterprise Service Bus [4]. The ultimate goal of such efforts is to introduce automated composition/decomposition services in the Web services environment ultimately changing the existing application development paradigms. An introduction of a translucency concept may have a big impact in the world of service-oriented computing (SOC) [5], because one way to incorporate translucency would be to provide a highly configurable architecture with respect to non-functional properties.

2

Related Work

Architectural research in the area of distributed computing focused very early on the topics of real-time capabilities, fault tolerance and security. These non-functional properties of an architecture are often grouped under the ”umbrella” term of dependability. Research in the area of real-time capable architectures is applied in embedded systems, such as specialized robots, automation control mechanisms and other time-critical applications. There are approaches that evaluate such systems as platforms for light-weight services [6, 7]. These approaches benefit from the better abil-

4

ity of a small embedded system to respond to an event or an input in a timely manner, keeping predefined deadlines. This ability deteriorates with the growing complexity of the architecture. Fault tolerance is typically achieved through redundancy - there is a backup system or a service that replaces the failed one. There is a variety of approaches to redundancy - keeping duplicate services running in parallel, having duplicate services available and start them when a failure occurs, transition of tasks of the failed node to nodes, that currently run other tasks [8]. An important precondition for fault tolerance is the correct identification of faults. This is particularly difficult to achieve in a distributed computing system where the system nodes must have a coherent view of what constitutes a faulty behavior. Approaches here include leader election [9], consensus protocols [10], depth-first and breadth-first searches [11]. The substitution of a failed system node with a new one presumes that the latter should somehow be initialized with the state information of the former at the time just before the failure occurs. Preserving state information in distributed systems is often achieved again through consensus protocols [10] or similar replication techniques. There are two important prerequisites for a secure system – authentication and authorization. Based on them the system can define access rights to the services it offers. Furthermore, the system integrity should be maintained by preventing tampering at different system levels – e.g., network sniffing of sensitive data, compromising a system using buffer overflows or other vulnerabilities of the operating system, and presenting malicious code as a harmless application. The existing initiatives to de-

5

velop dependable computing architectures – e.g., Autonomic Computing initiative at IBM [12] and Trustworthy Computing at Microsoft [13] try to engage the research community and both companies to develop solutions for self-management and enhanced dependability. They also attempt to integrate hardware and software related aspects into an overall architectural concept for control of non-functional properties. Several extensions in the area of Web services aim to introduce coordination protocols. On the one side are vertical protocols, specific to a given industry sector, such as ebXML [14], xCBL [15] and RosettaNet [16]. These protocols do not include a standardization of all low level details - they focus on the semantic of the exchanges and the set of correct conversations. Therefore, they rely on the infrastructure of the horizontal protocols. Horizontal (middleware) protocols are expected to provide Web services with properties similar to those of conventional middleware. They offer a common infrastructure for all application areas and allow inter-service communication with higher-level abstractions, very much resembling the developments in conventional middleware. They also address properties like reliability and service management functionality. Two important examples of horizontal protocols are Web Services Coordination [2] and Web Services Transaction [3]. WS-Coordination is used to coordinate the actions of Web services, when a consistent agreement has to be reached on the outcome of service activities. It enables creation of a shared context that can propagate from service to service. WS-Transactions is used to define transactional behavior of Web services. It allows for atomic transactions (short-running) or business transactions (long-running).

6

Extensive research concerning non-functional properties exists in the field of CORBA, particularly in the areas of real-time support [17, 18], replication as approach for dependability [19–22], adaptivity and reflection [23, 24], as well as mobility [25, 26]. Of particular relevance to architectural translucency are the concepts of reflective middleware. An application for optimisation of QoS aspects in CORBA is presented in [27]. There are various efforts to address non-functional properties in distributed computing environments. Under the term performability, originally introduced in [28] there are works in the area of resource control [29] and addressing fault-tolerance at system level (e.g., hardware platform and OS) and application level [30]. We envision architectural translucency as more general approach – while CORBA-related research focuses on certain level of distributed computing architecture (middleware), and performability deals mainly with fault tolerance and how to address it cumulatively at the system and application level, we present an approach for controlling different non-functional properties (e.g., mobility, adaptivity and dependability) throughout an architecture. In this paper we focus on the specifics of applying architectural translucency to service-oriented architectures.

3

Problem Statement

Modern system architectures span multiple layers ranging from hardware platforms and communication interfaces to small services that reside on

7

the top of it. Every layer has specific properties and qualities. We define architectural translucency as the ability to monitor and control nonfunctional system properties architecture-wide in cross-layered way. We have identified two important prerequisites to this approach – a quantitative one and a structural one. In order to measure factorial influence on non-functional properties we need to quantify these properties in a coherent way. Therefore, we presented quantification approaches for nonfunctional properties in [31]. A structural precondition describes the definition of architectural layers or levels. In SOA we have identified following system levels – hardware and communication platforms, serviceware framework and applications composed from services [5]. With this preconditions addressed we can focus on the key issues of translucency – to identify major factors that influence non-functional properties at different system levels and to measure their importance when applied at certain level. A serviceware framework abstracts application components and services from the underlying specifics of hardware platform and operating system. Therefore, having support for translucency at that level is key to the ultimate goal of overall architectural translucency. Various properties may require support at various number of layers, e.g., dependability may need support at all layers, while security support at the top level can be sufficient. There are several prerequisites for translucency-supporting serviceware framework. First, we need to define which properties can be con-

8

trolled and monitored translucently through it. The decision which properties to include in such definition is influenced on one side by the overall requirements we impose on the system, e.g., we want to be able to control real-time behavior. On the other side, we must consider whether a property we view as worth being controlled or monitored translucently is achievable in a loosely-coupled distributed computing environment such as SOA. Having identified the properties that meet these requirements, we have to evaluate whether and how far existing SOA environments support them and whether there are properties that are impossible to control and measure due to limitations in these environments. Furthermore, we need a model of SOA that allows us to analytically evaluate the expected architectural behavior incorporating configuration and parameter information from the underlying layers, e.g., hardware, operating system and networking. We should also be able to simulate this behavior to see whether the analytical evaluation holds. In order to have real test results we need implementations of the needed extensions for at least two SOA environments.

4

Relevant System Properties

We want to influence non-functional properties of a distributed computing architecture. Support for dependability is expected to include support for real-time capabilities, fault tolerance and security. Furthermore, we regard mobility and adaptivity as prerequisites of a distributed system for ubiquitous [32], pervasive [33] or subdued computing [34]. Other properties that may be worth controlling include memory footprint, CPU usage,

9

overall system performance and power consumption. These parameters can provide empirical data related to the control of mobility, adaptivity and dependability.

Properties Achievable in Distributed Computing Architectures. Distributed computing architectures span multiple nodes that are interconnected with each other and often employ some kind of middleware (e.e., CORBA, COM+, .NET Remoting, Java RMI) to facilitate internode communication. Such environments are typically not capable of providing hard real-time support – the communication flow between the nodes can hardly be predicted exactly to meet hard timing requirements. Introducing mobile or ad-hoc communication within the system adds further uncertainty. But, as [8] demonstrated, it is possible to achieve responsiveness in a distributed application where the nodes are interconnected via Ethernet. Furthermore, here the nodes were based on processor architecture and operating system that do not have real-time capabilities a-priori.

Properties Achievable in a Service-oriented Architecture for Light-weight Services. We expect a SOA for light-weight services to be deployed on small embedded devices with lesser complex infrastructural requirements compared to SOA based on component frameworks such as .NET and J2EE. The level of support of non-functional properties can be higher with respect to hard real-time requirements. Furthermore, the abilities to compromise such a platform are limited, as it does not offer the same amount of accessible services as a complex system.

10

On the other side, an embedded system may lack functionality to support complex service hosting including support for distributed transactions, cross-service authentication and complex composition.

Properties Achievable in a Service-oriented Architecture Based on Component Frameworks. Although component frameworks offer good support for the development of distributed applications, their introduction in a distributed architecture leads to higher complexity. This is especially true with respect to dependability, mobility and adaptivity. As argued in [35] a performance evaluation of a component is not feasible without performance evaluation of the middleware environment that hosts the component. Nevertheless, as proved in [17] it is possible to achieve responsiveness in CORBA-based architectures. So, while we cannot have hard real-time guarantees in component-based architectures, we are able to fulfill responsiveness requirements. When extending real time to responsiveness, the notion of fault tolerance is added [36].

5

Model for Translucent Service-oriented Architectures

Our formal architectural model is based on modular Petri Nets [37]. We use the hierarchical extensions presented in [38] as well as timing extensions [39]. We employ a workflow approach similar to [40]. In order to adapt the model to a SOA we assign every task within a workflow to a service. The overall behavior of the workflow execution depends on the behavior of the services involved. Every service is a top hierarchy module which contains several modules. They model the layers the service is built

11

from, e.g., network, platform, middleware and actual service application (see Figure 2). This formal model is applicable to SOA based on small embedded devices, as well as to SOA based on component frameworks such as COM+/.NET and J2EE. A detailed description of the model, together with an evaluation of applicable modeling techniques is given in [31]. Environments such as COM+/.NET and J2EE provide application level components with a variety of services they require in order to operate in a distributed system. This support greatly exceeds the infrastructure available on an embedded device. Canonical examples of such services include object location, security, transaction management, integration services, database connection pooling, and component lifetime management – initialization, start/restart and disposal. Application level components and derived services do not need to take care of these tasks themselves, and are therefore able to concentrate on application logic. They are hosted in run-time environments that provide these services to them. Components can request specific levels of service from a container (e.g., transaction, security, encryption) declaratively, as they are configured. Within such an environment non-functional properties of an application level components and services depend heavily on the infrastructure of the framework components and these properties cannot hold outside the hosting environment. Furthermore, an application level component can only run in a suitable middleware environment. So providing non-functional properties in a distributed component-based system should primarily focus on the middleware infrastructure.On the other

12

side there are many ways in which components running in one environment can interact and use features of another component environment, as demonstrated for Java components and the .NET Framework in [41]. On small embedded devices we are faced with a platform with lesser complexity but limited capabilities as compared to middleware platforms. Here the non-functional properties for the services have to be provided. In the area of dependability we can make use of the real-time capabilities of the platform. On the other side, we have to take care of security, life-time management and transaction support from within a device. Our methodology is based on an approach shown in Figure 3. Here we focus on dependability as non-functional property of a service-oriented architecture. Starting from general dependability models and test cases for a generic dependability profile we incorporate configuration information at the level of hardware, operating system and middleware. A profile in this context is a a general non-functional requirement on the whole system – e.g., the system has to be able to meet certain response deadlines, availability and fault-tolerance requirements.This dependability profile can then be further refined for a service based on the derived architecture-specific model. This model incorporates information about the hardware configuration and parameters (e.g., available RAM, number of processors, type and speed of processors, type and speed of network connection. Furthermore, type, parameters and configuration information about the operating system and about the serviceware framework are evaluated to create their specific profiles. These three profiles (hardware, operating system

13

and framework) are combined into the architecture-specific profile. It is then extended according to the configuration settings of the service and of the application or composed service it is part of. Our model for dependability implementation in a SOA is shown on Figure 4. Every service is hosted in a service container. Incoming service requests are received through a set of open connections C1 to Ck . They are then forwarded to the request spooler. The spooler has access to the configuration data of the service concerning non-functional properties and to its status. It evaluates the settings Gf t (grade of fault tolerance), Tmax (maximal tolerable response time), Trans (transaction support) and ACL (Acess Control Lists). Furthermore, it has access to performance monitor data provided from the service container. Depending on these values it transfers the request to the active service or notifies the translucency manager to provide a replica for the servicing of the request.

6

Case Studies

In order to show the general applicability of the concept we decided to create two implementations – for SOA based on small embedded devices, on the one hand, and for SOA based on component frameworks. We decided to use standard-based, widely used platforms, namely J2EE and .NET for our case study in the area of component frameworks. In the area of small embedded devices we chose Windows CE powered devices based on Intel XScale. Our choices were based on the following considerations: – These platforms are already mature with already settled architectural groundwork.

14

– There is strong industry support for them and there exist a lot of tools and related research projects, that can be useful for our implementation. – Beside component support J2EE and .NET are capable of offering component functionality as Web services, which could extend the areas of application of our approach significantly. – There is existing know-how in our group, related to architectural improvements and design of distributed systems based on these frameworks.

J2EE Case Study There are several important concepts in the J2EE specification we need to keep in mind when developing a dependability framework for this environment. Central to the specification is the Enterprise Java Beans (EJB) Framework. An EJB is the component unit here that incorporates the application logic. A distributed application consists of EJBs residing on different machines that are interconnected throughout the J2EE environment. In order to execute an EJB we need to place it in an EJB container. This container provides services such as security, transactions and object persistence to the component. A component is configured to declare its requirements concerning these services. The configuration information is stored in XML-based component-specific deployment descriptor file. Furthermore, the EJB container manages the concurrent execution of multiple components and takes care of threading and resource locks. The EJB framework provides an extensive security infrastructure. In order to provide dependability here we need to im-

15

plement mechanisms for responsiveness bringing together fault tolerance and real-time capabilities [36] as far as they can be achieved within the environment. Our J2EE implementation is based on the JBOSS Application Server 4.0 [42] – an Open Source implementation of the J2EE standard. It includes a configuration client that allows the declarative specification of required non-functional properties. Furthermore, it provides a dependability extension to the EJB implementation of JBOSS.

Embedded Case Study The Intel XScale architecture is based on an ARM-based RISC core which clocks up to 533MHz with 64k of cache. It offers high degree of component integration which includes an on-chip SDRAM controller, 2 high-speed serial ports, 2 10/100Mbit Ethernet ports, UTOPIA interface for ATM / xDSL, PCI bus, host USB, and even an encryption accelerator. The Windows CE platform [43] is focused on providing real time processing capabilities, while offering comprehensive development tool and networking support and Win32 compatibility. Its small memory footprint, modular approach and processor portability make it a possible choice for a variety of embedded devices (e.g., PDAs, ATMs and consumer electronics). Its real time support includes nested interrupts and the possibility of zero length thread quantum. The current version – Windows CE 5.0 offers a subset of the Win32 APIs and the .NET Compact Framework. The .NET Compact Framework is a subset of the .NET Framework and does not include support for hosting web

16

services on the mobile device, although it is capable of hosting COM+ and .NET components.

Evaluation We tested our J2EE prototype with a distributed e-commerce application described in [44]. The structure of the application is shown on Figure 5. In the test setup we set the grade of fault tolerance Gf t and the maximal tolerable response time Tmax for several services. For our J2EE tests we configured several services within the payment processing workflow as described in Figure 6. While services such as Payment Transaction Start, Payment Input and Payment Confirmation can be set up to meet short response time requirements, services like Input Validation and especially Payment Validation and Payment Processing are complex, distributed and support transactions. Therefore their response time is substantially longer. Results from the basic tests that are shown in Figure 7 show the general applicability of the approach to control service dependability. To further evaluate system behavior we have developed a 2k factorial design setup. The two primary factors we introduce are: Ncu (number of concurrent users) and Am (amount of available RAM). Each of them can assume three levels, so we have 9 different experiments (see Figure 8. The response variable is maximal tolerable response time Tmax . We have done 5 replications (for each combination of factor levels we conducted five consecutive tests).

17

Results from the factorial design setup are shown in Figure 9. As our response variable is a threshold (we need to ensure that we do not miss the deadline), only the highest level of Tmax measured during the replications of each experiment is given. While we measured Tmax for every service within the workflow, here we present the values for the payment validation service as a representative average. The values for the other services were similar and will be presented in future publications focused specifically on the test design setup. All values for Tmax that we measured were within the configuration setting of 400 ms. This constraint was met with different user loads and different amount of RAM on the system. While we are currently evaluating the variation caused by the two factors for our cross-layered evaluation of translucency (the first factor is an application level factor, while the second one is a platform-level factor), for the purpose of this paper we needed data measured for the same setup without activating our serviceware-level translucency implementation. Results from these tests (again on the example of payment validation service) are shown in Figure 10. The results show that the distributed e-commerce application by itself has a rather random timing behavior with Tmax values ranging from 422.89 ms to 887.34 ms. The introduction of our prototype leads to a more predictable timing behavior with values ranging from 276.16 ms to 389.5 ms. More important, the prototype ensures that the deadline of 400 ms we set is met in every single case, even in the presence of faults at the service level.

18

We conducted tests of our embedded prototype within the broader evaluation of a distributed robotic system described in [45]. Results here were similar and, due to the embedded environment, we were able to enforce shorter deadlines (150 ms).

7

Conclusion and Outlook

The test results demonstrate that our dependability extension is capable of keeping the requirements as specified in the configuration. We use configuration data and parameters of the hardware, the operating system and the serviceware framework (J2EE and .NET) to help meet these requirements. This combined approach addresses dependability as a property of the overall architecture by evaluating parameters at these levels. While this is a first step toward translucent architecture, we still need to provide dynamic evaluation of alternatives (e.g., double RAM amount or faster processor) to present targeted configurations (e.g., a configuration with focus on security, a configuration with focus on fast response times, a configuration with focus on fault tolerance). We envision architectural translucency as a concept particularly well suited for monitoring and control of non-functional properties in distributed computing architectures. Having translucent support for properties such as availability, dependability, mobility and adaptivity enables the configuration of these properties for the overall architecture. Using this approach changes are inflicted at the architectural level that will bring the highest gain, or at several levels simultaneously if this is required. In this paper we introduced the incorporation of translucency support at

19

the serviceware level in service-oriented architectures. Having these first prototypes provides for a testing platform with different kinds of applications. The experimental results will help us to evaluate the correctness of the approach and the implementation. Our future work will focus on the refinement of the abstract model that incorporates the concept of translucent service-oriented architectures presented here. For the construction of an empirical model we will evaluate the importance of similar parameters at different levels (e.g., replication at the platform, OS, serviceware or service level).

8

Figures

SOA Web Services – SOAP, WSDL, UDDI Document Exchange: BizTalk Service Coordination – WS-Coordination, WS-Transactions Service Composition – BPEL, CDL Non-functional properties: fault tolerance, security, timeliness EAI Middleware for EAI Message Brokers Workflow Management Systems Time

Middleware RPC TP Monitors Object Brokers (CORBA) Message oriented middleware Distributed Information Systems From One-tier to N-tier Architectures

Fig. 1. Development of Distributed Computing Architectures

20

l1

l1

l1

l1 l1

Service 2 l1

l1 l1

Service 1

l1

l1

l1

l1

Service 3

Fig. 2. SOA Model based on hierarchical modular timed Petri Nets

Generic dependability models

Test Cases

Dependability Profile

Hardware Configuration

Hardware Profile Framework Operating System Profile Profile Architecture-specific Profile

Framework Configuration

Component Configuration

OS Configuration Service Profile

Application Configuration

Fig. 3. Methodology for Dependability Profiles

21

Serviceware Framework Translucency Manager

Configuration Data Gft , Tmax, Trans, ACL

Incoming Connections ’

Ȝi,j,1

Service Container C1 ’

Request Spooler

Ȝi,j,k

Ȝi,j,k

Ck Active Replication Service Coordinator ’

’

State Information Exchange Replicated Services

Ck R1

Ck Rn

Fig. 4. Model for Translucency Implementation in a Service-oriented Architecture

22

Bluetooth

IR

RF ID

…

GPRS

WLAN

HSCSD

…

Client for Application Development (Modeling and Logic)

Switching layer

(switching between mobile/wireless technologies)

Pipeline- Manager

(extendable via modules for new devices and technologies)

Generic Application (layer)

(Storage of existing, derived, or developed generic business processes)

Database layer (Generic connection to different DBM without additional programming)

Fig. 5. Architecture of the J2EE Test Application

Service: Gf t : Payment Transaction Start 4 Payment Input 4 Input Validation 4 Payment Validation 4 Payment Processing 4 Payment Confirmation 4

Tmax : 10 ms 8 ms 40 ms 400 ms 200 ms 20 ms

Fig. 6. Service Settings for Testing the J2EE Prototype

23

Service: Crashes: Tmin : Payment Transaction Start 2 6.832 ms Payment Input 1 4.86 ms Input Validation 0 9.54 ms Payment Validation Payment Processing Payment Confirmation

3 2 2

Tmax : 9.433 ms 8.02 ms 36.383 ms

Tavg : 8.1325 ms 6.44 ms 22.9615 ms 105.12 ms 329.06 ms 217.09 ms 104.7 ms 162.8 ms 133.75 ms 6.14 ms 12.44 ms 9.29 ms

Fig. 7. Basic Test Results for J2EE Prototype Exp. No.: Level of Factor Level of Factor Ncu Am 1 5 512 MB 2 50 512 MB 3 150 512 MB 4 5 1024 MB 5 50 1024 MB 6 150 1024 MB 7 5 2048 MB 8 50 2048 MB 9 150 2048 MB Fig. 8. Combination of Factor Levels for the Factorial Design Setup Exp. No.: 1 2 3 4 5 6 7 8 9

Values for Tmax 332.02 ms 347.74 ms 389.5 ms 301.44 ms 327.12 ms 340.1 ms 276.16 ms 293.9 ms 312.4 ms

Fig. 9. Values for the Response Variable Tmax of the J2EE Prototype Test

24

Exp. No.: 1 2 3 4 5 6 7 8 9

Values for Tmax 512.18 ms 674.05 ms 887.34 ms 468.07 ms 521.26 ms 693.78 ms 422.89 ms 489.64 ms 554.03 ms

Fig. 10. Values for the Response Variable Tmax of the J2EE E-Commerce Application without Activated Translucency Implementation

References

1. BEA Systems, IBM Corporation, Microsoft Corporation, SAP AG, and Siebel Systems.

Business process execution language for web services.

http://www.ibm.com/developerworks/library/ws-bpel/, 2004. 2. BEA Systems, IBM Corporation, and Microsoft Corporation. Web services coordination (ws-coordination). http://www-106.ibm.com/developerworks/library/wscoor/, 2004. 3. BEA Systems, IBM Corporation, and Microsoft Corporation. Web services transaction (ws-transaction).

http://www-106.ibm.com/developerworks/library/ws-

transpec/, 2004. 4. D. Chappel. Enterprise Service Bus. O’Reilly, 2004. 5. V. Stantchev and M. Scherz. Challenges of Service-Oriented Architectures. In Proceedings of IPSI2004, Venice, Italy, 2004. 6. M. Werner, J. Richling, N. Milanovic, and V. Stantchev. Applying Composability to Dependable Embedded Systems. In Proceedings of the International Workshop on Dependable Embedded Systems at the 22nd Symposium on Reliable Distributed Systems (SRDS 2003), Florence, Italy, 2003.

25 7. N. Milanovic, J. Richling, and M. Malek. Lightweight Services for Embedded Systems. In Proceedings of 2nd IEEE Workshop on Software Technologies for Embedded and Ubiquitous Computing Systems), Vienna, Austria, 2004. 8. M. Werner, A. Polze, and M. Malek. The Unstoppable Orchestra: A Responsive Distributed Application. In Proceedings of the 3rd International Conference on Configurable Distributed Systems (ICCDS’96), pages 154–160, 1996. 9. Shing-Tsaan Huang. Leader election in uniform rings. ACM Trans. Program. Lang. Syst., 15(3):563–573, 1993. 10. M. Malek. Omniscience, Consensus, Autonomy: Three Tempting Roads to Responsiveness. In Proceedings 14th Symposium on Reliable Distributed Systems, Bad Neuenahr, Germany, September 1995. Humboldt University of Berlin. 11. Chong Jye Rhee, Y. Daniel Liang, Sudarshan K. Dhall, and S. Lakshmivarahan. Efficient algorithms for finding depth-first and breadth-first search trees in permutation graphs. Inf. Process. Lett., 49(1):45–50, 1994. 12. IBM

Autonomic

Corporation.

Computing

-

Research

Focus.

http://www.research.ibm.com/autonomic/research/, 2004. 13. Microsoft

Trustworthy

Corporation.

Computing.

http://www.microsoft.com/mscorp/twc/, 2004. 14. ebXML.org.

ebXML-Enabling

a

Global

Electronic

Market.

http://www.ebxml.org/geninfo.htm, 2001. 15. Commerce One Inc. XML Common Business Library. http://www.xcbl.org, 2001. 16. P.

Yenduri.

RosettaNet

Implementation

Framework

(RNIF)

2.0.

http://xml.coverpages.org/RNIF-Spec020000.pdf, 2000. 17. A. Polze and L. Sha. Composite Objects: Real-Time Programming with CORBA. In Proceedings of 24th Euromicro Conference, Network Computing Workshop, Vol.II, pp.: 997-1004, Vaesteras, Sweden, August 1998. Humboldt University of Berlin. 18. W. Feng. Dynamic client-side scheduling in a real-time corba system. In COMPSAC, pages 332–333. IEEE Computer Society, 1999. 19. Pascal Felber, Rachid Guerraoui, and Andr´e Schiper. Replication of corba objects. In Sacha Krakowiak and Santosh K. Shrivastava, editors, Advances in Dis-

26 tributed Systems, volume 1752 of Lecture Notes in Computer Science, pages 254– 276. Springer, 1999. 20. V. Marangozova and D. Hagimont. An infrastructure for corba component replication. In Judith M. Bishop, editor, Component Deployment, volume 2370 of Lecture Notes in Computer Science, pages 222–232. Springer, 2002. 21. M. Werner. Replikation in CORE, Oct 1996. 22. Pascal Felber and Priya Narasimhan. Reconciling replication and transactions for the end-to-end reliability of corba applications. In Meersman and Tari [46], pages 737–754. 23. Pierre-Charles David and Thomas Ledoux. An infrastructure for adaptable middleware. In Meersman and Tari [46], pages 773–790. 24. Sebastian Gutierrez-Nolasco and Nalini Venkatasubramanian. A reflective middleware framework for communication in dynamic environments. In Meersman and Tari [46], pages 791–808. 25. Gregory Biegel, Vinny Cahill, and Mads Haahr. A dynamic proxy based architecture to support distributed java objects in a mobile environment. In Meersman and Tari [46], pages 809–826. 26. Sandeep Adwankar. Mobile corba. In DOA, pages 52–, 2001. 27. Nanbor Wang, Kirthika Parameswaran, Michael Kircher, and Douglas C. Schmidt. Applying reflective middleware techniques to optimize a qos-enabled corba component model implementation. In COMPSAC, pages 492–. IEEE Computer Society, 2000. 28. C.M.Krishna and Kang.G.Shin. Real-Time Systems. The McGraw-Hill Companies, Inc, New York, 1997. 29. Kang G. Shin, C. M. Krishna, and Yann-Hang Lee. Optimal dynamic control of resources in a distributed system. IEEE Trans. Softw. Eng., 15(10):1188–1198, 1989. 30. Joshua Haines, Vijay Lakamraju, Israel Koren, and C. Mani Krishna. Applicationlevel fault tolerance as a complement to system-level fault tolerance. The Journal of Supercomputing, 16(1-2):53–68, 2000.

27 31. V. Stantchev and M. Malek. Modeling Translucent Architectures. In S. Aier and M. Sch¨ onherr, editors, Enterprise Architecture - Volume III, Berlin, Germany, 2005. Gito Verlag. 32. N. Stanton. Ubiquitous Computing: Anytime, Anyplace, Anywhere? Lawrence Erlbaum Associates, 2001. 33. M. McCullough. Digital Ground: Architecture, Pervasive Computing, and Environmental Knowing . MIT Press, 2004. 34. M. Malek. Introduction to nomads. In Computing Frontiers 2004, Ischia, Italy, April 2004. 35. S. Chen, I. Gorton, A. Liu, and Y. Liu.

Performance Prediction of COTS

Component-based Enterprise Applications. In Proceedings of the 5th ICSE Workshop on Component-based Software Engineering (CBSE5) Benchmarks for Predicable Assembly, in conjunction with ICSE2002, Orlando Florida, USA, 2002. 36. M. Malek. Responsive Systems: A Marriage between Real Time and Fault Tolerance. In M. Dal Cin W. Hohl, editor, Fault-Tolerant Computing Systems, pages 1–17. Springer-Verlag, September 1991. 37. S. Christensen and L. Petrucci. Modular analysis of petri nets. Computer Journal, 43(3):224–242, 2000. 38. M. M¨ akel¨ a. Model checking safety properties in modular high-level nets. In Proceedings of the 24th International Conference on Applications and Theory of Petri Nets (ICATPN 2003), pages 201–220, Eindhoven, The Nederlands, June 2003. 39. F. D. J. Bowden. A brief survey and synthesis of the roles of time in petri nets. Mathematical and Computer Modelling, 31(10-12):55–68, 2000. 40. K. Knorr and H. Weidner. Analyzing separation of duties in petri net workflows. In LNCS 2052: Information Assurance in Computer Networks - Methods, Models, and Architectures for Network Security — International Workshop MMM-ACNS 2001, St. Petersburg, Russia, May 21-23, 2001 / V.I. Gorodetski, V.A. Skormin, L.J. Popyack (Eds.), pages 102–pp. Springer Verlag, 2001. 41. J. Bishop, R. Horspool, and B. Worrall. Experience in integrating java with c# and .net. Concurrency and Computation: Practice and Experience, 17(5-6):663– 680, April-May 2005.

28 42. JBoss. Jboss. http://www.jboss.org, 2004. 43. J. Murray. Inside Windows CE. Microsoft Press, 1998. 44. V. Stantchev and M. Scherz. Net Business Environment for Small and Mediumsized Enterprises.

In Proceedings of the IADIS International Conference e-

Commerce 2004, Lisbon, Portugal, 2004. 45. P.K. Ibach, N. Milanovic, J. Richling, V. Stantchev, A. Wiesner, and M. Malek. CERO: CE RObots Community. In IEE Proceedings - Software, special issue on Embedded Systems (to appear), 2005. 46. Robert Meersman and Zahir Tari, editors. On the Move to Meaningful Internet Systems, 2002 - DOA/CoopIS/ODBASE 2002 Confederated International Conferences DOA, CoopIS and ODBASE 2002 Irvine, California, USA, October 30 November 1, 2002, Proceedings, volume 2519 of Lecture Notes in Computer Science. Springer, 2002.