AGENT-ORIENTED DESIGN OF E-COMMERCE SYSTEM
ARCHITECTURE
Stéphane Faulkner, Manuel Kolp, Adrien Coyette, T. Tung Do
Information Systems Research Unit, University of Louvain,
1 Place des Doyens, 1348 Louvain-la-Neuve, Belgium
Keywords: Agent Systems, Architectural Description Language, Organizational Styles, BDI Agent Model, System
Architecture, E-commerce Application.
Abstract: Agent architectures are gaining popularity for building open, distributed, and evolving software required by
e-commerce applications. Unfortunately, despite considerable work in software architecture during the last
decade, few research efforts have aimed at truly defining patterns and languages for agent architectural
design. This paper proposes a modern approach based on organizational structures and architectural
description languages to define and specify agent architectures notably in the case of e-commerce system
design
.
1 INTRODUCTION
The meteoric rise of Internet and World-Wide-Web
technologies has created overnight new application
areas for enterprise software, including e-commerce
applications. These areas demand software that is
robust, can operate within a wide range of
environments, and can evolve over time to cope with
changing requirements. Moreover, such software has
to be highly customisable to meet the needs of a
wide range of users and sufficiently secure to protect
personal data and other assets on behalf of its
stakeholders.
Not surprisingly, researchers
are looking for new
software designs that cope with such requirements.
One promising source of ideas for designing such e-
commerce software is the area of agent
architectures. They appear to be more flexible,
modular and robust than traditional including object-
oriented ones. They tend to be open and dynamic in
the sense they exist in a changing organizational and
operational environment where new components can
be added, modified or removed at any time.
To cope with the ever-increasing complexity of
t
he design of software architecture, architectural
design has received through the last decade
increasing attention as an important field of software
engineering.
Practitioners have come to realize that getting an
architecture ri
ght is a critical success factor for
system life-cycle and have recognized the value of
making explicit architectural descriptions and
choices in the development of new software.
To this end, a number of architectural description
l
anguages (ADL) and architectural styles (Garlan,
1994) have been proposed for representing and
analyzing architectural designs. An architectural
description language provides a concrete syntax for
specifying architectural abstractions in a descriptive
notation while an architectural style constitutes an
intellectually manageable abstraction of system
structure that describes how system components
interact and work together.
Unfortunately, despite this considerable work
(see e.
g., Shaw, 1996), few research efforts have
aimed at truly defining styles and description
languages for agent architectural design. To fill this
gap, we have defined, in the SKwyRL
1
project,
architectural styles for agent systems based on an
organizational perspective (Do, 2003) and have
proposed in (Faulkner, 2003) SKwyRL-ADL, an
agent architectural description language. This paper
continues and integrates this research: it focuses on
1
Socio-Intentional ArChitecture for Knowledge Systems
and Requirements Elicitation
(http://www.isys.ucl.ac.be/skwyrl/)
372
Faulkner S., Kolp M., Coyette A. and Tung Do T. (2004).
AGENT-ORIENTED DESIGN OF E-COMMERCE SYSTEM ARCHITECTURE.
In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 372-379
DOI: 10.5220/0002646103720379
Copyright
c
SciTePress
an agent perspective for designing and specifying e-
commerce software architecture based on
organizational styles and SKwyRL-ADL. The
structure-in-5 organizational style will be
instantiated to design the architecture of the system
and the specifications will be expressed in a formal
way with SKwyRL-ADL.
The rest of the paper is organized as follows.
Section 2 introduces some perspectives of SKwyRL
insisting on the BDI model, our ADL and
organizational styles. Section 3 describes our agent
oriented approach on e-commerce system
development, including the design of the global
architecture with organizational styles, its formal
specification with SKwyRL-ADL and the
corresponding implementation on an agent-oriented
platform. Finally, Section 4 concludes the research.
2 ADL AND STYLES IN SKWYRL
We have detailed in the SKwyRL project an agent
ADL called SKwyRL-ADL (Faulkner, 2003) that
proposes a set of abstractions that are fundamental to
the description and specification of agent
architectures based on the BDI (Belief-Desire-
Intention) agent model. To help the reader to
understand our ADL specification in the rest of the
paper, we briefly present the main elements of
SKwyRL-ADL including the BDI agent model.
SKwyRL-ADL is composed of two sub-models
which operate at two different levels of abstraction:
internal and global. The internal model captures the
states of an agent and its potential behavior. The
global model describes the interaction among agents
that compose the agent architecture. We will also
introduce organizational styles through the
description of one of them, the structure-in-5, that
will be used later on in the paper.
2.1 The BDI Agent Model
An agent defines a system entity, situated in some
environment that is capable of flexible autonomous
action in order to meet its design objective
(Wooldridge, 1996).
An agent can be useful as a stand-alone entity
that delegates particular tasks on behalf of a user.
However, in the overwhelming majority of cases,
agents exist in an environment that contains other
agents. Such environment is a agent system that can
be defined as an organization composed of
autonomous and proactive agents that interact with
each other to achieve common or private goals
(Kolp, 2001).
In order to reason about themselves and act in an
autonomous way, agents are usually built on
rationale models and reasoning strategies that have
roots in various disciplines including artificial
intelligence, cognitive science, psychology or
philosophy. An exhaustive evaluation of these
models would be out of the scope of this paper or
even this research work. A simple yet powerful and
mature model coming from cognitive science and
philosophy that has received a great deal of
attention, notably in artificial intelligence, is the
Belief-Desire-Intention (BDI) model (Bratman,
1996). This approach has been intensively used to
study the design rationale of agents and is proposed
as a keystone model in numerous agent-oriented
development environments such as JACK (JACK).
The main concepts of the BDI agent model are in
addition to the notion of agent itself we have just
explained:
- Beliefs that represent the informational state of a
BDI agent, that is, what it knows about itself and the
world;
- Desires (or goals) that are its motivational state,
that is, what the agent is trying to achieve;
- Intentions that represent the deliberative state of
the agent, that is, which plans the agent has chosen
for possible execution.
2.2 Internal Model
Figure 1 illustrates the main entities and
relationships of the internal model of SKwyRL-
ADL. The agent needs knowledge about the
environment in order to reach decisions. Knowledge
is contained in agents in the form of one of many
knowledge bases. A Knowledge base consists of a
set of beliefs that the agent has about the
environment and a set of goals that it pursues. A
belief is a finite set of objects, things with individual
identities and properties, that represents a view of
the current environment states of an agent. However,
beliefs about the current state of the environment are
not always enough to decide what to do. In other
words, as well as a current state description, the
agent needs some sort of goal information, which
describes an environment state that are (not)
desirable.
The intentional behavior of an agent is
represented by their capabilities to react to events.
An event is generated either by an action that
modifies beliefs or adds new goals, or by services
provided from another agent. Note that these
AGENT-ORIENTED DESIGN OF E-COMMERCE SYSTEM ARCHITECTURE
373
services are represented in the global model because
they involve interaction among agents that compose
the agent system.
An event may invoke (trigger) one or more
plans; the agent commits to execute one of them,
that is, it becomes intention. A plan defines the
sequence of action to be chosen by the agent to
accomplish a task or achieve a goal. An action can
query or change the beliefs, generate new events or
submit new goals.
Figure 1: Conceptual Representation of the Internal Model
2.3 Global Model
Figure 2 conceptualizes the global model which
describes the interaction among agents that compose
the agent system.
Agent Interface
Effector
Service
Configuration Architecture
require
1..n 1
1..n
1..n
1
1..n1..n
contains
provide
1..n
Sensor
connect_to
Figure 2: Conceptual Representation of the Global Model
Configurations are the central concept of
architectural design, consisting of an interconnected
set of agents. The topology of a configuration is
defined by a set of bindings between provided and
required services.
An agent interacts with its environment through
an interface composed of sensors and effectors. An
effector provides to the environment a set of
services. Then, a sensor requires a set of services
from the environment. A service is an action
involving an interaction among agents.
The whole agent system is specified with an
architecture which contains a set of configurations.
An architecture represents agents by one or more
detailed, lower-level configuration descriptions.
2.4 Agent Architectural Styles
A key aspect to conduct architectural design in
SKwyRL is the specification and use of
organizational styles (see e.g., [KGM01, DFK03] )
These are socially-based design alternative inspired
from models and concepts from organizational
theories that analyze the structure and design of real-
world human organizations.
Belief
Agent
Event
Goal
Plan
Action
post
handle
post query
modify
has pursue
selec
t
1..n
1..n
1..n
0..n
1..n
0..n
1
0..n
0..n
0..n0..n
1..n
1..n
0..n
0..n
0..n
For instance, the agent architecture we propose
in Figure 3 has been designed following the
structure-in-5 organizational style detailed in
[DFK03]. In a few words, the structure-in-5 style is
a meta-structure that defines an organizational
architecture that as an aggregate of five sub-
structures, as described by Minztberg (Mintzberg,
1992). It consists of five typical strategic and logistic
components found in many organizations. At the
base level one finds the Operational Core where the
basic tasks and operations -- the input, processing,
output and direct support procedures associated with
running the system -- are carried out. At the top lies
the Apex composed of strategic executive
components. Below it, sit the
control/standardization, management components
and logistics: Coordination, Middle Agency and
Support, respectively.
3 AGENT ARCHITECURE FOR E-
COMMERCE SYSTEM
E-Media
2
is a typical business-to-consumer
application we have developed using the
architectural concepts explained in Section 2. The
application offers an e-commerce architecture
supporting the creation of information sources that
facilitate the on-line transaction of products,
services, and payments resulting in an effective and
efficient interaction among sellers, buyers and
intermediaries.
This section describes how we have applied the
structure-in-5 style to design the architecture of E-
media and used SKwyRL-ADL to formally specify
2
http://www.isys.ucl.ac.be/skwyrl/emedia
ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING
374
each architectural aspect (belief, goal, plan, action,
interface, configuration, service …) of the
application.
Based on this
architectural specification, we have
implemented the application using JACK, a JAVA
agent-oriented development environment.
3.1 E-Media Architecture
E-Media includes the following features:
- An on-line web interface allows customers to
examine the items in the E-Media catalogue, and
place orders;
- Customers can search the on-line store by
either browsing the catalogue or querying the item
database. An online search engine allows customers
to search title, author/artist and description fields
trough keywords or full-text search;
- If an item is not available in the catalogue,
the customer has the option to order it;
- Internet communications are supported;
- On-line financial transactions including credit
card and anonymity are protected;
- All web information (e.g., product and
customer turnover, sales average, …) of strategic
importance is recorded for monthly or on-demand
statistical analysis;
- Based of this statistical and strategic
information, the system permanently manages and
adapts the stock, pricing and promotions policy. For
example, for each product, the system can decide to
increase or decrease stocks or profit margins. It can
also adapt the customer on-line interface with new
product promotions.
Figure 3 models the architecture of E-Media
using the i* model (Yu, 1995) following the
structure-in-5 organizational style we have
introduced in Section 2 . i* is a graph, where each
node represents an actor (or system component) and
each link between two actors indicates that one actor
depends on the other for some goal to be attained. A
dependency describes an “agreement” (called
dependum) between two actors: the depender and
the dependee. The depender is the depending actor,
and the dependee, the actor who is depended upon.
The type of the dependency describes the nature of
the agreement. Goal dependencies represent
delegation of responsibility for fulfilling a goal;
softgoal dependencies are similar to goal
dependencies, but their fulfilment cannot be defined
precisely; task dependencies are used in situations
where the dependee is required.
As show in Figure 3, actors are represented as
circles; dependums – goals, softgoals, tasks and
resources – are respectively represented as ovals,
clouds, hexagons and rectangles; dependencies have
the form depender dependum dependee.
Figure 3: The E-Media Architecture in Structure-in-5
The Store Front plays the role of the structure-in-5’s
Operational Core. It interacts with customers and
provides them with a usable front-end web
application for consulting, searching and shopping
media items.
The Back Store constitutes the structure- in-5’s
Support component. It manages the product database
and communicates to the Store Front relevant
product information. It stores and backs up all web
information about customers, products and sales to
be able to produce statistical information (e.g.,
analyses, average charts and turnover reports). Such
kind of information is computed either for a
predefined product (when the Coordinator asks it) or
on a monthly basis for every product. Based on this
monthly statistical information, it provides also the
Decision Maker with strategic information (e.g.,
sales increase or decrease, performance charts, best
sales, sales prevision, …).
The Billing Processor plays the role of the
structure-in-5’s Technostructure in handling
customer orders and bills. To this end, it provides
the customer with on-line shopping cart capabilities.
It also ensures the secure management of financial
transactions for the Decision Maker. Finally, it
handles, under the responsibility of the Coordinator
component, stock orders to avoid shortages or
congestions.
As the structure-in-5’s Middle Agency, the
Coordinator assumes the central position of the
architecture. It is responsible to implements strategic
decisions for the Decision Maker (Strategic Apex).
It supervises and coordinates the activities of the
Billing Processor (initiating the stock and pricing
policy), the Front Store (adapting the front end
interface with new promotions and
recommendations) and the Back Store
(parametrizing statistical computing) ensuring that
the system fulfills its mission in an effective way.
AGENT-ORIENTED DESIGN OF E-COMMERCE SYSTEM ARCHITECTURE
375
Finally, the Decision Maker assumes the
Strategic Apex role of the structure-in-5. It defines
the Strategic Behavior (e.g., sales and turnover,
product visibility, hits, …) of the system ensuring
that objectives and responsibilities delegated to the
Billing Processor, Coordinator and Back Store are
consistent with respect to their capabilities.
3.2 E-Media Formal Specification
The architecture described in Figure 3 gives an
organizational representation of the system-to-be
including relevant actors and their respective goals,
tasks and resource inter-dependencies. This model
can serve as a basis to understand and discuss the
assignment of system functionalities but it is not
adequate to provide a precise specification of the
system details. As introduced in Section 2,
SKwyRL-ADL provides a finite set of formal agent-
oriented constructors that allow to detail in a formal
and consistent way the software architecture as well
as its agent components and their behaviors.
Figure 4 shows a high-level formal description of
the Back-Store agent. Three aspects of this agent
component are of concern here: the interface
representing the interactions in which the agent will
participate, the knowledge base defining the agent
knowledge capacity and the capabilities defining
agent behaviors.
SkwyRL-ADL allows to work at different levels
of architectural abstractions (i.e., different views of
the system architecture) to encapsulate different
components of the system in independent
hierarchical descriptions. For instance, in Figure 4
the Back Store agent has three knowledge bases
(KB) and three capabilities (CP), but the description
level chosen here does not specify the details of the
beliefs composing the KB or the plans and events
composing each capability.
The rest of the section focuses on the Back Store
agent to give an example of a refinement
specification with our ADL for each of the three
aspects of the agent: interface, KB and capabilities.
Interface. The agent interface consists of a number
of effectors and sensors for the agent. Each of them
represents an action in which the agent will
participate. Each effector provides a service that is
available to other agents, and each sensor requires a
service provided by another agent. The
correspondence between a required and a provided
service defines an interaction. For example, the Back
Store provides the statistical_info service that the
Coordinator requires.
Such interface definition points two aspects of
an agent. Firstly, it indicates the expectations the
agent has about the agents with which it interacts.
Secondly, it reveals that the interaction relationships
are a central issue of the architectural description.
Such relationships are not only part of the
specification of the agent behavior but reflect the
potential patterns of communication that
characterize the ways the system reason about itself.
Agent:{Back-Store
Interface
Effector[provide(strategic_info)]
Effector[provide(statistical_info)]
Effector[provide(product_info)]
Effector[provide(back-up)]
Sensor[require(stategic_behavior)]
KnowledgeBase:
Product_KB Statistical_KB
BS_System_KB BS_Customer_KB
Capabilities:
Statistical_CP Strategic_CP
Data_Management_CP
}
Figure 4: Agent Structure Description of the Back-Store
Service: {Ask(statistical_info)
sender: Coordinator
parameters: (tw: TimeWindows), (id: Id_product)
reply_with: to: Turnover sl: Sales
receiver: Back-Store
Effect: Add(Statistical_KB,
Achieve(statistic(“today”,“on_product”)
}
Figure 5: A Service Specification
The specification of a service is given in Figure 5.
Each provided or required service is detailed by
specifying the sender agent that initiates the service,
the set of receiver agents that interact with the
sender, the reply-with and content statements that
define the information about which the service
expresses an interaction and optionally a set of
parameters to define the information required to
execute the service. Like the parameters the reply-
with information is represented with a belief or a set
of terms (e.g., function, constant or variable).
Knowledge Bases. A knowledge base (KB) is
specified with a name, a body and a type. The name
identifies the KB whenever an agent wants to query
or modify them (add or remove a belief). The body
represents a set of beliefs in the manner of a
relational database schema. It describes the beliefs
the agent may have in terms of fields. When the
agent acquires a new belief, values for each of its
fields are specified and the belief is added to the
appropriate KB as a new tuple. The KB type
describes the kind of formal knowledge used by the
ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING
376
agent. A Closed world assumes that the agent is
operating in a world where every tuple it can express
is included in a KB at all times as being true or false.
Inversely, in an open world KB, any tuple not
included as true or false is assumed to be unknown.
Figure 6 specifies the Product_KB:
KnowledgeBase: {Product_KB
Kb_body:
product(Id_Prod,Title,Class,Description,Price)
purchase(Id_Card,Id_Prod,Date,Quantity,Pay_Means)
audio(Id_Prod,Artist(+),Compositor(+))
book(Id_Prod,ISBN,ISNN,Author(+),Publisher)
dvd(Id_Prod,Actor(+),Realizator(+))
- the plan body, that specifies either the sequence
of formulae that the agent needs to perform, a
formula being either an action or a service to be
executed;
kb-type: closed_world
}
Figure 6: A Knowledge Base Specification
For instance, the predicate purchase with four
arguments represents the customer and product ids,
the quantity and the means of payment. The ‘+’
symbol means that the attribute is multi-valued.
Capabilities formalize the behavioral elements of an
agent. They are composed of plans and events that
together define the agent’s abilities. They can also
be composed of sub-capabilities that can be
combined to provide complex behavior.
Capability: {Data_Management_CP
CP_body:
Plan Send_Product_Data
Plan Backup_Database
Plan Check_Identification
Plan I nterface_Custom_Id
endEvent update_interface
PostEvent backup
}
Capability: {Statistic_CP
CP_body:
Plan Prov_Turnover_On_Demand
Plan Prov_Turnover
Plan Sales_Average
}
Figure 7: Capabilities Specification
Figure 7 shows the Data_Management and the
Statistical capabilities of the Back-Store agent. The
body contains the plans the capability can execute
and the events it can post to be handled by other
plans or it can send to other agents. For example, the
Data_Management capability is composed of four
plans: Send_Product_Data is used to send product
information to the Store-Front, Backup_Database
backs up all information about customers, products
and sales in order to provide statistical information,
Interface_Custom_Id allows user registration and
Check_Identification checks the customer
login/password when an order is made.
A plan defines the sequence of actions and/or
services (i.e., actions that involve interaction with
other agents) the agent selects to accomplish a task
or achieve a goal. A plan consists of:
- an invocation condition detailing the
circumstances, in terms of beliefs or goals, that
cause the plan to be triggered;
- an optional context that defines the preconditions
of the plan, i.e., what must be believed by the
agent for a plan to be selected for execution;
- an end state that defines the post-conditions
under which the plan succeeds;
- and optionally a set of services or actions that
specify what happens when a plan fails or
succeeds.
Figure 8 specifies the Prov_TurnOver_On
_demand plan that gives the turnover on every
product.
Plan:{Prov_TurnOver_On_demand
Invocation: Achieve(stat_Comput(“today”,“on_produc »))
Context:
¬newproduct(id,“today-15d”)
¬is_done(“prov_turnover_on_demand",Today)
¬day(now =“25”)
Body:
action: compute_turnover(tw, id) as to: Turnover
//with id: Id_product From
Coordinator.Ask(statistical_info).parameter/
//with tw:TimeWindows From
Coordinator.Ask(statistical_info).parameter/
effect: Add(Statistical_Kb, product_turnover(tw, id,to))
service: {Tell (statistical_info)
sender: Back-Store content: to: Turnover
receiver: Coordinator
effect: Add(System_KB,
is_done(“prov turnover_on_demand”,Today))
Add(Statistical_Kb,
stat_comput(“today”,“on_product”, id))
Endstate:
Add(Statistical_Kb,
stat_comput(“today”, “on_product”, id))
Suceed:
action: compute_sales(tw, id) as sl: Turnover
//with tw:TimeWindows From
Coordinator.Ask(statistical_info).content/
effect: Add(Statistical_Kb, product_sales(tw, id, to))
service: {Tell(statistical_info)
sender: Back-Store content: sl: Sales
receiver: Coordinator
Fail:
action: search_set(prov_turnover(),id,tw1))
as set_of to: Turnover
// with tw1 [today-12mth;today] /
action: extrapol_turnover(set_of to) as to1: Turnover
service: {Tell(statistical_info)
sender: Back-Store content: to1: Turnover
receiver: Coordinator
effect: Add(Statistical_Kb,
stat_comput(“today”,“on_product”,id)
}
AGENT-ORIENTED DESIGN OF E-COMMERCE SYSTEM ARCHITECTURE
377
Figure 8: A Plan Specification
The invocation condition is defined with the goal
Achieve meaning that the today’s computation of
product statistics must be true in the current or in
some future state. The agent then determines the
applicability of the plan by analyzing its context.
The context states that the product must be on
sale for at leat 15 days and that the current day is not
the 25
th.
of the month. The plan could not have been
executed today.
The body is composed of a sequence of an action
and a service. The Back-Store first computes the
product turnover from data (id and tw) transmitted
during the execution of the Ask(statistical_info)
service (see Figure 3). The result (to) is then sent to
the Coordinator. The service effect results in
satisfying the goal event.
In case of failure, the Back-Store searches in its
KBs the turnovers that have been previously
computed during the last twelve months in order to
extrapolate a current value. The extrapolation is sent
to the Coordinator. With respect to the case of a
successful plan execution, the service effect satisfies
the goal event but it does not prevent the re-
execution of the plan during the same day.
Configuration To describe the complete
topology of the system architecture, the agents of an
architectural description are combined into a
SkwyRL configuration.
Configuration E_Media
Agent DecisionMaker Agent Coordinator
Agent BackStore Agent StoreFront
Service Ask(strategic_info)
Service Tell(strategic_info)
Service Import(product_info)
Service Export(product_info)
Service Achieve(back-up)
Service Do(back-up)
Instances
DM: DecisionMaker CO: Coordinator
BS: BackStore ST: StoreFront
Askstrat: Ask(strategic_info) Tellstrat:
Tell(strategic_info)
Importprod: Import(product_info)
Exportprod: Export(product_info)
Achievebkup: Achieve(back-up)
Dobkup: Do(back-up)
Collaborations
DM. Askstrat --- Tellstrat.BS;
ST.Exportprod --- Importprod.BS;
ST. Achievebkup --- Dobkup.BS;
End E_Media.
Figure 9: The E-Media configuration
Instances of each agent or service that appear in
the configuration must be identified with an explicit
and unique name.
The configuration also describes the
collaborations (i.e., which agent participates in
which interaction) through a one-to-many mapping
between provided and required service instances.
Part of the E-Media configuration with instance
declarations and collaborations is given in Figure 9.
To allow dynamic reconfiguration and
architecture evolvability at run-time, configurations
separate the description of composite structures from
the description of the elements that form those
compositions. This permits to reason about the
composition as a whole and to reconfigure it without
having to examine each component of the system.
3.3 E-Media Implementation
Based on the structure-in-5 architecture described in
Section 3.1 and the formal SKwyRL-ADL
architectural specification overviewed in Section
3.2, the E-Media application has been implemented
with JACK (JACK), a BDI agent-oriented
development environment for JAVA. We briefly
describe the E-Media implementation to illustrate
the role of the agents and their interactions.
Figure 10: E-media Main Interface
When an on-line customer gets connected to
E-media, an instance of the Front-Store is created to
display the interface depicted in Figure 10. It allows
the new coming user to register (1). The Back-Store
handles the information provided by the user and
checks its validity (2). If the access is granted, the
user can purchase products on E-Media by adding
catalogue items to the shopping cart (4) managed by
the Billing-Processor. At any time the user can use
the navigation-bar (3) to switch from one section of
the website to another. Promotions (5) and best
sales (6) are part of the strategic behaviour objective.
The promotions policy is initiated by the Decision-
Maker based on the strategic information provided
by the Back-Store. The Coordinator chooses the best
ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING
378
promotions and consequently adapts the Store Front
layout. The Coordinator acts similarly for the best
sales: the Back-Store computes the five best sellers
and the Coordinator accordingly updates the Store-
Front.
Figure 11: Interface of E-Media DVD Section
Figure 11 describes the Store-Front interface
for the DVD section, i.e., when the “DVD” button of
the navigation-bar is activated. To search E-Media
DVD catalogue, the user must fill at least one field
of the search engine (1). The Store-Front sends the
query parameters to the Back Store which provides
the results back to the Store-Front (2). At any
moment during the session, the user can click on a
product (best seller, query result, shopping cart…), a
request is then sent to Back Store to provide more
information on this product (3). When the user
activates the billing process, the Billing-Processor
displays the items in the shopping cart and computes
the total and sub-total for each product. It then
checks the validity of the user’s credit card number.
4 CONCLUSION
Nowadays, software engineering for new enterprise
application domains such as eBusiness is forced to
build up open systems able to cope with distributed,
heterogeneous, and dynamic information issues.
Most of these software systems exist in a changing
organizational and operational environment where
new components can be added, modified or removed
at any time. For these reasons and more, agent
architectures are gaining popularity in that they do
allow dynamic and evolving structures which can
change at run-time.
Architectural design has received
considerable attention for the past decade which has
resulted in a collection of well-understood
architectural styles and formal architectural
description languages. Unfortunately, this work has
focuses on object-oriented rather than agent-oriented
systems. This paper has described an approach based
on organizational styles and an agent architectural
description language we have defined to design
agent architectures in the context of e-commerce
system engineering. The paper has proposed a
validation of the framework: it has been applied to
develop E-Media, an e-commerce platform
implemented on the JACK agent development
environment.
REFERENCES
Bratman, M . E., Intention, Plans and Practical Reason.
Harvard University Press, 1987.
Faulkner, S. and Kolp, M., Towards an Agent
Architectural Description Language for Information
Systems. In Proc. of the 5th Int. Conf. on Enterprise
Information Systems (ICEIS 03), Angers, France,
April 2003.
Do, T. T., Faulkner, S. and Kolp, M., organizational
Multi-Agent Architectures for Information Systems. in
Proc. of the 5th Int. Conf. on Enterprise Information
Systems (ICEIS 2003), Angers, France, April 2003.
Garlan, D., Allen, R. and Ockerbloom, J., Exploiting Style
in Architectural Design Environments. In Proc. of
SIGSOFT’94: Foundations of Software Engineering,
New Orleans, Louisiana, USA, Dec. 1994.
JACK Intelligent Agents. http://www.agent-
software.com/.
Kolp, M., Giorgini, P. and Mylopoulos, J., An Orga-
nizational Perspective on Multi-agent Architectures. In
Proc. of the 8th Int. Workshop on Agent Theories,
architectures, and languages, ATAL’01, Seattle, USA,
Aug. 2001.
Mintzberg, H., Structure in fives: designing effective
organizations. Prentice-Hall, 1992.
Shaw, M. and Garlan, D., Software Architecture:
Perspectives on an Emerging Discipline, Prentice Hall,
1996.
Yu, E., Modeling Strategic Relationships for Process
Reengineering, Ph.D. thesis, Department of Computer
Science, University of Toronto, Canada, 1995.
Wooldridge, M. and Jennings, N.R., editors. Special Issue
on Intelligent Agents and Multi-Agent Systems.
Applied Artificial Intelligence Journal. Vol. 9(4),
1996.
Louis, R., 1999. Software agents activities. In ICEIS’99,
1st International Conference on Enterprise Informa-
tion Systems. ICEIS Press.
Smith, J., 1998. The book, The publishing company.
London, 2
nd
edition.
AGENT-ORIENTED DESIGN OF E-COMMERCE SYSTEM ARCHITECTURE
379