A PATTERN FOR INTERCONNECTING DISTRIBUTED

COMPONENTS

Walid Gaaloul

, Karim Ba

ına

1,2

, Khalid Benali

, and Claude Godart

LORIA - INRIA - CNRS (UMR 7503)

BP 239, F-54506 Vandœuvre-l

es-Nancy Cedex, France

School of Computer Science and Engineering,

The University of New South Wales, Sydney NSW 2052, Australia

Keywords:

Object Orientation in Internet and Distributed Computing, Internet and Collaborative Computing, Process De-

sign and Organisational Issues, Enterprise-based Component Architectures, Architectural Patterns for Object-

based Components and Applications, Distributed Component Cooperation.

Abstract:

Nowadays, enterprises express huge needs for mechanisms allowing interconnection of their business compo-

nents. Due to the weakness of component integration facilities, a large amount of research and development

has been made in this area. Nevertheless, developed mechanisms are generally hard-coded, proprietary and

lack a high level of abstraction. This paper presents our contribution to the design, the implementation, and

the experimentation of an architectural pattern named “Service”. This pattern is able to support intercon-

nection and cooperation between distributed components independently of their speciﬁc contexts (workﬂow

processes, database robots, agents, networks nodes, etc.). Our “Service” pattern proposes a generic solution to

interconnection and cooperation between components through object oriented structures and scenarios. The

essence of the pattern is the ability for ”Service” to provide registration, discovery, negotiation and dynamic

API information on behalf of a contained service. Moreover, several alternatives are presented to implement

our pattern.

1 PROBLEMATIC

Applications manipulate considerable number of dis-

tinct and heterogeneous components. By components

we mean all resources needing to be discovered on

a network, and to be used through customised ac-

cess rights (e.g. workﬂow processes, database robots,

agents, distributed objects, networks nodes, etc.).

These components are often used to cooperate with

each other to achieve common goals of the composed

applications.

Through our pattern “Service”, we bring a generic

solution to the problem of components interconnec-

tion and cooperation. We express the genericity un-

derlying the concepts of components interconnection

and cooperation which are distinct and heterogeneous

as an architectural pattern we name “Service”. This

pattern will express a structural schema for coop-

eration of heterogeneous components which enables

reusability of design and architecture concepts.

2 SERVICE PATTERN :

STRUCTURE

Our contribution is in the same vain of research works

on interconnection and cooperation patterns (Pyarali

et al., 2000; Benatallah et al., 2003; Arsanjani, 1999).

It is speciﬁed through the description of its struc-

ture elements, their responsibilities and their manner

to collaborate in the same pattern building structure

(Buschmann et al., 1995; Schmidt et al., 2000). ”Ser-

vice” pattern can be used when there is a need of

cooperation within an environment of heterogeneous

and monolithic components.

”Service” pattern provides a conceptual schema for

distributed component to suit needs for dynamic co-

operation. It helps to decompose a cooperative sys-

tem to software bricks that deal with organisational

and structural aspects such as component presenta-

tion, and with behavioral aspects such as component

access rights, component security, etc.

Our pattern “Service” is composed of two struc-

tures :

1. a service deﬁnition structure which enables to de-

430

Gaaloul W., Baïna K., Benali K. and Godart C. (2004).

A PATTERN FOR INTERCONNECTING DISTRIBUTED COMPONENTS.

In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 430-434

DOI: 10.5220/0002643404300434

 SciTePress

ﬁne, customize the access to components, and man-

age numerous existing components ;

2. a service discovery and negotiation structure which

enables to support operations of either component

lookup according to structured properties, or dy-

namic customisation of component properties and

access rights.

2.1 Service deﬁnition

UML class diagram of ﬁgure 1 represents the role

played by a service to abstract and to adapt a com-

ponent subject in order to customize the access to its

resources. Thus, a “Service” is seen as a software en-

tity that encapsulates a component to keep only visi-

ble the elements necessary to its interconnection and

cooperation with other application components.

Subject

• Deﬁnes an object interface, which is speciﬁc to a

particular component.

Service

• Manages meta-information that keep possible dis-

covery, negotiation and access control to a compo-

nent;

• Dynamically controls the access to the component

it encapsulates;

• Has the capability to dynamically extract the API

of its component, in order to ensure the control

of a component method invocation or a component

event notiﬁcation;

• Provides a new interface of the component it

adapts: (e.g., complementary functionalities re-

lated to negotiation and discovery);

• Is able to dynamically extract the adapted compo-

nent category and properties attributes in order to

build a proﬁle enabling service discovery and com-

parison to other adapted components;

Category

• Enables components “Subject” to be categorised

thanks to application speciﬁc taxonomy (e.g., ob-

ject taxonomy, XML hierarchical taxonomy, etc.).

Proﬁle

• Describes meta-information related to the com-

ponent “Subject” as an application speciﬁc set of

named-value attributes properties.

APIManager

• Stores information on the component “Subject” in

terms of methods “Method” and events ”Event”;

• Enables the access control to the previously nego-

tiated interface of the component “Subject”;

• Method and Event enable the component data, status,

and resources management through its primitives

invocation and events notiﬁcation.

ServiceContainer

• Deﬁnes a repository of “Service” objects that is nec-

essary to their discovery, negotiation and access;

• Enables global processing to be applied to services

of the same category (e.g., mining, veriﬁcation,

transformation, etc.);

• Gathers a view of “Service” objects according to

particular criteria.

ConcreteServiceContainer

• Deﬁnes a concrete “ServiceContainer” repository

(e.g., RequestedServiceContainer : gathering requested

services, ProvidedServiceContainer : gathering pro-

vided services, WrappedServiceContainer : gathering

already negotiated and bound services).

2.2 Service discovery and

negotiation

UML class diagram of ﬁgure 2 isolates operations re-

lated to components discovery (e.g., matching calcu-

lus between components and component neighbour-

hood calculus), and operations related to components

negotiation. These operations are dynamic and efﬁ-

cient cooperation tools. On one hand, service deﬁ-

nition and discovery aim to structure component ser-

vice containers and ”position” them relatively to each

other. On the other hand, service negotiation enables

to distinguish between discovered components and to

select those that propose most interesting cooperation

contract comparing to other neighbour components.

2.2.1 Service discovery

Locator

• Manages the localisation of the objects “Service”;

• Enables to discover realisations of the object “Sub-

ject” according to a given “LocationStrategy”;

• Depends on the object “Matcher” that ensures the

matching calculus necessary to every service local-

isation.

A PATTERN FOR INTERCONNECTING DISTRIBUTED COMPONENTS

431

Figure 1: Service deﬁnition structure

LocationStrategy

• Dynamically manages service discovery algo-

rithms classes (according to methods, events, pro-

ﬁle, category, etc.);

• Declares a common interface to every service dis-

covery algorithm;

• Enables discovery algorithms to be independent

and interchangeable by choosing dynamically

an algorithms implemented in one of “Concrete-

LocationStrategies”;

Matcher

• Manages the matching calculus for the objects “Ser-

vice” ;

• Is composed of strategies “MatchingStrategy” for

matching calculus of objects “Service”.

MatchingStrategy

• Declares a common interface to every service

matching calculus algorithm;

• Enables the management of service matching cal-

culus algorithms and their reﬁnement;

• Enables service matching calculus algorithms to be

chosen at runtime from one of “ConcreteMatching-

Strategies”;

2.2.2 Service negotiation

Negotiator

• Manages the negotiation of “Service” objects ac-

cording to a given ”NegotiationStrategy”;

• Enables negotiation of interface access of the ob-

ject “Subject”;

• Knows the set of negotiations concerning the object

“Service”;

• Enables the application of global processing to ne-

gotiations of the same type (e.g., analyse, tactical

application, coordination, etc.);

NegotiationStrategy

• Declares a common interface to every service ne-

gotiation algorithm;

• Enables service negotiation algorithm to be cho-

sen at runtime from one of “ConcreteNegotiation-

Strategies”;

3 IMPLEMENTATION ISSUES

AND SERVICE APPLICATION

EXPERIMENTS

3.1 Implementation issues

Among numerous possible solutions for implement-

ing the facilities of “Service” pattern, we summarise

some of them in table 1.

3.2 Service pattern applied to

Internet printers

As an example of known service pattern use, we will

detail Internet printing service through IPP (Internet

Printing Protocol) . As described by the RFC (IETF,

2000a), Internet printing service possesses the follow-

ing properties :

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

432

Table 1: Service pattern implementation technologies

Facility Solution 1 Solution 2 Solution 3 Solution 4 Solution 5

Services CORBA CCM Web

Servants Components Services

Containers CORBA Trading WebDAV Name RDF UDDI

Service Spaces Containers Repository

Proﬁles CORBA Trading WebDAV RDF XML

Service Properties Properties Properties Files

Methods IDL CIDL WSDL

Interface Interface Interface

Events CORBA Event CCM Message Oriented

Service Events Middleware (MOM)

Interface CORBA Security ad-hoc facilities

visibility Service

CORBA Trading WebDAV RDF-enabled

Discovery Services or CORBA Searching and search UDDI

Naming Service Locating (DASL) engine

Negotiation OMG Negotiation Facility, Trading Partner Agreement (TPA)

or ad-hoc facilities

Figure 2: Service discovery and negotiation structure

• A proﬁle : (printer-name, printer-uri-supported,

printer-location, printer-state, color-supported, multiple-

document-jobs-supported, document-format-supported,

printer-resolution, etc.) (IETF, 2000b);

• Operations : (Print-Job, Get-Jobs, Pause-Printer,

Purge-Jobs, Get-Printer-Attributes, etc.) (IETF,

2000b);

• Events : (printer-is-accepting-jobs, job-impression-

completed, job-state, etc.);

• Requirements for discovery mechanisms within a

networks of printers : according to printer-name, or

according references stored in printer-urisupported at-

tribute which represent the set of all supported URI

identiﬁer by the printer, or according to information

stored in printer-location attribute which is a char-

acter string of 127 bytes describing the printer lo-

cation in natural language -e.g., “Room 123A, 1

ﬂoor, building A”-), or according to values of other

attributes (IETF, 2000b);

• Requirements for negotiation mechanisms of either

printer supported content format or other printer at-

tributes values (IETF, 2000b; IETF, 2001);

• And requirements for printer access privileges and

roles mechanisms : printing, jobs management, su-

pervision, etc. (IETF, 2000b).

A PATTERN FOR INTERCONNECTING DISTRIBUTED COMPONENTS

433

REFERENCES

Arsanjani, A. (1999). Service Provider: A Domain Pattern

and its Business Framework Implementation. In Pat-

tern Languages of Programs (PLoP’99).

Benatallah, B., Dumas, M., Fauvet, M.-C., and Rabhi,

F. A. (2003). Patterns and Skeletons for Parallel and

Distributed Computing, chapter Towards Patterns of

Web Services Composition, pages 265–296. Springer-

Verlag.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P.,

and Stal, M. (1995). Pattern-Oriented Software Ar-

chitecture, Volume 1: A System of Patterns. Wiley,

John and Sons.

IETF (2000a). Internet Printing Protocol - IPP/1.1: Model

and Semantics. IETF (Internet Enegineering Task

Force), www.ietf.org/rfc/rfc2911.txt.

IETF (2000b). Internet Printing Protocol (IPP) : Require-

ments for Job, Printer, and Device Administrative Op-

erations. IETF (Internet Enegineering Task Force),

www.ietf.org/rfc/rfc3239.txt.

IETF (2001). Internet Printing Protocol (IPP) : The

’indp’ Delivery Method for Event Notiﬁcations and

Protocol/1.0, draft. IETF (Internet Enegineering

Task Force), www.ietf.org/internet-drafts/draft-ietf-

ipp-indp-method-06.txt.

Pyarali, I., O’Ryan, C., and Schmidt, D. (2000). Patterns

for efﬁcient, predictable, scalable, and ﬂexible dis-

patching components. In Proceedings of 7th Pattern

Languages of Programs Conference (PLoP’00), Mon-

ticello, Illinois, USA.

Schmidt, D., Stal, M., Rohnert, H., and Buschmann, F.

(2000). Pattern-Oriented Distributed System Archi-

tectures, 1st edition. John Wiley & Sons.

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

434