Common Architecture Issues related to CoABS and ALP

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 with plugins.
• 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, and execution
• 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.]