Architecting Frameworks for Specific Applications with RM-ODP
Ana Paula Gonçalves, Sandro Antônio Vicente, Dib Karam Jr, Moacyr Martucci Jr
Computing Engineering and Digital Systems Dept – Escola Politécnica da USP
apaulacg@uol.com.br, sandro.vicente@poli.usp.br, dib@poli.usp.br, moacyr.martucci@poli.usp.br
Abstract
Today, distributed systems are commonly used inbusiness enterprises in practically all market sectors. But
such systems are characterized by their huge complexity
due to physical distribution, lack of synchronization,
heterogeneity, external parties and the very businesslogic related to the system itself. RM-ODP appeared as
an interesting resource to assist the designing ofarchitectures for distributed systems, providing means tocapture business needs, distributed processing systems
architecture, semantics of processing, and choice oftechnologies. This paper presents three different
experiences in modeling architectures using RM-ODP: aproposal for use of RM-ODP for the development of
convergent applications, a generic architecture for CRM
systems and a framework based on ODP for the
integration among different computer architectures.

1

Introduction

Nowadays, distributed systems became mature enoughto be commonly used in business enterprises inpractically all market sectors. Besides their businesscomplexity, such systems are characterized by physicaldistribution, lack of synchronization and heterogeneity
due to the fact that they are composed of a plethora ofdifferent applications and devices. In addition, such
systems are also affected by external elements, such as
telecommunication networks, 3rd party systems, etc.
Hence, when a distributed system is being designed, it
is necessary to assure that its architecture will provide theright levels of service, supporting interoperability,
scalability, security, heterogeneity, and all other aspects
that characterize such systems.
RM-ODP (Reference Model – Open Distributed
Processing) appeared as an interesting resource to assist
the designing of architectures for distributed systems,
providing means to capture business needs, distributed
processing systems architecture, semantics of processing,and choice of technologies, all in a consistent andcomplete manner. It focuses on how to capture thecomponents, their interrelationships, and formal
semantics of processing aspects of an open distributed
processing system.
The paper objective is trying to show how the RMODP can be considered a complete modeling tool,
presenting an overview for three generic cases. Each casefocuses a different set ofviewpoints, chose according its
importance in application. The complete set of the
viewpoints were used considering the three presented
cases together.
These experiences in modeling architectures
addressing specific applications domains carried out by
integrants of the Computing Engineering and Digital
Systems Dept of Escola Politécnica da USP (University of
Sao Paulo), which have been driving early researches inthis area in Brazil.
This paper is organized as follows. Section 2 presents
a proposal for use of RM-ODP aiming the developmentof convergent applications. Section 3 presents a genericarchitecture for CRM (Customer RelationshipManagement) systems, which fits CRM strategies into
the ODP (Open Distributed Processing) enterpriselanguage. Section 4 outlines a framework based on ODP
for the integration among different computerarchitectures. Finally, section 5 concludes the paper.

2

Designing technologically convergent
applications using RM-ODP

This section presents a proposal for use of RM-ODP
aiming the development of convergent applications. But
it is important first to clarify the meaning of the term
“convergent”.
The term technological convergence is often mistaken
for interoperability. The difference among them is that
“interoperability” means capability to work with anotherautonomous systems or applications. Technologicalconvergence means adaptation of services to different
communications medias through the use of networks andterminals designed to bear such services, transparently
providing users with access to these services’information
and applications. So these services are carried out usingany network, any communications channel and providing
a coherent human-interface with appropriate quality.
This demands fundamentally capabilities of mobility,
portability of applications and content, andinterconnection and interoperability among platforms
and operators. Any application involving several
technologies, such as: digital television, mobile Internet,
videoconference, telephony, interactive broadcasting, etc,
can be considered a convergent application [1].
An appropriate solution in order to develop
convergent applications employs the model of distributed
computing using the Internet, client-server architecture
in a decentralized networked environment, andindependent and autonomous devices. Generally, this
distributed computing model uses mainly the TCP/IP(Transmission Control Protocol - Internet Protocol
protocol, for the communication among devices, using
differentarchitectures,operatingsystems
andapplications. Distributed object architectures provides
suitable means to apply the model of distributed
computing, enabling the transparent integration of
distributed services upon software architectures,
hardware platforms and networks [2][3].
Figure 1 presents an overview of architecture ofconvergent applications based on three different
technologies: the Internet, mobile telephony and digital
television. The integration among these threetechnologies is possible only through the use ofstandardized protocols and distributed objects. Thus, next
section presents how convergent applications can be

Protocol andObject distributed

The computational viewpoint is responsible for thefunctional decomposition in terms of objects and their
computational interfaces, which must be specified for thedevelopment of convergent applications [4]. Figure 2
presents the objects and interfaces and they are detailed
as follows.
- User object: represents communication channel
through which a user may use to send or receive
information and services. Examples of instances ofthis object are: PDAs (Personal Digital Assistants),
mobile telephones and digital television. This object
has interface with Connection Object;- Connection object: is the object responsible forconnection services among the user object and theservice required, according to the type ofcommunication channel. Examples of instances ofthis object are: Internet connection via TCP/IP,
mobile phone connection via WAP (WirelessApplication Protocol), digital television connection
using image, sound and data compression anddecompression techniques through the use of DVB-T(Digital Video Broadcasting - Terrestrial) standard.
This object has interface with Convergence Services
Objects;- Convergent services object: these objects represent
convergent services, so they can be considered an
application
framework
integrating
different
convergent services and obtaining services andinformation from different locations.
User Object

Connection Object

User
Communication
Channels

Connection
Services

Convergence Services Objects

Digital TV

Application 3
Internet

MobileApplication 5

Computational viewpoint

Application 2

Application 1

Application 4

2.1.

Services
Middleware

Information andServices

Phone

Application 6

Application 7

Figure 2. Computational view of objects for convergent
applications

developed using the RM-ODP.
Figure 1. General view of architecture of convergent

2.2.

Engineering viewpoint

applications based on three different technologies

The following subsections present an overview ofarchitecture for convergent applications using thecomputational, engineering and technology ODP
viewpoints. The enterprise and information viewpoints
are not addressed in this article because it aims topropose a generic architecture, able to be applied overdifferent enterprise and information models.

The engineering viewpoint model provides support
for the execution of the computational model [4]. Figure
3 presents a simplified architecture in the engineering
viewpoint, detailed as follows.

Convergence
Services

User
Integration
Interfaceof different
technologies

Stub

Stub

BinderBinderProtocolP1

P2

ProtocolConnection
P3

P1

P2

P3

Figure 3. Simplified architecture of convergent
applications in the engineering viewpoint

When an user object requires a service orinformation, a stub object will provide functions to
support transparency in the request of a service and its
response. The binder object verifies compatibility amonginterfaces and keeps the connection integrity of theservice request and its response. The protocol object
interacts with protocols of the other different convergent
services. For example, in figure 3, protocols like P1, P2
and P3, transparently obtain the information or service
from the binder and stub objects of the instances of theconvergent services objects. The integration among
Internet services, mobile telephony and digital television,for example, is possible through the use of interfaces
concerning different technologies. An example for theuse of this architecture would be a request of a service
from a digital TV device (user in figure 3) that would
enable a content search in a database server (convergence
service in figure 3) using the Internet (connection infigure 3), whose answer would be delivered to the user’s
mobile phone (user in figure 3).

2.3.

Technology viewpoint

The technology viewpoint specifies the software andhardware components of the application [4]. Suchtechnologies for convergent applications were proposedin light of studies on well-grounded technologies,
availability of tools to support development and ease ofdevelopment.
The platform generally adopted is Java, because it
provides APIs (Application Programming Interfaces) andfacilities for the development of applications using

different communications medias and devices, such as
the following:- Internet integration interface: J2EE (Java 2
Plataform Enterprise Edition) platform for thedevelopment of distributed objects allows both theuse of an IDL (Interface Definition Language) with
CORBA (Common Object Request Broker
Architecture) and XML (eXtensible Markup
Language) with SOAP (Simple Object AccessProtocol);- Mobile telephone integration interface: use of thetechnology MIDP (Mobile Information Device
Profile). The main characteristics of MIDP
concerning software are the use of specific Java APIs
for limited devices, as for example: java.lang.*classes, java.util.* classes, java.io.* classes, HTTP
(hypertext transfer protocol) 1.1 protocols and
HTTPS (hypertext transfer protocol security) X.509
protocols. Characteristics concerning hardware are
the screen size of 96x64, 1-bit intensity, black andwhite, 4,096 colors or touch-screen enabled;- Digital television integration interface: assuming theuse of the European standard DVB-T, the MHP(Multimedia Home Platform) can be employed. Its
main characteristics concerning software are the useof Java APIs like, for example: Personal Java, java
TV API, Java Media Framework and DVB API
extensions. Characteristics concerning hardware are
MPEG-2 (Moving Picture Experts Group – 2)
reception, screen resolution of 720x576 pixels and“true color” model.
Figure 4 presents the technology layers proposed forthe development of convergent applications. The layerthat represents the facilities of the applications’implementation is the main concern and is shown in the
figure 4 with shaded blocks.

3

Designing a CRM architecture with ODP

In this section, an overview of a generic architecture
for CRM systems is presented in light of the enterpriseand information viewpoints. At first, the main idea of
CRM concept is stated, as well as the concept of CRM
Ecosystem [5], which is essential to drive the modeling of
the CRM architecture in an enterprise context.

App

Proprietary

App

App

Open API(MIDP, MHP)

API
Value
added
middleware

Internet

Java Profile
JVM

OPERATIONAL CRM

BackOfficeAppterminals, etc [6]. These three functional groups working
together establish a CRM Ecosystem, which is depicted
in figure 5.

ERP

ANALYTICAL CRM

LegacySystems

SCM

CORBA

Java Virtual Machine

Front
OfficeConfiguration
Customer
Service

MarketingAutomation

Sales Force
Automation

Data
Warehouse

Customer
Datamart

Product
Datamart

Category
Management

MarketAutomation
Campaign
Management

convergent applications

CustomerInteraction

Operating system

Figure 4. Technology layers for the development of

Data
Mining

Voice
IVR, CTI, ACD

Internet

Wap

E-MailFax

LetterDirectInteraction

COLLABORATIVE CRM

Figure 5. The CRM Ecosystem

3.1.

Customer Relationship Management CRM
3.2.

CRM is a marketing concept whose goals are theacquirement of new customers and the loyalty of existing
ones. These goals are reached establishing a friendshiprelationship with customers, employing one-to-one
interaction, to achieve complete knowing of them,predicting their behavior and habits [6]. Technology
supports one-to-one customer interaction by means ofautomated and semi-automated contact points providing
accessibility and distribution of information to thecustomers [7]. Interactions among contact points andfront-office applications (such as sales, marketing andcustomer services) implement CRM process.
CRM is implemented through the automation ofhorizontally integrated business processes involving
front-office customer touch points via multiple,
interconnected delivery channels [5]. We can distinguishthree large functional groups necessary for a CRM
architecture: operational, collaborative and analytical,
where the operational CRM can be divided into frontoffice and back-office. Front-office functions are
performed by customer service, marketing automationand sales automation applications. Back-office are
performed by Enterprise Resource Planning (ERP)systems, Supply Chain Management (SCM) systems andlegacy systems. Analytical CRM comprises decisionsystems and tools for business performance analysis suchas: data warehouses, data marts and data mining tools.
Collaborative CRM comprises elements used as customer
channels, such as: IVR (Interactive Voice Response)
devices, CTI (Computer Telephony Integration) systems,
ACDs (Automatic Call Distributor), web sites, agentsEnterprise viewpoint

In this subsection, a generic architecture for CRM
systems is modeled using the ODP’s enterprise viewpoint[4]. This viewpoint is the basis to understand the overall
structure of the CRM architecture in terms of whichelements take part in the architecture and which roles
they perform.
In the enterprise viewpoint, the entire CRM system ismodeled by means of business objects, or enterpriseobjects, each one performing the roles necessary for theactivities concerning those functional groups that
perform the CRM process: Collaborative (CO),FrontOffice (FO), BackOffice (BO) and Analytical (AN).
In addition, the customer who interacts with the CRM
system is also considered a role in the enterprise
viewpoint because it represents an entity external to the
CRM system. Business roles and the interactions among
them are depicted in figure 6 and detailed as follows.
- Customer: performed by objects that represent the
CRM system’ customers, concerning policies related
to customers location, current situation, preferences,
etc. Customers may interact with objects performing
CO role;- CO: performed by objects representing theapplications and devices, or groups of applications
and devices that interact directly with the customers,such as IVR devices, human agent workstations, webconnections, etc;
- FO: performed by objects which perform activities
such as: customer care services, contact

--management, telemarketing and sales force
automation;
BO: performed by objects responsible for the core
activities of the business where the CRM system isapplied to, concerning ERP systems, legacy systems,
SCM systems and operational databases;
AN: performed by objects responsible for the
analytical CRM which perform activities that give
intelligence to the CRM process, providing the otherfunctional groups with policies so that the customer
expectations could be better fulfilled. This role
extends to data warehouses, data mining applications
and OLAP (On-Line Analytical Processing) tools.

Analytical:AN
Back-office:BO
Front-office:FO
Collaborative:CO

Customer

Figure 6. CRM communities in the enterprise viewpoint
The roles detailed above also define communities,
each one containing sets of objects performing the samerole. The interoperation among these communities is
crucial to the one-to-one process and, consequently, to
the CRM objectives.
So, all those communities must comprise a federation
whose primary objective is to provide a one-to-one
service to the customer. A service can be further modeled
as a set of interactions among the CRM communities. For
example, the analytical community (AN) may detect abusiness opportunity and request the telemarketing
automation system (FO community) to contact somecustomers to offer a product employing a customer
channel, such as: voice, e-mail or postal delivery (COcommunity). For the customers that accept the offer, theback-office community (BO) will process their orders.
Anyway, the analytical system will process the customer
responses in order to learn a little bit more about themfor future contacts. So the CRM goals will be achieved.

3.3.

Information viewpoint

In this work, the information viewpoint is used tomodel the general structure of information concerning
the CRM system. This viewpoint may deal with theinvariant, static and dynamic information schemas, but
in the case of the generic architecture for CRM systems,
the invariant schema is more relevant to provide a class
diagram representing the structure of the information
essential for a CRM process. Thus, figure 7 depicts suchclass diagram, which identifies the following information
classes concerned with the CRM process:- InfComponent: models information concerning thedevices used in the communities CO and FO, where
specifics characteristics of each of these communities
are carried out by the specializations InfChannel and
InfApp, detailed below.
- InfChannel: models information concerning thetouch-points (or channels) with customers, such as:
IVR (Interactive Voice Response) devices, telephonicbranches, web-server connections, etc;
- InfApp: models information concerning front-officeapplications, such as help desk, sales force
automation systems and market automation systems;- InfExAgent: models external entities (probably acustomer) in touch with the CRM system in a
specific moment, such as during a phone call for thecompany’s call center;- InfInteraction: models associations involving
external entities, customer channels and front-officeapplications, representing a well defined interactionof a customer with the CRM system;- InfContact: models groups of inter-related
interactions;- InfCustomer: represents each customer, comprising
every piece of information related to him or her;
- InfProduct: represents products and/or services
offered to the customers;- InfDeal: models the relationship among a customer,
products (or services) and the contact (group ofinteractions) that drawn the customer to the product;- InfCampaign: models campaigns about products,
relating products to groups of customers likely toappreciate them, and involving appropriate frontoffice applications to offer these products to thecustomer.
In the context of a CRM system, the static anddynamic schemas are not so general as the invariant
schema. The static schema defines specific states for each
instance of the information classes identified in theinvariant schema. For example, an instance of the class
InfCanal, representing a telephone line, may have an
attribute status that can be idle, busy, disabled and fault.

These values comprise states represented by the static
schema.
Dynamic schemas can be used to define statetransitions among the states identified in the static
schema. For example, the behavior of a telephonic line
can be described by a state diagram involving the states
idle, busy, disabled and fault, as well as the events andconditions that trigger transitions from one state toanother.
InfComponent

InfExAgent

InfChannel

InfAppInfInteraction

InfCampaign

InfContact

enterprises, collaborations, mergers, acquisitions and theInternet (a totally unstructured data source), solving
problems concerning heterogeneity and distribution. It is
not a wish, is a necessity around the computational world
because the information is an asset more valuable thanthe company’s facilities. By this way, accomplishing thiswhish is a complicate task and it is a challenge fordevelopers and researchers [9].
In this context we are developing a multipurpose
middleware, whose task is to allow integration andprovide interoperability to distributed computerarchitectures. This middleware has been desiged to be
used like an applications integrator providing
interoperability between these applications. It is anecessary step for convergence between technologies.
RM-ODP brings a general architectural view for thismiddleware as well as global conceptual definition,
analytical structure and standard specification. Thissection focuses on business information (information
flows and structures, restrictions and standards) andcomputational viewpoint (it is a real need for the system).

InfDeal

4.2.
InfCustomer

InfProductFigure 7. CRM static information schema

4Middleware for integration
computer architectures

amongEnterprises applications have a large range ofindependent systems sometimes without interactions or
fragile relationship [8]. On the other hand, dynamic
advances in IT (Information Technology) increased
complexity and customers demand for distributed
information shown necessary a new way to manage IT
systems.

4.1.

Distributed processing problem

The relationship between different applications may
be transparent, receiving and sending requests without
new codes or additional application.
All companies have distributed processing
applications without interactions allowing double effort.
Today, middlewares (management, availability and basic
communication layer) have functions to interact withapplications available for these stand alone systems.
The companies’ wish is to allow systems anddatabases integration within enterprises and acrossEnterprise viewpoint

It outlines a middleware architecture that will
integrate independent and different applications, being
capable to access distributed data and execute distributed
tasks. This middleware will provide information
wherever, however and whenever the user request.
Therefore, this middleware architecture will be a
distributed programming model and will allow
communication for all applications in several scenarioswith flexible customization and configuration.
At the enterprise viewpoint, this architecture will
install a component in existing applications that willintercept the requests and send them to the new
middleware. When receiving the requests, thismiddleware will provide the best way available to attend
it. This execution will be transparent to the users, i.e., therequester and executor are not publicly visible. A given
application will take part of a new system comprising
several architectures. Therefore, this application will be
an object for this new system with its functions and it
will access and accept others applications’requests.
This architecture improves the use of a corporative
system, assuring information integrity, quality of service(QoS) levels and availability.

4.3.

Information viewpoint

By information view, the component installed in an
application responsible for the interception of requests
and redirection to the middleware is the request object.

Another component, also installed in the existing
application, will receive the answer and will send it to
the final user. It is a reception object. This mechanism isshown at figure 8.

APPLICATION 1

performed, which compels the architects and designers toappropriately reason what to specify. Once a goodarchitectural specification is ready, it is possible toprovide an implementation for it using well-grounded
technologies, basing on the ODP technology viewpoint.

APPLICATION N

6References[1] Presidencia Española de la Unión Europea, El Potencial de laConvergencia Tecnológica en el Desarrollo de la Sociedad dela Información, Colegio Oficial ingenieiros de telecomunicación.,
2002.
[2] H. Balen, “Distributed Object Architectures with CORBA”,
Sigs Books, Cambridge University Press, 2000.

middleware

Figure 8. Information flow in the new architecture
The middleware receives, dispatches and sends therequests and answers to its users transparently. It is a way
to accomplish heterogeneous management.
An existing architecture connected to this middleware
will receive and send requests, integrating independent
systems with different architectures without different
gateways or bridges between each system.

5

Conclusion

The different approaches presented in this article
show how RM-ODP can be properly used for the
specification and modeling of distributed systems
targeting different problems, which restates how RMODP may be malleable for architecting of distributed
systems.
In the three cases presented, the studies show a weak
points in RM-ODP when it was used for modelingsystems where one or more blocks are legacy systems.
Furthermore, for the implemetation the concern is thelack of compatibility between RM-ODP and distributed
objects architectures like CORBA and J2EE.
Despite de fact that RM-ODP is not proper toformally specify an entire system, which would require to
dig into its implementation details – in fact, such deed
would be at least impracticable –, RM-ODP isappropriate to determine the architectural patterns
necessary to drive the further development of the system,
once RM-ODP modeling requires a good understandingof the interactions of the system with its environment, theelements
thatcomprisethesystem,theirinterrelationships and the activities that must be[3] G. Blair, G. Coulson, N. Davies, “Standards and Platforms forOpen Distributed Processing”, Eletronics & Communication
Engineering Journal, p.123–133, 1996.
[4] ISO/IEC 10746-1, Information technology – OpenDistributed Processing – Reference model: Overview, 1st edition,
1998.
[5] E. Shahnam, "The Customer Relationship Management
Ecosystem", Delta Research Reports, 2000.
[6] A. P. Gonçalves, “Proposta de Arquitetura Aberta de Central
de Atendimento”, Master’s dissertation, EPUSP, 2001.
[7] J. D. Wells, W. L. Fuerst, J. Choobineh, “Managing
Information Technology for One-to-one Customer Interaction”,
Information & Management, 1998.
[8] M. Feridum, G. D. Rodosek, “Management of IT Services”,
Computer Networks, v.43, pp 1-2, 2003.
[9] K. Geihs, “Middleware Challenges Ahead”, Computer, pp 2431, June 2001.

Acknowledegements
The authors wish to thank the support of the UNILINS Escola de Engenharia de Lins - Lins, Brazil.