Defining Open Software Architectures for Customized Remote Execution of Web Agents.
Agent-based solutions promise to ameliorate Web services, by promoting the modular construction of Web servers, relieving the network from transferring useless data, supporting user mobility, etc. However, existing Web servers do not favor the hosting of agents. This paper proposes a description of agent behavior in terms of its requirements regarding resource utilization (e.g. memory, and disk space), functional services (e.g. system calls), and non-functional properties (e.g. degree of replication, and access control). When formally expressed, these requirements can be used in an automated decision process, which is based on software specification matching techniques. Upon the acceptance of an agent, the host uses these requirements to construct an environment customized to agent's execution. We discuss the benefits of this approach, and how it can be used to promote existing agent-based solutions in the Web framework.
Introduction
Since its appearance in the early 90's, Web has been greatly evolved.
While it was initially intended for the transfer of hypertext documents,
its success and world-wide acceptance led the focus of research interest
into other directions like distributed computing, electronic commerce,
etc. However, from the perspective of intensive use, Web's architecture
was not designed for such employment. Consequently, today Web is
confronted with a number of problems ranging from server saturation
and heavy network tra-c, to access control and verication of client
requests. One of the most prominent solutions for coping with those
problems is the use of software agents, a concept introduced to distributed
systems from the eld of articial intelligence [1]. In common
sense, an agent can be anyone who acts on behalf or in the interest
of somebody else. Consequently, a software agent is a piece of code
endowed with capabilities that allow it to perform some task in the
place of a person or some other piece of code. In the context of this
document we use the term agent to signify an autonomous piece of code
c
1999 Kluwer Academic Publishers. Printed in the Netherlands.
V. Issarny and T. Saridakis
with mobile characteristics, that can be executed independently from
its originator.
Agents permit computations to be executed close to the data, which
results in a decrease of both the network bandwidth utilization, and
the response time. By relaxing the restrictions of permanent location
of computations, they promote distribution of workload among the
components of a distributed system. Finally, agents support the construction
of modular servers capable of adapting to a large variety of
client requests. On the other hand, agents raise major problems on
their potential hosts. Such problems are related to host's capabilities
to provide all the indispensable primitives for supporting an agent's
execution, and to the compatibility of agent's requirements with host's
policies. These execution primitives and policies are the execution properties
that fully describe the agent's behavior in the host environment.
Accepting an agent without supporting all required execution properties
might not be acceptable for the agent's originator, while accepting
an agent whose execution properties are in con
ict with host's policies
might not be acceptable for the host. Hence, before accepting an agent,
the host system should be informed of agent's properties, analyze them
and decide whether or not the given agent can be properly hosted.
This paper presents a framework, in which a host decides on the
acceptance of an agent based on the explicit description of agent's
execution properties. Based on means provided by the software architecture
eld, we describe an agent's execution properties as an
open architecture, which abstractly but unambiguously characterizes
the host environment expected by the agent. Using this architectural
description as the agent's specication, the host is able to detect conicts
with its own policies and to decide whether or not to accept the
agent. In case of agent acceptance, the host also has the information to
customized the execution environment to meet agent's requirements.
The remainder of the paper is structured as follows: next section
gives an overview of the results in the eld of software architecture,
which we use as a base ground for our proposal. Section 3 addresses
the description of open software architectures so as to characterize Web
agents with respect to the execution properties that are expected from
the host environment. The instantiation of a host environment customized
to a given agent, is further addressed in Section 4. Related work
is discussed in Section 5, and we conclude in Section 6 by summarizing
our contribution.
Customized Remote Execution of Web Agents 3
2. Software Architecture
Research in the software architecture domain aims at reducing costs
of developing complex software systems [18, 21]. Towards that goal,
formal notations are being provided to describe software architectures,
replacing their usual informal description in terms of box-and-line di-
agrams. These notations are generically referred to as Architecture
Description Languages (Adls). An Adl allows the developer to describe
the gross organization of a system in terms of coarse-grained
architectural elements, abstracting away their implementation details.
Prominent elements of a software architecture are subdivided into the
following categories:
Components, that characterize a unit of computation or a data
store.
Connectors, that characterize a unit of interaction.
Congurations, that describe a specic, possibly generic, software
architecture through the composition of a set of components via
connectors.
Existing Adls dier depending on the software architecture aspects
to which they are targeted. We identify at least two research di-
rections, which dene dierent Adls: (i) the architecture analysis,
which provides the formal specication of an architecture's behavior
(e.g. [14, 10]), and (ii) the architecture implementation, which delivers
the implementation of an application its architectural description
(e.g. [20, 8]). Both research directions instigate the design and implementation
of CASE tools, based on technologies such as model
checking, theorem proving, and type checking [12].
2.1. Example
To illustrate the use of Adls, we take as an example a primitive Distributed
File System (Dfs). The Dfs is composed of a client interacting
with a (possibly distributed) le server for performing le accesses.
We further assume that the interaction protocol between components
is Rpc-like. Using a simplied version of the Adl used in the Aster
project 1 , the Dfs architecture is given as a conguration made of the
client and le server components, which are bound together using a connector
describing an Rpc protocol. Figure 1 contains the corresponding
declarations.
4 V. Issarny and T. Saridakis
component client =
port
client (typeFormat format);
server (typeFormat format);
functional
typeInt close (typeDsc fd);
interaction
open, close, read, write: client;
key, state: server;
non-functional
state: CheckPoint;
component
port
server (typeFormat format);
functional
typeInt close (typeDsc fd);
read (typeDsc fd,
interaction
open, close, read, write: server;
non-functional
read, write: FailureAtomicity;
connector
role
client (typeFormat format);
server (typeFormat format);
port
client (typeFormat format);
functional
interaction
state: client;
non-functional
Secure, Reliable;
components
C: client;
connectors
com: RPC;
binding
functional
C.open: FS.open; C.close: FS.close;
C.read: FS.read; C.write: FS.write;
com.key:
com.state: C.state;
interaction
C.client: com.client;
com.server:

Figure

1. The architectural description of the Dfs.
Customized Remote Execution of Web Agents 5
The architectural elements described in Figure 1 dene the gross organization
of the Dfs in an abstract manner, and give the associated
execution properties. More precisely, the execution properties of the
Dfs are subdivided into:
Functional properties, which dene the operations that are provided
and called by the architectural elements. The fact that a
functional property is either provided or called by the element
declaring it, is given by the semantics of the port through which
the corresponding interaction is performed. For instance, the client
component calls the open() operation of the leServer component.
Non-functional properties, which characterize the resource management
policies that are provided by the architectural elements.
For instance, the state() and key() operations of the client component
provide the CheckPoint and Authentication properties
respectively; the RPC connector provides Reliable and Secure
communications for all the interactions using it.
Interaction properties, which characterize the communication protocols
that are used for performing the interactions among com-
ponents. In the Dfs example, interactions are achieved using an
Rpc protocol.
Until this point, we have considered the declaration of execution properties
in terms of operation signatures and \names" associated to the
declared operations (e.g. key: Authentication). The type-checking process
typically employed in distributed programming environments to
verify the correctness of bindings among declared operations is based on
pattern matching. However, using pattern matching techniques to verify
the satisfaction of the execution properties requirements placed on
bindings relies on an informal description of the execution properties.
Obviously, we cannot rely on pattern matching performed on \names"
describing the execution properties (e.g. Authentication, RPC, etc), to
verify the correctness of bindings; a slightly dierent interpretation of
the same \name" by each of the interacting sides may cause communication
problems di-cult to track down and resolve. To overcome this
problem, we associate to a \name" a set of formal specications that
serve as its denition. This allows both clean interface declarations
and execution properties requirements resolution based on specica-
tion matching. The next subsection gives an overview of work done
in the area of formally specifying execution properties. For the sake
of conciseness, we do not give examples of formal specications in the
following. The interested reader may refer to [7] for more details on this
topic.
6 V. Issarny and T. Saridakis
2.2. Formal specifications of execution properties
Formal specication of functional properties amounts to specifying the
behavior of the operations required and provided by the architectural
elements. the behavior of operations is specied in terms of pre- and
post-conditions using Hoare's logic (e.g. [17, 23]). In addition to the
straightforward benet of formally specifying functional properties for
verifying the correctness of component interconnection, it further favors
software reuse and evolution. A component may be retrieved
from a component database using the component specication. The
correctness of component substitution within a conguration can be
checked with respect to the specications of involved components.
The aforementioned verications lie in the denition of relations over
specications. These relations dene, in terms of specication match-
ing, correctness conditions for software interconnection, re-use, and
substitution [17, 13, 23].
A non-functional property characterizes a resource management policy
that is implemented by the underlying execution platform. Similar
to functional properties, non-functional ones are specied in terms
of rst order logic (e.g. [9]). These specications refer to operations
that are not explicitly stated in the conguration description of a
software system, but which are provided by the execution platform
or the middleware in a way transparent to the software system. This
allows us to specify any non-functional property in terms of a unique
predicate instead of pre- and post-conditions. Practically, the formal
specication of non-functional properties provide for the verication,
with respect to the declared non-functional properties, of the correctness
regarding the bindings among components. In addition, it enables
the systematic customization of middleware with respect to properties
required by the architectural elements (e.g. [8, 24]). Brie
y stated, middleware
components providing non-functional properties are retrieved
in a systematic way through specication matching between required
and provided properties. The retrieved components are integrated with
the application components using base connectors.
Formal specication of interaction properties has been examined in
[2], where a Csp-like notation is introduced for the formal specication
of the behaviors of components and connectors with respect to their
communication patterns. This allows the correctness verication of a
conguration with respect to the communication protocols that are
used, using the notion of renement given in Csp. In that framework,
a component description embeds a set of port processes that are the
component interaction points, and a coordination process dening the
coordination among ports. The behavior of a component is described
Customized Remote Execution of Web Agents 7
by the parallel composition of port and coordination processes. Simi-
larly, a connector is dened in terms of a set of role processes, which
realize communications among components, and a coordination process
that species the coordination among roles. The behavior of a connector
is described by the parallel composition of role and coordination
processes.
3. Web Agent in an Open Software Architecture
A Web agent denes a software component, which interacts with
components from the host environment. Each of these interactions is
characterized by the functional, non-functional, and interaction properties
associated to it. Thus, a software agent can be specied inside an
open software architecture, which denes a conguration made of the
agent component and the set of open components and connectors that
must be provided by the host environment. Then, a host may safely
accept and execute an agent if the former's capabilities cover the latter's
requirements agent's requirements. The agent's requirements on the
host environment can be precisely dened by providing the following
information for the elements of the agent's open architecture.
The agent component denes:
the functional properties it expects from the host environment
together with the associated interaction properties, and
the functional, interaction, and non-functional properties it
provides.
Each connector characterizes the interaction and non-functional
properties that are to be made available by the host environment
for communication among the agent and the host's components.
Each open component characterizes a software component with
which the agent is willing to interact.
In other words, the agent component abstractly denes the agent's
behavior by exposing how it interfaces with the host. The open components
and connectors provide a description of the execution properties
that should be provided by the host environment.
8 V. Issarny and T. Saridakis
agent component
{ Same as client in Figure 1 {
open component hostFileServer =
{ Same as leServer in Figure 1 {
connector
{ Same as RPC in Figure 1 {
components agent: X; FS: hostFileServer;
connectors Svce: service;
binding { Same as DFS binding in Figure 1 {

Figure

2. Description of an agent accessing a le server in the host environment.
3.1. Example
For illustration, let us give the denition of an open architecture for
an agent that accesses a le server in the host system. Figure 2 gives
a description of the resulting architecture, which is close to the Dfs
architecture discussed in Subsection 2.1 except from the client component
that now corresponds to the agent. Given this description of the
open architecture, the host can safely accept and execute the agent, if
the host is able to instantiate the open hostFileServer component and
the service connector, without violating its own security policies.
3.2. Interpreting agent specifications
So far we have been arguing that architectural descriptions like the
one given in Figure 2 provide su-cient information about an agent's
requirements and a host's guarantees. Based on this information, one
can decide whether an agent conforms with some host's policies, and
whether a host can support all the requirements of some agent. To make
practical use of this approach, we need to associate agents and hosts
with interfaces that describe their execution properties. In addition,
hosts must be provided with a framework that allows them to interpret
such interfaces. This framework should support the analysis of agent's
execution properties, and the reasoning on their combination with
host's policies (e.g. see [3] for a study on the combination of properties
describing security policies).
Customized Remote Execution of Web Agents 9
Ideally, all three types of execution properties (i.e. functional, non-
functional, and interaction properties) should be described using formal
specications. However, common practice has shown that informal
specications provide su-cient guarantees for correct reasoning on
functional properties, like in the case of Omg's Object Transaction Service
(see chapter 16 in [6]). In a similar manner, informal specication
has been shown su-cient for interaction properties, due to the well-known
and widely accepted interpretations of common communication
protocols. In contrast to the above, formal specication is necessary
for non-functional properties, since there does not exist a precise common
understanding of what they represent. Consider for example the
case of an Rpc system: designers have a common interpretation of
the client-server interaction, but the interpretation of the associated
non-functional properties, like the at-most-once failure semantics often
dier.
Given the architectural description that serves as the specication
of an agent, the analysis and reasoning that should be performed by a
host prior to the agent's acceptance, are formally dened as follows:
8C a 2 O(Agent):
MatchPorts(P (C a ); P (C h
8I a 2 I(Agent):
MatchFunc(I a ; I h
MatchNonFunc(I a ; I h
MatchInter(I a ; I h )
The functions and the symbols used in the above expressions, are
dened as follows:
O(Agent) and C(Host, Agent) denote respectively the open components
declared by Agent, and the components available by Host
to Agent, based on trust issues (i.e. the origin of the agent and the
associated level of trust).
I(Agent) and I(Host, Agent) denote respectively the connectors
declared by Agent, and the connectors available by Host to Agent,
based on trust issues.
denotes the set of ports dened in C.
evaluates to true if the set of ports P (which
are requested by the agent) is a subset of the set of ports P 0 (which
are provided by the host). This function can be implemented using
pattern matching techniques.
V. Issarny and T. Saridakis
evaluates to true if the functional properties
of C 0 match those of C. This function can be implemented using
pattern matching, if functional properties are specied in terms
of operation signatures. Otherwise, if functional properties are
formally specied, this function can rely on a theorem prover.
evaluates to true if the non-functional properties
declared by C 0 match those declared by C. This function
should be implemented using a theorem prover, since we have
argued that specication matching of non-functional properties is
mandatory.
MatchInter(I, I 0 ) evaluates to true if for each interaction property
in I there is at least one interaction property in I 0 that matches it.
Similarly to the functional properties, this function can be implemented
using pattern matching. However, for greater robustness
and
exibility formal specications of interaction properties should
be employed. For instance, this may be achieved using a Csp-based
process algebra as proposed in [2]. Then, interaction properties
match if the processes declared in I 0 rene those in I. Let us remark
here that the matching function may be automated using a tool
like Fdr [5].
4. Instantiating Customized Hosts for Web Agents
Given an agent's specication, we have seen how the host environment
can analyze the agent's requirements and reason on their compatibility
with host's policies. In this section we report on the work we have
carried out on using the outcome of this analysis to instantiate an
execution environment customized to the agent's needs. The instantiation
process is based on searching and retrieving host's architectural
elements that match the open components and connectors declared
by an agent. In addition to the execution properties that have been
mentioned thus far, we explicitly take under consideration the usage
of host resources requested by an agent, so as to guarantee that the
agent will be able to execute to completion [19]. For that purpose,
we include an additional clause, named resource, in the conguration
description, in which the resources required for the agent's execution
are declared. Figure 3 gives an example of an explicit declaration of
agent requirements concerning host's resources.
Customized Remote Execution of Web Agents 11
components
agent: X;
connectors
Svce: service;
binding
{ Same as DFS binding in Figure 1 {
resource

Figure

3. Explicit declaration of agent's requirements regarding host's resources.
4.1. Customizing the host environment
Upon the reception of an agent specication, the host rst evaluates
whether it is able to execute the agent based on the agent's originator
and on available architectural elements and resources. If so, the host
noties the agent's originator, which then sends the agent's code. If
the host does not accept the agent, the reason of rejection is sent to
agent's originator. Possible reasons include: insu-cient level of trust
for performing the requested operations, unavailability of architectural
elements, and unavailability of some resources. The agent's originator
may then revise its initial requirements by modifying the open software
architecture constraints, and make a new request to the host.
Considering the agent's specication, instead of treating it as a hostile
entity facilitates its acceptance by the host. However, until now,
we have not considered issues related to the safety of the host, which
in the Web community is considered much more important than the
acceptance of an agent. By accepting an agent relying on the declared
properties, we risk to accept an agent that actually exhibits a dierent
behavior than the one it declares. In that case, the agent may cause
damages to the execution environment. Obviously, for our approach to
be viable, situations like the above should never raise. To assure this,
the execution environment for a given agent is built by the host according
to the agent's specication, which describe the exact interaction
points with the host and their properties. Except from the allocated
resources (i.e. private memory and disk space) which the agent can
access without any restrictions, the only way for an agent to access
the host is to pass through the declared bindings conforming to the
associated execution properties. Hence, the execution environment is
V. Issarny and T. Saridakis
safe for the host since it does not allow the agent to perform any actions
other than those declared in its interface.
Although the host guarantees the correct execution of an agent
whose behavior conforms with the one declared in its interface, no
guarantees exist for the execution of agents whose behaviors deviate
from the declared ones. In some cases the customized environment
may provide \stronger" execution properties than those requested by
an agent. this may occur under two conditions: (i) if the host does
not possess a component providing exactly the property requested by
the agent, but it does possess a component providing a \stronger"
property, and (ii) if the agent is still accepted by the host when the
stronger property replaces the originally requested one in the agent's
specication. Such cases include the allocation of a bigger portion of
resources than the one required, the support for 32-bit encryption keys
while only 16-bit keys were requested, the use of a component that
implements failure atomicity and retry-on-error while only the rst was
requested, etc. Hence, an agent that requested 15.5KB of memory but
actually uses 16KB may nally execute to completion, although this is
not a priori guaranteed.
4.2. Prototype implementation
To experiment the practicality of our approach, we implemented a
prototype for agents written in the Java programming language. The
prototype is a client-server system, where clients contact the server
through Cgi to request the remote execution of one of their agents.
The client-server interaction is decomposed as follows:
The client rst sends the agent's specication to the server, and
waits for approval or rejection notication from the server.
Upon reception of an agent's specication, the server checks
whether it is able to host the agent based on available architectural
elements and resources, as presented in the previous subsection.
Architectural elements available on the host are stored in a software
repository, which is organized so as to be able to identify the
subset of elements that can safely be made available to an agent
with respect to its originator. In the current prototype, we distinguish
between two kinds of agents: those originated from the same
Intranet to which the server belongs, and those originate outside
this Intranet. Availability of architectural elements simply relies on
pattern matching for functional and interaction properties. On the
other hand, checks regarding non-functional properties are done
using specication matching and relies on the tool we developed for
Customized Remote Execution of Web Agents 13
middleware customization [8]. If the server can safely execute the
agent, it computes a unique key for it and reserves the requested
resources; the key is sent to the client together with the acceptance
notication. If the agent cannot be run, the reason for rejection is
notied to the client.
Once the client receives the notication message from the server, it
checks whether the agent has been accepted or not. In the former
case, it sends the agent's code to the server together with the
associated key. In the latter case, the client re-issues the requests
later on, if the reason of rejection is the temporary resource un-
availability. The client may issue a new agent specication if the
reason of rejection is some other execution property.
Upon the reception of the agent's code, the server checks the
agent's identity using the associated key. Once the agent is authen-
ticated, it runs in the customized execution environment, which
only allows the agent to behave in the way that was described in its
specication. In addition, the customized execution environment
provides a private address space for the agent's execution, in order
to conne the consequences of an agent's crash on the failed agent
alone. To assure that an agent respects the execution properties
it has declared in its interface, we have used the SecurityManager
Java class to build the AgentSecurityManager. The AgentSecurity-
Manager surveys the execution of an agent in terms of le system
and network accesses, and resource consumption, and causes an
agent to abort if the agent attempts some unauthorized action.
The prototype is su-cient for evaluating the practicality of our
approach, but it needs to be enhanced from the standpoint of performance
and scalability of the host instantiation process. The software
repository of architectural elements available on the host is actually
composed of a small set of elements, enabling sequential search. Further
work is needed so as to experiment with a large software repository. In
addition, our prototype implementation would obviously benet from
enhanced products based on the Java technology. Products like SUN's
may provide for substantial improvements to our prototype.
14 V. Issarny and T. Saridakis
5. Related Work
The implicit host-agent interaction model that underlies our approach
is similar to the conventional Web agent interaction model, where the
agent describes a process and the host provides an execution environment
(e.g. HTTP-based Mobile Agents [11]). Yet, in our case the
execution environment is prepared by the host according to the agent's
execution properties, which implies that the execution environment
is explicitly dened by the agent, and that an agent and its execution
environment are strongly coupled. From this standpoint our Web
agents resemble Mobile Ambients [4], which dene the mobile code and
its bounded execution environment as a single entity that can move
across Web's administrative domains. However, a mobile ambient is
a modeling entity used as the structural element of a system model
described in the ambient calculus, whereas our Web agent is a set of
execution properties describing the behavior of a piece of software. The
conceptual similarity of mobile ambients and our Web agents suggests
that the ambient calculus can be employed to provide a formal model
of the host-agent interactions described in this paper.
At the practical level, our prototype deals with the safety problems
stemming from inappropriate resource use by mapping an agent to an
individual process. Although this approach assures that problems like
memory address violation will aect only the execution of the agent
that caused them, it restricts severely the number of agents that can
execute concurrently in a given host. A dierent approach is suggested
by Proof-Carrying Code, or PCC for short, which has been used to
support safe execution of mobile agents [15]. In PCC agents carry a
proof that they conform to the host's policies and the host is capable of
verifying the validity of this proof. Hence, agents can be safely mapped
to threads which share their address space with other agents or even
host threads. In this sense, PCC provides an elegant alternative to
the heavy hosting scheme used by our prototype, for the extra cost
of building a proof at the agent's originator and verifying its validity
at the host. However, PCC does not provide any support for nonfunctional
execution properties, nor support of any type for the agent's
requirements from the host. Hence, it is not directly comparable to our
approach. Rather, it should be considered as a alternative approach for
resource management in prototype.
In general, our approach for hosting Web agents does not aim at
replacing existing environments supporting mobile agents. Instead, it
aims at providing a unifying way for describing agents' behavior in
terms of their functional and nonfunctional execution properties, and
considering their hosting based on that behavior. In our framework,
Customized Remote Execution of Web Agents 15
issues related to code mobility and its remote execution in foreign hosts
can be uniformly expressed as execution properties. Execution properties
integrate agent characteristics regarding both mobility support
primitives (e.g. attach, move, and clone [11]), and non-functional requirements
(e.g. authentication, availability, secrecy, and integrity [22]).
Hence, approaches like Mobile Assistant Programming [16] that provides
the underlying framework for creating agents and moving them
to dierent hosts, can gain signicant benets from the presented
approach, in terms of
exible agent hosting.
6. Conclusion
In this paper, we have proposed a framework for reasoning on the
acceptance of agents and for constructing execution environments customized
to agents' requirements. The proposed framework conveniently
adapts existing technology from the elds of distributed systems and
formal specications to the needs of Web agents. Our approach is based
on the description of open software architectures characterizing the
execution properties provided by agents and expected from the host
environment. The proposed framework suggests that hosting an agent
consists of verifying the compatibility of the agent's requirements with
the host's policies, and then customizing the host environment to meet
the approved requirements. Our proposal is easy to use in the simple
case (i.e. the interface declaration for agents that do not have any non-functional
requirements is equally easy to the declaration of a Corba
while it supports the declaration of complex execution properties
without sacricing the functionality, performance, or safety of
the host (i.e. the customized execution environment guarantees both
agent's requirements and host's constraints).
Besides the benets for the agent, the presented approach provides
support for modular constructions of host environments, which results
in
exible and scalable Web servers. The customization of the agent's
execution environment permits the use of resource management algorithms
which allow the host to concurrently serve more than one agent
without signicant impacts on its performance. Moreover, modular
constructions allow the Web servers to apply dierent hosting poli-
cies, according to various criteria based on agent characteristics. As a
consequence, a number of other research issues can be addressed in the
Web agent framework, including how a host can use its current state
for deciding to accept an agent, how to advertise, dispose of, and cost
its resources, what combinations of non-functional properties should
V. Issarny and T. Saridakis
the host accept, how to assure fair treatment of agents with equivalent
requirements, etc.



--R

Intelligent Agents.
A Formal Basis for Architectural Connection.
Dealing with Multi-Policy Security in Large Open Distributed Systems
Mobile Ambients.
Failures Divergence Re
Common Object Services Speci

Achieving Middleware Customization in a Con
Characterizing Coordination Architectures According to Their Non-Functional Execution Properties
Exposing the Skeleton in the Coordination Closet.

A Framework for Classifying and Comparing Architecture Description Languages.

Correct Architecture Re- nement
Untrusted Agents using Proof-Carrying Code
Mobile Assistant Programming for E-cient Information Access on the WWW
The Inscape Environment.
Foundations for the Study of Software Architecture.
Customized Remote Execution of Web Agents.
Abstraction for Software Architectures and Tools to Support Them.
Software Architecture: Perspectives on an Emerging Discipline.


A Framework for Systematic Synthesis of Transactional Middleware.
--TR
customized execution;remote execution;mobility;execution properties;agent;software architecture;specification matching