Common Architecture Issues related to CoABS and
Object Services and Consulting, Inc.
This listing was compiled based on the ALP
Workshop held in Tampa on 8-10 December 1999.
The ALP architecture needs to evolve to meet its
FY99 and FY00 objectives of connecting to C2 execution environments and
real data sources, supporting alternate worlds and contingency monitoring,
interoperating with other systems (secret or allies or other logistics
systems) and scaling to 100s of sites. From the ALP Workshop,
this is a listing of some of the important ALP architectural issues that
need resolution within the next six months and that are related to parallel
CoABS agent architectural concerns:
mapping the cluster architecture to an agent architecture
- the benefit would be to identify missing ingredients of each kind of
architecture and see how to augment each
lite-weight and still functional - the claim
for both cluster and agent architectures is they are lite-weight but also
that they provide some way to insure that architectural systemic properties
like security pervade the system and are still customizable. What
needs to be centralized about ALP and what decentralized? e.g., propagation
of policy information from a single point or from oversight roles.
Both the CoABS and ALP architectures need better answers in this area.
We must say more about the architecture than that it can be specialized
enterprise management - related to the above
problem and how to insure we can pass policy down.
scaleable - both CoABS and ALP need scaleable
architectures to meet global DoD needs. There are a number of areas
and assumptions being made about scaleablilty that need to be captured,
examined, and solution approaches need to fit into the architecure.
survivable ALP - ALP's architecture must be
survivable to various kinds of threats. [By the way, we have expertise
in survivability and a selected but not funded proposal to insert survivability
into an ATAIS architecture, which could be ALP. Todd, are you interested?]
interoperable with external systems - ALP
must wrap existing data sources, logistics systems, interoperate with ALP
systems at different security levels and with logistics systems from suppliers
(CLS = contract logistics support, issue of fairness in marketplace, comparison
shopping, eBrokers) and host nations. More work on declarative wrapper
policies is needed. A view of ALP as not just a fine grained architecture
but also an interoperability architecture with migration paths and coexistence
relations to existing logistics planners is probably going to be important.
Moreover, interoperability not just with existing legacy but new developements
is worth considering now: the Common Schema/ALP relationship and
CoABS/ALP relationships are cases in point.
logical data model - what extensions are needed
for the current ALP LDM to support behavior and rules; would LDM be useful
beyond ALP; how does it map to other data models. How do we characterize
identity wrt time, replicas, aggregations, ...
ontologies - how do these fit into ALP
business rules - ignoring the term business
rules, ALP clusters and plugins (and agents) need a representation
for rules and constraints. [OMG needs a rules service too.] Is a
CLIPS plugin the answer? Ideally, a way should be found to define
rules/constraints as part of object/component/cluster behavior, and have
the evaluation/monitoring of those rules be part of the overall programming
(object) model and communication model (e.g., integrated with events) used
for the system, rather than some kind of separate "service" or "plug-in",
because these rules/constraints form too much of an essential part of the
definition of these systems to be relegated to "add-on" status. There
are some hybrid (mixing imperative and declarative) object model approaches
that can make sense.
agent communication language - where would
we use this in ALP negotiations?
alternate worlds - bookkeeping for distributed
alternate worlds needs to be worked out.
resource starved planning - a special case
of planning is when multiple plans (different regional conflicts) compete
for resources and require priorities and replanning. Similar to QoS.
execution monitoring - the architecture needs
to be extended to propagate changes back to trigger replanning. It
need to model mission phases: force generation, sustainment, transportation,
specialist architecture - one of the most
interesting aspects of both cluster and agent architectures is the potential
for different nodes to provide different kinds of local planners, schedulers,
optimizers and demand managers, relaxers, anticipators.
clusters - logical or physical? unit
of planning, consistency, security, privacy, ...? algebra of clusters
to account for splitting and merging. Mobility of clusters.
What defines cluster communities/societies? can they overlap?
plug-in issues - component configurability
of plug-ins; preventing collisions from competing plug-ins
control issues - preventing circular chaining
in planning, damping propagations; insuring visiting the log plan nodes
does not mean traversing all clusters in a WAN; cluster feedback mechanisms
characterizing consistency - ACID transactions
are not quite the right model for plan consistency. How does pedigree
fit? Supporting drill down and explanations.
reliability issues - clusters get disconnected
or go down then get reconnected and rehydrated
cost modeling, penalty functions, cluster bucks
the idea of a pervasive economic model with local mapping to a standard
of exchange (clusterbucks) needs refinement
sub-architecture frameworks - a multi-modal
user interface visualization framework and a fine-grained information management
framework for connecting data sources are two specialty architectures that
ALP will need to refine. [By the way, we have a nice menu-based
natural language interface technology that might work well in ALP for
letting end users easily ask complex queries or state complex rules.]
micro-licenses - a flexible scheme is needed
to microlicense components with purchasing being a special case.
Negotiation technology is needed to reduce time and cost of making business
arrangements. Pay-per-use logistics system.
enabling clusters to escape into the electronic
commerce community- ALP will succeed best if its infrastructure can
become the basis for how the electronic commerce and host nation communities
do business. If they adopt cluster protocols, then ALP can improve
its planning. An example is the FedEx parcel tracking service.
mappings of ALP to emerging technologies -
it is one thing to port from Voyager to Jini and another to understand
how to implement ALP on a changing technology base that includes not just
Jini but Enterprise Beans and other component protocols, XML/RDF, HTTP-NG,
OMG/JTF services, all of these and future ones. Some unifications
of Web-object-agents-clusters are needed. A mapping of ALP to emerging
agent standards from FIPA and OMG (MASIF, Trader) is needed
agent-cluster standards - agent-cluster interfaces,
logistics object models, etc. must be documented for other communities
to adopt them. This complements the open source approach ALP is planning.
cluster-agent architectures beyond logistics
- the cluster-agent architecture could also be a good model for more complex
societies beyond logistics to C2 and intelligence.]