Lambertus Johannes Maria Nieuwenhuis

Transparent dynamic reconfiguration for CORBA

Distributed systems with high availability requirements have to support some form of dynamic reconfiguration. This means that they must provide the ability to be maintained or upgraded without being taken off-line. Building a distributed system that allows dynamic reconfiguration is very intrusive to the overall design of the system, and generally requires special skills from both the client and server side application developers. There is an opportunity to provide support for dynamic reconfiguration at the object middleware level of distributed systems, and create a dynamic reconfiguration transparency to application developers. We propose a Dynamic Reconfiguration Service for CORBA that allows the reconfiguration of a running system with maximum transparency for both client and server side developers. We describe the architecture, a prototype implementation, and some preliminary test results.

Mapping the business model canvas to ArchiMate

Many IT projects fail to succeed in the market, as they start purely from technology. Much effort is therefore wasted, while the potential benefits are not realized. We argue that the design process should start with creating a business model, which is then translated to an architecture to ensure fitness for market of the future system. Therefore, we propose a mapping from Osterwalders business modeling canvas and ontology to the enterprise architecture modeling standard ArchiMate, which makes the above translation possible and represents a formal basis for business modeling in ArchiMate. A case study illustrates the mapping between the two languages.

Dimensioning network links: a new look at equivalent bandwidth

One of the tasks of network management is to dimension the capacity of access and backbone links. Rules of thumb can be used, but they lack rigor and precision, as they fail to reliably predict whether the quality, as agreed on in the service level agreement, is actually provided. To make better predictions, a more sophisticated mathematical setup is needed. The major contribution of this article is that it presents such a setup; in this a pivotal role is played by a simple, yet versatile, formula that gives the minimum amount of capacity needed as a function of the average traffic rate, traffic variance (to be thought of as a measure of burstiness), as well as the required performance level. In order to apply the dimensioning formula, accurate estimates of the average traffic rate and traffic variance are needed. As opposed to the average rate, the traffic variance is rather hard to estimate; this is because measurements on small timescales are needed. We present an easily implementable remedy for this problem, in which the traffic variance is inferred from occupancy statistics of the buffer within the switch or router. To validate the resulting dimensioning procedure, we collected hundreds of traces at multiple (representative) locations, estimated for each of the traces the average traffic rate and (using the approach described above) traffic variance, and inserted these in the dimensioning formula. It turns out that the capacity estimate obtained by the procedure, is usually just a few percent off from the (empirically determined) minimally required value.

Extending CORBA with specialised protocols for QoS provisioning

The CORBA layer in a distributed system hides the heterogeneity of the underlying computer network. The interactions of objects located at different computing systems are described in terms of IDL specifications and the ORB takes care of the actual transfer of messages along the wire. In fact, an object interaction is translated into the transfer of GIOP messages over TCP/IP networks (IIOP). The advantages in terms of interoperability and portability are obvious. Currently, OMG is in the process of standardising the Open Communication Interface (OCI). Through OCI, a protocol module can be plugged into any ORB and hence, the distributed application including the ORB can be put on top of any network without changing the applications code, thus implementing network transparency. Obviously, the QoS of distributed applications depends on the QoS of the underlying network protocols e.g., best effort versus guaranteed bandwidth. Through OCI we are able to use the network protocol that is needed to satisfy the QoS requirements of a specific distributed application. We propose to extend CORBA with specialised protocols for QoS provisioning using OCI. We have prototyped protocol plug-ins, including a plug-in that exploits IP Multicast. The IP Multicast plug-in can be used in situations where one client communicates with a group of replicated servers. We have used this mechanism to implement replication transparency in CORBA and have shown that the OCI interface can be used for QoS provisioning in CORBA. Based on our hands-on experience, we have also identified some shortcomings in the proposed OCI specification.

Telemedicine services: from idea to implementation

Background nNew ways to cope with the increasing number of elderly and people with chronic diseases who need care need to be found. As there are high expectations of Information and Communication Technology (ICT) many ICT initiatives have been developed. However 75% of these fail to survive the research phase. This brings us to the question, how to realize successful telemedicine applications. This paper describes a method involving three key elements for the realization of successful telemedicine applications and shows the results of this method for one specific application, a myofeedback based tele-treatment service for treatment of patients with chronic pain (MYOTEL). nMethod nThe methodology discerns three key matters: clinical content, design and outcome. nClinical content; care services for patients with chronic diseases aim at increasing levels of functioning. As such telemedicine services need to monitor aspects of the patients functioning and to provide feedback about this to the patient. Promising parameters are general physical activity and muscle activation patterns. Concerning the feedback, this requires choices about the content of the information, the modality and timing of feedback. nDesign; it appears that the different stakeholders involved speak different languages, that there is a lack of knowledge about aspects related to acceptance and a lack of good methods to define user requirements. Scenario based requirements analysis is promising to overcome these barriers. nOutcome: Evaluation of telemedicine services in everyday clinical practice should be performed according a staged approach, starting from technical performance and user satisfaction to large scale clinical studies with multiple end points. nResults nApplying this method to MYOTEL shows nClinical content: nMYOTEL is based on the fact that subjects with chronic pain differ in their muscle activation patterns, reflected in a decreased ability to relax. As such treatment could consist of monitoring the level of muscle relaxation and providing feedback to the patient with the aim to enable them change nDesign nA scenario was developed describing the people, their roles and activities, the functions of the application and its context of use. Subsequently functional requirements were defined. Most important are: n- monitoring should focus at muscle relaxation, n- feedback should be provided in case muscle relaxation is insufficient, n- the system should be usable during every day tasks, n- people should able to put on and take off the system themselves, n- the system can be worn under the clothes n- feedback should be private n- teleconsultations can partly replace face to face contacts. nOutcome nThe first evaluation trial (N=10) showed that the application was technical stable, that pain and disability decreases and that patients were satisfied with the remote counselling but less satisfied with the technical functioning. The second a large scale multicentre clinical trial (n=138) with the improved service showed that Myotel is as effective as usual care and that the time investment of the professionals reduces with 20%. nConclusion nResults of this study showed that using this method, telemedicine applications can be developed that have potential to make health care more effective, efficient and accessible. []

Second generation micropayment systems: lessons learned

In the next years the market for low value products such as online music and videos and the role of micropayment systems for selling such products are expected to grow substantially. The first generation micropayment systems appeared around 1994, with systems such as eCash, MilliCent and CyberCoin. These systems were unable to gain market share, however, and disappeared slowly in the late 1990s. The second generation micropayment systems appeared around 1999-2000, and are still operational. In this paper we present an overview of first and second generation micropayment systems, and compare their key characteristics to determine their success or failure. This paper explains why the first generation systems failed and concludes that second generation systems have a better chance for success than their predecessors.

A Method for Business Model Development

Currently, business modelling is more an art, than a science, as no widely accepted method exist for the design and specification of business models. This could be an important reason why many IT innovation projects fail to be absorbed in a real life setting. We propose a structured method to create “as-is” business models in a repeatable manner. The method consists of the following steps: identify the involved roles, recognize relations among roles, specify the main activities, and quantify using realistic estimates of the model. The resulting business model reflects the current situation. This is the basis for further analysis of possible business cases, scenarios, and alternative innovations, which may enable successful projects to be implemented, instead of ending on a shelf after the pilot stage. We illustrate the proposed method by means of a case in the healthcare sector.

The Fall and Rise of Micropayment Systems

In this article, we discuss the chance that the second generation systems will become more successful than their predecessors and to what extent do these sys-tems solve or avoid problems causing the failure of the first generation systems. We show that most failure causes are avoided in the second generation, and con-clude that these systems have a much better chance to be successful than their predecessors.

Goal and model driven design of an architecture for a care service platform

Service-Oriented Architecture holds the potential of allowing the development on-the-fly of flexible applications that can adapt rapidly by combining and reusing existing services. We believe that in order to react swiftly and coherently to changes, an architecture must provide a capability to capture how services, and the more complex applications based on them, realize business motivations. This research develops a framework and a method for goal-driven, model-driven, and service-oriented design. The framework includes goal modeling in the MDA stack, from CIM to code. By using this framework, we are able to create a system that is compatible with its business goals, and thus is flexible when business demands change. A case study demonstrates how our framework can be used to combine MDA, SOA, and goal modeling with business rules as an architecture for a care service platform.

An interconnection architecture for micropayment systems

In the next years the market for low value online content, like music and videos, is expected to grow substantially. To allow pay-per-use of such content, micropayment systems are expected to play an important role. Since there are already many competing micropayment systems on the market, customers and merchants are forced to use multiple systems. To overcome the problems associated with using multiple systems, the research presented in this paper builds upon the idea of payment gateways that interconnect these systems. We introduce a generally applicable interconnection method such that the interconnection of these systems can be easily realized in a systematic way. This approach consists of (de)enhancing the existing micropayment services towards a uniform service level before the interconnection takes place. This paper presents the main functional characteristics of existing payment systems, and proposes modification strategies for existing micropayment systems to provide the uniform payment service. The modifications are required before the interconnection can take place.