See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221215951

Hybrid service-oriented architectures: a case-study in the automotive domain

Conference Paper · September 2005

DOI: 10.1145/1108473.1108487 · Source: DBLP

CITATIONS READS
25 169

6 authors, including:

Luciano Baresi Carlo Ghezzi

Politecnico di Milano Politecnico di Milano
345 PUBLICATIONS 9,459 CITATIONS 366 PUBLICATIONS 10,985 CITATIONS

SEE PROFILE SEE PROFILE

Antonio Miele Matteo Miraz

Politecnico di Milano Politecnico di Milano
72 PUBLICATIONS 1,116 CITATIONS 14 PUBLICATIONS 244 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Antonio Miele on 23 May 2014.

The user has requested enhancement of the downloaded file.

 Hybrid Service-Oriented Architectures:
A Case-Study in the Automotive Domain

Luciano Baresi, Carlo Ghezzi, Antonio Miele,

Matteo Miraz, Andrea Naggi, Filippo Pacifici
Dipartimento di Elettronica e Informazione - Politecnico di Milano
Piazza Leonardo da Vinci 32
I-20133 Milano, Italy
[email protected]

ABSTRACT Although components do not vary frequently, we cannot

Vehicles are becoming complex software systems with many envisage software architectures where the communications
components and services that need to be coordinated. Ser- among components are hard-wired. The different configura-
vice oriented architectures can be used in this domain to sup- tions would lead to a very complex architecture with many
port intra-vehicle, inter-vehicles, and vehicle-environment different variants.
services. Such architectures can be deployed on different Inter-vehicles and vehicle-environment (also called, extra-
platforms, using different communication and coordination vehicle —EV) interactions consider the different vehicles
paradigms. We argue that practical solutions should be hy- (and the environment) as components of a dynamic feder-
brid: they should integrate and support interoperability of ation, which supply and require services. Service suppliers
different paradigms. We demonstrate the concept by inte- and requestors are not fixed nor predefined, but can join
grating Jini, the service-oriented technology we used within and leave the federation dynamically. In this context, it is
the vehicle, and JXTA, the peer to peer infrastructure we not only a problem of understanding who is “alive” out of a
used to support interaction with the environment through predefined set (i.e., the mandatory elements and additional
a gateway service, called J2J. Initial experience with J2J is components that can be operated on a vehicle), but avail-
illustrated. able features can change with the context and thus need to
be discovered, negotiated, and bound dynamically.
Dynamism, flexibility, and self-organization are the key
1. INTRODUCTION features of service-oriented architectures (SoAs) [2]. A SoA
Vehicles are becoming complex software systems where is a software architecture where available services are ad-
many different components and services need to be properly vertised through brokers, clients can discover and negotiate
coordinated [5]. Consider, for example, the large number them, and the binding between clients and providers can be
of intra-vehicle features that must be controlled and coordi- set in flexible ways, e.g., dynamically. This solution works
nated, such as wheels, brakes, injection control, ABS system, for both IV and EV interactions. In the first case, it helps
and other subsystems and accessories, including climate con- discover the features installed in the vehicle and configure
trol, HI-FI, and GPS. Furthermore, advances in network- them. In the second case, since services change with the
ing technologies are now adding complexity (and new chal- context, discovery and negotiation capabilities help identify
lenges), by allowing vehicles to communicate and coordinate available components and set proper federations.
their behaviors with the external environment and with the The investigation of SoAs in the automotive domain —
other vehicles in proximity. Vehicles may also be viewed as both at the IV and the EV level— is one of the main research
carriers of services, e.g., providing information on the traffic goals of our participation to the EU research project called
encountered during their journey to other vehicles, or inter- SeCSE (Service Centric System Engineering, [7]) whose goal
acting with the environment, which might provide location —among others— is to investigate the use of SoAs in the
aware services to the people in the vehicle. automotive domain. In order to use it as a guideline for
Both intra-vehicle, inter-vehicles, and vehicle-environment development, the general idea must be refined into detailed
interactions require flexibility and, possibly, some degrees design and implementation guidelines. We argue that in do-
of self-configuration. Intra-vehicle (IV) interactions must ing so we do not force software architects to follow a uniform
deal with the many configurations of modern vehicles and style and adopt a single middleware technology. Rather, we
also with the mobile devices that might be used in the car. aim at designing hybrid solutions, where services are sup-
plied through different interaction paradigms and middle-
ware systems. For example, interactions within the vehi-
cle and between vehicles and the environment may require
Permission to make digital or hard copies of all or part of this work for different solutions. Within a vehicle, we can adopt a mid-
personal or classroom use is granted without fee provided that copies are
dleware solution that is based on some shared centralized
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to components. As we move to EV features, we must fore-
republish, to post on servers or to redistribute to lists, requires prior specific see a decentralized organization where services are suitably
permission and/or a fee. replicated to improve their availability. Moreover, the de-
SEM 2005 September 2005 Lisbon, Portugal gree of reliability is higher in the vehicle than in the open
Copyright 2005 ACM 1-59593-204-4/05/09 ...$5.00.

62
environment. work by registering themselves with a LUS. Since a LUS
Another reason for dealing with integrating different so- is itself a Jini service, there can be multiple LUSs on the
lutions —both in terms of interaction paradigms and mid- network and they can come and go as every dynamic Jini
dleware technologies— is of practical nature. The IV and service.
the EV worlds have different stakeholders and their services A Jini component might know at design time the correct
may be developed by different organizations. The need for address of a LUS or discover it at runtime by sending a
integrating subsystems that follow different styles might be broadcast request for lookup services. If the Jini component
dictated by existing legacy components. already knows the correct address of a LUS, it contacts it
For all these reasons, we argue that hybrid SoAs should directly, otherwise it contacts the first LUS that answers to
be investigated. A hybrid architecture is one that integrates its broadcast request. In both cases, the LUS sends a proxy
different communication paradigms and technological plat- to the Jini component that then uses it to lookup or register
forms. Each element perceives a homogeneous federation services in the network.
where all the components communicate by using their prim- During the registration phase, the LUS and the Jini ser-
itives. Suitable gateways are then defined and implemented vice agree on the terms of the lease, such as the duration
to connect the heterogenous parts and supply the required of the lease, the objects exposed to the other services, and
transformations. a set of optional attributes. Such exposed objects can be
In this paper, we report on our first experiences with a either copies of existing objects or proxies to let the client
hybrid architecture that integrates Jini, which is used as execute the functionality locally or remotely, respectively.
service-oriented IV technology, and JXTA, the peer-to-peer The optional attributes, set during the registration phase,
infrastructure we have used for EV services. The interac- can be used for the categorization of services, helping dif-
tions between Jini and JXTA are managed by J2J, the gate- ferentiate services that offer the same capabilities. Jini, in
way we designed and implemented to deploy the necessary fact, offers the ability of searching for a service using its in-
integration in the hybrid SOA. The choice of these tech- terface, and a set of attributes, to identify a specific service
nologies is simply motivated by their diffusion and by their in a group of services that export the same interface.
suitability to support IV and EV interactions. They are the Since Jini clients choose Jini services according to the Java
representatives of a wider class of middleware technologies, interface they implement, they automatically use the ser-
and the ideas behind J2J are not limited to this specific in- vice that provides the functionality they need without even
stantiation of hybrid systems, but have broader applicability. knowing how it is called or where it is located. This makes
J2J transforms the service invocations in Jini into mes- service substitution simpler and more affordable: the client
sages in JXTA, and viceversa. It also allows components is able to recognize and use new service implementations as
to dynamically identify the services they need and thus the soon as they become available.
components they want to interact with. Besides presenting Javaspace [9] implements a Linda-like tuple space [3].
the general concepts and the high-level architecture of J2J, In a tuple space, different components can share informa-
we also exemplify the message flows when we make the en- tion in a logical common space, as required in blackboard-
vironment (JXTA) communicate with the car (Jini) and the based architectures. This space, called repository, contains
other way around. These examples demonstrate the capa- the shared objects, called tuples, and offers the basic mech-
bilities of integrating two different technologies, but also two anisms for adding, reading, and extracting tuples.
different interaction paradigms. The adoption of JXTA, and Since it is implemented on top of Jini, Javaspace is a Jini
thus of a P2P approach, help solve the problems of the cor- service. Thus, when a component needs to use its features,
rect distribution of information in wide-area environments, it joins the Jini framework by searching for the Javaspace
where a centralized repository or coordination would not be service in an appropriate LUS. Once it finds an active Javas-
feasible. pace, it uses its features: it can add, read, and extract tuples
The rest of the paper is organized as follows. Section 2 from the repository. Users can add objects to the Javaspace
briefly surveys the technologies used to conduct our exper- to share information: when a service needs to communicate
iments. Section 3 presents J2J, which is our proposal for with other services, it puts the relevant information in a
a gateway that supports the cooperation between Jini and tuple and adds it to the Javaspace. Each tuple is character-
JXTA frameworks. Section 4 applies the proposed gateway ized by a special-purpose interface, according to the message
to the interaction between a vehicle and the environment. type it belongs to. Services can look for the tuples stored in
Section 5 describes some related approaches to foster the co- the Javaspace and filter the results with respect to a partic-
operation among different communication frameworks and ular type of tuples. The searching mechanism is based on
Section 6 concludes the paper. pattern matching of the tuples’ interfaces and optionally on
some attributes. Once a tuple is found, the caller can read
2. TECHNOLOGIES it or read and remove it atomically.
Javaspace can be used to build a dynamic framework of
The proposed hybrid architectures are based on Java-
decoupled services. All services can cooperate with the oth-
related technologies, namely Jini, Javaspace (which is in-
ers through message exchange. The collaboration is not
tegrated in Jini), and JXTA.
based on the knowledge of involved services. Each service
Jini [9] introduces the concept of dynamic networking. It
needs only to know how to access the Javaspace and how to
is a set of specifications that describe how to build adap-
interpret stored messages (tuples).
tive distributed systems that run on the Java platform. A
JXTA [11] is a set of protocols that allow devices to com-
dynamic network is created with the assumption that the
municate in a peer to peer (P2P) way. JXTA peers create
environment can evolve and the system has to adapt to the
a virtual network where any peer can interact and commu-
changes.
nicate directly with the others. JXTA is designed to build
Jini Lookup Services (LUS) allow services to join the net-

63
frameworks which are highly dynamic and scalable. The Jini supports synchronous communications, where the cal-
main components of JXTA are its peers and the commu- ler is blocked until the callee does not answer. In contrast,
nication channels used to allow the peers to interact. A JXTA supports asynchronous communications, where the
JXTA framework can work both without a centralized au- caller is not blocked after performing a call and it is free to
thority and with some peers that act as lookup services to continue its execution. If needed, the callee can contact the
improve network performance. caller to send a response message.
JXTA provides several features that support the organiza- A second difference concerns the collaboration schema.
tion of peers and the discovery of services. Groups of peers Jini can support both direct invocations, through remote
can also be related to each other by some special-purpose cri- method calls, and blackboard-based interactions through
teria to create a hierarchical structure among groups. When Javaspace. In the first case, the caller knows exactly how
a group is created, it informs the other peers about its exis- to contact the callee and the communication takes place di-
tence. From then on, existing peers can join the new group. rectly with the other party. In the second case, the caller
Notice that a peer can join different groups. Advertisements does not know exactly how to contact the callee, so it uses
are fragments of XML code that identify an entity, i.e., a a blackboard to communicate: the caller sends a message
peer, a group, or a service, in a JXTA framework. They con- to the blackboard, and then the possible recipients read the
tain a description of the object and the information needed message posted on it. One or more components may de-
to reach it. They are created at the same time as the en- cide that they are interested in the message posted on the
tity, and they are spread to the other peers. The discovery blackboard and they can react consequently.
service is an infrastructure that permits the discovery of a JXTA only adopts the direct communication schema, but
specific JXTA entity. It can find advertisements published since our goal is to integrate the two frameworks, we must
by other entities in the same group of the searching peer. merge the two communication schemas. J2J allows Jini
When a peer knows another peer, it can instantiate a com- to borrow asynchronous communications from JXTA, and
munication channel with that peer and they can exchange JXTA to inherit synchronous and blackboard-based com-
typed objects serialized via XML messages. Pipes are the munications from Jini.
high-level abstraction for communication channels. A pipe
is a link between two or more peers that provides primitives 3.1 Message types
for transferring typed objects. Every pipe has its own ad- J2J allows a JXTA network and a Jini network to ex-
vertisement and a peer can bind itself to a given pipe to change the following messages. If we consider the informa-
transmit data. tion flow from JXTA to Jini, J2J supports:
• Direct messages. The sender, a JXTA peer, knows
3. J2J exactly the kind of services that are supposed to re-
The goal of J2J is to create hybrid architectures to en- ceive the message. It knows that the receiver is a
able a bi-directional communication between a Jini network Jini service that implements a specific interface. The
and a JXTA network (Figure 1). We can also replicate J2J sender specifies the parameters to lookup the service,
to set hybrid architectures with one JXTA network and sev- the specific method it wants to invoke, its actual pa-
eral JINI networks: each J2J gateway enables a Jini network rameters, and if it wants to be notified about the re-
to communicate with the JXTA network. Every bridge can sults of the method execution or about possibly thrown
operate in a totally independent way with respect to the oth- exceptions.
ers. Every Jini network uses the same cooperation paradigm • Indirect messages. In blackboard-based collabora-
to communicate with JXTA; the same applies when JXTA tions, the sender (JXTA) sends a message without any
communicates with a Jini network. addressing information. J2J receives the message, rec-
ognizes that it is a blackboard message, converts it into
a tuple, and stores it in the Javaspace. Interested Jini
services are notified and can use the tuple.
JXTA JINI
PEER SERVICE
JXTA If we consider the information flow from Jini to JXTA,
PEER JINI
SERVICE J2J supports:
JXTA JINI
JXTA NETWORK PEER J2J SERVICE JINI NETWORK
• Direct messages. Jini services call a proper opera-
JINI
SERVICE
tion (specified later) on the Jini service published by
JXTA
PEER
JXTA JINI J2J, with the message to be sent and the addressee as
SERVICE
PEER parameters. J2J builds a JXTA message and sends it
to the JXTA destination. If no suitable peers exist,
this exception is sent back as separate message.
• Indirect messages. In the blackboard model, Jini
Figure 1: J2J hybrid architecture.
services store their messages (tuples) in the Javaspace,
as any Jini service would do. J2J is notified of these
Before explaining the details of J2J, we must understand added data, discovers if there is an external JXTA
that Jini and JXTA use different communication paradigms group that wants to receive them, and forwards them
and thus their integration implies the capability of mimick- to the group. To make it possible, J2J uses the Direc-
ing the Jini communication paradigm in JXTA and vicev- tory Service to find if there are peers interested in the
ersa. tuple and to retrieve their addresses.

64
 J2J relies on the messages exchanged between the two the interface of the callee, while in indirect communications
parties, and does not address QoS-related issues. For the the caller only deposits some data in a shared space and
sake of simplicity, we assume that the meaning of a message knows nothing about the possible users of those data.
is the same in the whole system. We do not consider ontolo- The JXTA Module implements a write method that reg-
gies and semantic translations, but we rely on standardized isters a JXTA handler for every JXTA group J2J is listening
messages. to. The handlers process JXTA messages as soon as they ar-
rive. The method distinguishes between direct and indirect
3.2 J2J architecture messages —since the difference is in the content of the XML
J2J is seen as a Jini service within the Jini network, while message— and uses an external library to build an object
it becomes a peer in JXTA. Figure 2 shows the architecture that corresponds to the XML message.
of J2J, where we have a JXTA Module and a Jini Mod- If we consider indirect messages, the JXTA Module simply
ule, along with their interfaces called JXTA Interface and calls the Jini module by passing the object created above,
Jini Interface, and a Directory Service. Moreover, the Jini but without specifying the destination. The message is
Module uses a dedicated interface to communicates with the stored in the Javaspace. If we consider direct messages,
Javaspace. the object also contains the destination of the message (i.e.,
the name of the service for the LUS of the Jini platform).
This module is also responsible for mimicking synchronous
interactions with JXTA peers. It keeps track of those peers
that have sent a direct message and want a response, and
sends appropriate messages as soon as the responses arrive
from Jini. It also sends to JXTA fault messages if an error
occurs while calling the Jini service.
The JXTA module exports method sendToJXTA to the Jini
module. This method is used to send messages to the JXTA
network. It takes as parameters the message (as a Java ob-
ject) and the destination (as a hierarchical structure repre-
senting the path groups to a JXTA peer). This method joins
the specified group, serializes the message as an XML docu-
ment, and sends the document either to the single specified
peer or to the whole group. Since the Jini Module assumes
synchronous communications, if the message requires a re-
sponse, this module also transforms the response message for
the JXTA peer into the correct response to the Jini invoca-
tion, otherwise the call to sendToJXTA returns immediately.
If a response is required, but it does not arrive within a
specified amount of time, the method raises an exception.

Jini Module
The Jini Module implements a Jini service registered in the
Jini network. This enables J2J to communicate with the
Jini network.
When this module receives a call from a service within
Figure 2: J2J architecture. the Jini network, it identifies the requested JXTA group
and calls the JXTA Module to forward the message to the
interested peer. Method directSend, which requires two
JXTA Module parameters: the message to be sent and a recipient address
The JXTA Module implements the JXTA peer used by J2J (i.e., the necessary path to reach a peer in the JXTA net-
to communicate with the JXTA network. When J2J wants work) calls method sendToJXTA of the JXTA Module, and
to communicate with a specified JXTA peer, it joins one also handles responses and error messages from JXTA. This
of the groups containing the destination peer. The groups method cannot return before delivering such messages (re-
to which J2J subscribes depend on the particular context in turn values or exceptions).
which J2J is used and are not hard-coded in the component. The same approach can be used to make a Jini service
The setup phase follows the same policies chosen to configure communicate with other Jini networks. J2J allows the Jini
the Jini network. service to interact with them as if they were JXTA peers.
We assume that the messages that come from the JXTA When the JXTA Module sends a message to the Jini Mod-
network are standardized and we distinguish between direct ule, we identify the involved service and pass the invocation
and blackboard-based communication. As to direct commu- to it. This is done through method sendToJini, which uses
nication, messages contain the information used by the Jini the object containing the message and the destination for
LUS to find the specific destination service, the name of the the lookup service (i.e., the interface of the service) as pa-
method to be called, and the parameters that have to be rameters. This method returns after the Jini service has
used. In contrast, the structure of blackboard-based mes- returned. If there is a problem with the invocation of the
sages is not fixed by J2J. This distinction comes from the Jini destination service, sendToJini raises an exception.
fact that, in direct communications, the caller knows exactly Besides supplying the functionality to manage the ser-

65
 Figure 3: Working context

vices in the Jini network (such as registering to the LUS is realized by a JXTA network (i.e., all the services in the
and updating the registration), this module also manages external context are JXTA peers).
the blackboard system (i.e., the Javaspace). It allows the IV services comprise, for example, onboard displays, the
JXTA Module to put data (messages) on the blackboard, engine processing unit, a GPS receiver, a mobile phone, and
and reads those tuples that have to be sent to the JXTA the infotainment system. EV services comprise traffic infor-
network. mation services, intelligent street signals, other cars, public
assistance vehicles, and automatic toll systems.
Directory Service J2J enables the cooperation between these two families of
The Directory Service contains pairs of message types and services and is the key component to set the hybrid architec-
JXTA group paths. It helps the Jini Module find the desti- ture. J2J allows a service registered on one side to cooperate
nation of indirect messages from Jini services by providing a with a service registered on the other side. It manages the
way to associate the type of a message with the JXTA groups communications between the inside and the outside of the
interested in it. As already described, messages stored in the vehicle as described in the previous sections, interprets ser-
blackboard by Jini services can be sent to the JXTA net- vice calls, and redirects them.
work. Since the Jini Module is a Jini service, it is triggered Given this context, a first scenario (Figure 4) shows the
by the events that correspond to changes in the Javaspace, case of a message flow from the environment to the vehicle.
and as soon as it understands that a new tuple (message) is The car arrives close to a tunnel; a sensor in the JXTA
available, it uses the Directory Service to discover if there network sends to all the cars near the tunnel a message
are JXTA peers that are interested in that information. This to signal the entrance. The car receives the message and
means that the Directory Service offers a method to find the displays it on the on-board display, turns the lights on, and
destination by supplying a message type, but also ways to the radio off: these are all Jini services.
allow JXTA groups to register their interest in particular More specifically, the tunnel, which is a JXTA peer, sends
message types. a message to the car, exposed by J2J as another JXTA peer.
The message, which is broadcast to the group the car is reg-
4. CASE STUDY istered to, is received by the J2J’s JXTA Module that creates
the object with the request and passes it to the Jini Module.
Figure 3 shows a screenshot of the prototype environment
Since the tunnel does not know the intra-vehicle components
in which J2J works. The scenario comprises two main sub-
interested in the notification, it sends an indirect message
systems: a vehicle and the external environment (simulated
and thus the Jini Module puts the message in the Javaspace
on a local-area network).
by passing the object created by JXTA Module. The Lights,
The vehicle contains J2J and a Jini network (i.e., all the
Radio, and Display are notified by the Javaspace: they lis-
services inside the car are Jini services); the external context

66
ten to the Javaspace for a specified type of objects, which in
Car Service
this case is what sent by the tunnel, and react accordingly.
In the second scenario (Figure 5), we show an example
of message flow from the vehicle to the environment. If we
suppose that the car engine breaks down, the appropriate
Jini service must communicate the fault to the car service
center, which is a JXTA service.
Again, the Engine, a Jini service, builds an engine fault
message (which is a Java object), and invokes the Javaspace Engine Display
to store it. The Javaspace notifies both the Warning Light 5
in the car and the Jini Module. Both these components
are Jini services. J2J uses the Directory Service to find the
right JXTA destination by passing the type of the message
object. The Directory Service replies with the path of the
JXTA destination group. Now, the Jini Module invokes the
2
JXTA Module by passing the message object and the path to JXTA 1
the destination. This module subscribes to the right group Interface J2J
(if it exists), serializes the object into an XML structure, JXTA 4
and broadcasts it to the specified group (which contains the Module JavaSpace
Car Service Center ). In this case, J2J lets the car see the Jini 2
external component as if it were a Jini service. Module
Directory 3
Service Jini
Interface
CAR
Tunnel Sign

Figure 5: From vehicle to environment

them to the driver through some other Jini services. To en-

able direct messages, this service is supposed to have the
Radio same interface and the same lookup information on all the
CAR
vehicles. The communication starts from the service located
1
in a particular car, and the J2J in that car, which receives
Lights
the message, forwards it to the interested JXTA group, so
4 that every other J2J, which has joined the group, receives
4 the message and forwards it to the Jini service on the car.
JavaSpace
JXTA 5. RELATED WORK
Interface J2J 3
4 The integration of different middleware technologies is a
JXTA 2 well-known problem already tackled by several initiatives.
Module Display In this short section, we do not want to address the general
Jini
Module problem, but we prefer to concentrate on those proposals
Directory
Service Jini that resemble our approach.
Interface There are a couple of attempts that aim at integrating
JXTA with other service-oriented technologies. The source-
forge project called JXTA & Web Services Gateway proje-
ct [10] is one of the proposals that are closer to J2J. It pro-
Figure 4: From environment to vehicle poses a solution to connect P2P JXTA elements and Web
services. The gateway advertises services between JXTA
In the third scenario (Figure 6), we have two cars that and Web Services environments and transforms the commu-
share traffic information without using a centralized exchange nication protocols: peers in JXTA and Web Services envi-
entity. We can obtain such an interaction by making two Jini ronments communicate by using SOAP/JXTA and SOAP/-
networks, i.e., the two cars, communicate directly through HTTP transformations. Unfortunately, the project does not
the JXTA network. We want to achieve this goal with a di- seem to be active anymore. Also the JXTA SOAP pack-
rect communication paradigm, i.e., without using the Javas- age [4] provides an integration point between JXTA P2P
pace. On each car, there is a Jini service that can report on networks and Web services and allows the same code to be
traffic conditions and can also get the position of the car, used as a JXTA P2P service and as a conventional Web ser-
maybe by using another Jini service that embeds a GPS re- vice. They do not supply a stand-alone component to make
ceiver. When the service detects certain traffic conditions, the two middleware systems interoperate, but this package
such as a traffic jam, it sends this information to the JXTA allows designers to “wrap” their code and see it as an ele-
network and thus to the other vehicle via J2J. It is also able ment of either framework.
to receive traffic information from other vehicles and present The proposal in this paper imposes a mention also to

67
 cies to select available services and the capabilities of on-
Traffic the-fly negotiation of QoS parameters. More generally, we
J2J Information will continue to investigate SoAs and their applicability to
Directory System important practical areas, such as the automotive domain.
Service
Jini This will be part of our contributions to the SeCSE project.
JXTA Module
Module 2 Jini 7. REFERENCES
JXTA Interface 1 CAR [1] AMIC Consortium. AMIC - Automotive Multimedia
Interface Interface Collaboration. www.ami-c.org/.
3 [2] D. Booth, H. Haas, and F. McCabe. Web Services
Architecture, 2004. www.w3.org/TR/ws-arch/.
JXTA
Traffic [3] D. Gelernter. Generative Communication in Linda.
Interface J2J
Information ACM Transactions on Programming Languages and
JXTA System Systems, 7(1):80–112, 1985.
4
Module
[4] JXTA org. JXTA SOAP Project home page, 2004.
Jini soap.jxta.org/.
Directory
Module [5] I. Krueger. Researcher in Focus.
Service
Jini www.calit2.net/researchers/krueger/index.html.
Interface 5 CAR [6] OSGi Alliance. Osgi web page. www.osgi.org/.
[7] SeCSE Consortium. Project web page.
secse.eng.it/.
Figure 6: from vehicle to vehicle [8] Sun Microsystems. The Network Is the Car, 1999.
java.sun.com/features/1999/06/concept car.html.
[9] Sun Microsystems. Jini Network Technology, 2004.
the Jini car developed by Sun [8], while the service-oriented wwws.sun.com/software/jini/.
paradigm motivates two further references: OSGi [6], which [10] The Gateway Development Team. JXTA & Web
is another example of service-oriented middleware often used Services Gateway Project, 2004.
in the automotive domain, and AMI-C [1], which is an ini- sourceforge.net/projects/j-x-w-s--gw/.
tiative to standardize the messages exchanged among the [11] B. J. Wilson. JXTA. New Riders Publishing, first
components in a car. edition, 2002.

6. CONCLUSIONS AND FUTURE WORK

The paper presents our first experiments with J2J to im-
plement hybrid architectures and demonstrate them in the
automotive domain. A hybrid architecture is an architec-
ture where different portions use different coordination and
communication paradigms to supply services to the other
portions. J2J is the gateway provided to make the different
portions interoperate.
The experiments conducted so far, and partially presented
in this paper, have given interesting results and are encour-
aging us to implement other plug-ins and conceive more het-
erogenous systems to let components communicate in fully
heterogeneous environments.
This implementation of J2J is based on JXTA and Jini,
but we have plans to re-implement it using other service-
oriented technologies: the main principles described in this
paper would remain untouched; we should only tailor the
implementation of the dedicated modules on the chosen in-
frastructures. As shown in Figure 1, the architecture is com-
posed of loosely-coupled modules that can be replaced by
new ones. For instance, if we wanted to make Jini com-
municate with a Web Services, it is enough to replace the
JXTA Module with a new Web Services Module with the
same functionality (i.e., the same interface). These imple-
mentations can also be extended by adding features that do
not concern with the communication paradigm, but address
QoS issues, like performance, trustworthiness, and security.
Our future plans include a more detailed assessment of
J2J by both selecting other case studies and extending the
set of supported frameworks. This also means better poli-

68

View publication stats