Browse Prior Art Database

Self Descriptive Components within a Service Oriented Architecture

IP.com Disclosure Number: IPCOM000200089D
Original Publication Date: 2010-Oct-12
Included in the Prior Art Database: 2010-Oct-12
Document File: 3 page(s) / 155K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

The configuration of the deployment of a service oriented architecture where a service itself is a composition of components requires detailed information of the components such as the provided and required component interfaces or whether an interface is a public service interface. A service can consist of a lot of components and the dependency between those components can be very complex. Due to this the configuration of a service, even or especially if it is XML (eXtensible Markup Language) based, it is very difficult and in the most cases not human readable. Furthermore, to guarantee the correctness and consistency of such configuration file is difficult, too. Software components often take the form of interfaces or collections of objects, in some binary or textual form, adhering to some interface description language (IDL) so that the component may exist autonomously from other components in a computer.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 27% of the total text.

Page 01 of 3

(This page contains 00 pictures or other non-text object)

(This page contains 01 pictures or other non-text object)

Self Descriptive Components within a Service Oriented Architecture

Idea: Frank Wigger, IN-Bangalore

The configuration of the deployment of a service oriented architecture where a service itself is a

composition of components requires detailed information of the components such as the provided and

required component interfaces or whether an interface is a public service interface. A service can

consist of a lot of components and the dependency between those components can be very complex.

Due to this the configuration of a service, even or especially if it is XML (eXtensible Markup Language)

based, it is very difficult and in the most cases not human readable. Furthermore, to guarantee the

correctness and consistency of such configuration file is difficult, too.

Software components often take the form of interfaces or collections of objects, in some binary or

textual form, adhering to some interface description language (IDL) so that the component may exist

autonomously from other components in a computer.

Up to now, there are two ways of implementing a component based service. First, the developer of

component A has to load component B and then to connect the component interfaces directly by

implementing the necessary calls (see Figure 1). Second, a so-called container application is

responsible for loading the components and injecting the correct interface pointers based on a

configuration file. The second solution is the most flexible one, but it requires a valid configuration file,

which is in the most cases based on a XML schema. As already mentioned such a configuration file is

very complex and it is difficult to maintain its consistency, because the description of provided

interfaces and especially of the required interface is not part of the component itself. Today there is no

concept of adding the information of the required interfaces to a component.

The solution proposed in the following reduces the complexity by supporting components that expose

their interface details in order to enable a graphical representation, which allows an easy plug-and-

play concept for a configuration user interface (UI).

Figure 2 shows an example UI for configuring a service based on a component composition. The user

can drag a component from the component library and drop it to the service configuration. Since the

configuration of the provided and more important of the required interfaces is part of the component

itself, it is possible to display the component with the provided and required interfaces. If a required

interface is not connected to a matching provided interface the UI can immediately mark the interface

red. In the next figure you can see an example of an alarm service. In this example, the user added

two components to the service configuration (AlarmServiceBusinessLogic and AlarmStatemachine).

The AlarmServiceBusi...