OMG Agents Working
McConnell, James Odell, Craig Thompson
OMG Agent WG homepage: http://www.objs.com/isig/agents.html
Dock Allen - General Dynamics Information Systems -
Brian Cook - Technical Resource Connection - firstname.lastname@example.org
Edward Feustel - Institute for Defense Analyses -
Heimo Laamanen - Sonera - email@example.com
Francis McCabe - Fujitsu - firstname.lastname@example.org
Stephen McConnell - OSM - email@example.com
Judy McGoogan - Lucent Technologies - firstname.lastname@example.org
James Odell - Intellicorp - email@example.com
Kimmo Raatikainen - Nokia - firstname.lastname@example.org
Michel Ruffin - Alcatel - email@example.com
Darrel Sell - NSA - firstname.lastname@example.org
Kenneth Shaffer - Raytheon - email@example.com
David Smiley - SAGA - firstname.lastname@example.org
Michiharu Takemoto - Nippon Telegraph and Telephone -
Craig Thompson - Object Services and Consulting -
Robert Whitney - The Bulldog Group - email@example.com
… by Craig Thompson
Review of Relevant Other OMG Work
Asynchronous Messaging, Bill Binko, TRC, Bill.Binko@trc.com
Orbos-98-05-05 or current RTF activity. Several have read the spec. The
spec extends CORBA with AMI - asynchronous messaging. Client calls server
and server response comes back to client message handler. Spec adds priorities,
store and forward, timeouts, queueing or router, possibly several of these.
Client and server can be disconnected. In AMI, it redoes the stubs - IN
parameters are passed in GIOP. Standard form of message. This is type safe,
not manually setting up the mapping. DII is not type safe. You can support
guaranteed delivery, priorities, but not everything you can do with MOM.
Now client sends f() to stub, goes to client orb to server orb to POA to
skeleton to call f() on server side. Main change is on client side to talk
to reply handler that is skeleton for servant. Callback model. Client side
ORB must be messaging aware. Server side does not have to change (in theory).
When you can get failure (and it is not all in memory). Francis comments
that these are like continuations. You could make this transparent but
if you want control over the synchrony, then you need to know the handler
exists and be able to control it. For instance, an indirection is to have
a router in an intermediary process then this lets client or server to
go away. You can specify policies based on the intermediaries. Apparently,
the claim is that transactions do not work over the intermediaries. Priorities
across many clients cannot be balanced. Many intermediate routers are not
ORBs at all but might be MQSeries. These intermediaries are not true ORBs
in that they do not support all ORB interfaces. The unshared transaction
model is a hack. Client can call transactional services but not be part
of a transaction. For queuing, the router builds a value type that is passed
back to client that can check status of the request via querying the value
type. Generally IIOP talks to router but router can talk anything to other
routers that must eventually talk to Corba client. Most ORBs will support
lower level proprietary extension for passing messages not in IIOP. All
compliant ORBs are required to put the route into the IOR. ORBs can use
more dynamic routing but they must support this static chain idea.
Right now, messaging and interoperable security do not work well together.
All this should be in JIDL, Iona, Visigenics 3.0 ORB.
So how is all this relevant to agents and ACL? Type safety might be
something agents do not need, thinks Francis. Agent message is more like
inter program email. The email is highly structured. You could package
your xml acl encoded message as an ANY and reply with a Null. Our routers
could be smart. Could also steal notification work as well (though that
is broadcast). Agents could be built on the AMI and notification design
Action item: Portable Interceptor Spec - get updated on this. Can add
new service profiles this way.
On-line Upgrades, Bill Wood, CMU/SEI, firstname.lastname@example.org
Real-time PSIG is working on RFP for online software updates. Want continuously
operating systems even when there are updates. Some proprietary software
does this. Not doing load-balancing - (another RFP is doing this. Want
to solve the interface versioning problem but backed off due to ORBOS advice.
Types of upgrades, different implementation, QoS or semantics. Non-redundant
objects - either you queue requests -or- deny service. Redundant objects
- emphasis is here. Current fault tolerance work ongoing. There are active
and passive kinds of fault tolerance. Passive has downtime versus more
complexity but better response. Replications within the group is not enough
for configurations. An element of preserving system state. Rollback to
an old version. Selection mechanisms like first arrival, voting, preferred,
decision making and safety, update paradox (functional redundancy so have
same signature but different implementations, and all the same where if
one fails they all will). Another approach is to install second version
simultaneous and check both logs to see if they behave the same. Went through
mandatory requirements and optional that included how to safely add a new
member into a group.
Problems with AB - fault tolerance is going on now so we need to get
some experience. So is single entity upgrades only worth doing? Agent WG
definitely thinks it is. What kinds of versioning? (branching or
linear). Also must affect interface upgrading? (not sure). Q: what about
dependencies? Not covered in this RFP.
CSI Interoperable Security RFP, Ed summary in lieu
of real presentation
We were hoping for a briefing on this RFP but will try again at the next
meeting. A few people gave us some inputs. The SEC SIG is moving
toward using an SSL type of approach. Vendors did not like SEC IOP so this
avoids that. So you could not get to security level 2. Permits
out of band communication. Has nothing to do with portable interceptors.
Possibility exists to have single security service that is portable across
Agent groups needs to define what kinds of non-repudiation, integrity
services, signing, etc. Can you seal data and carry it around and know
it has been tampered with. What about multi-hop authentication. What about
delegation? What happens when agent security policy is different than host
security policies. What are agent security requirements? One answer
is, they are not too unique and different agent systems might need different
capabilities. Tune in again at the next meeting.
Registration and Discovery RFP, Steve McConnell
Steve goes over the RFP. This RFP was presented to AB, Telco task
force, and EC task force. Many on the internet are producing XML schemas.
XML Schema does have inheritance. It is version 2 of XML, more of less.
These are schemas describing things that have commercial terms and conditions.
The proposed Registration and Discovery Service is tied very closely to
Trader. Trader itself can store non-IDL, just URL or IOR. XMI is an XML
based schema for exchanging UML across repositories. Includes a mapping
of all IDL types. Has all the semantic info.
Selection languages include XQL and commerce net selection language
among others. Conjunctive and disjunctive, multiple discovery services,
predicates, natural language keywords, financial products markup language
Trying to avoid management and plugin subsystems, hard to define this.
How do you avoid the ontology problem of resource descriptions describing
anything? Answer is to define to a collection of policies for versioning,
terms and conditions, ….
Submitters LOI due 10 March.
Architecture Board pointed out there are no requirements in the management
area. Want to include rationale for why not to include it as a non-goal.
Add some scalability criteria. Steve says: not trying to provide
replaceable systems, just interoperable ones.
Discussion on the meaning of policy, which is way underspecified in
FIPA News, Fancis McCabe
No FIPA meeting since last OMG meeting; next one in ten days. Lots of changes
in FIPA management. Everything is changing, specs management, meeting format,
architecture of specs, spec of architecture. Recent work on FIPA architecture.
Presentation by Kate Stout. Reminiscent of three RFP track - naming,
registration, transport. Three things the architecture group is working
A main thing in the future is policy. Want predicate calculus
like language to describe policy. To use this service you must register
with that service first. You must use secure message transport. Management
of policy. Policy domain is a set of agents agreeing to a certain set of
policies. Highly controversial. Question about point of application of
policy. A statement about a constraint on application of agent. Applied
at point of use of service. Another cut on notion of domain is as a computational
vehicle and agent pre-agreeing to policies. Policy verification is a membership
test. Similar to client server relationship in an agent-service relationship.
Policies are related to services.
Francis wrote a paper on Abstract ACL.
Lots of discussion in FIPA on content languages. Requirements on them,
policies on them. Do you allow multiple representations of content languages.
Can an entity have a set of object messages (so it is an object) and
also send and receive ACL messages (so it is simultaneously an agent).
Provides a good way for objects and agents to interoperate in the same
environment. Another way to do this is via a content language that
is oo. Some agents may not also be able to speak IDL. This leads
to a picture in which agents and objects are both first class and the same
object may (or may not) be both an agent and an object, depending on whether
it is speaking ACL or IDL.
We need a compelling set of use cases for ACLs. FIPA uses SL as a content
language but it is undecidable. Content language in FIPA is plugin affair.
Ask prolog query or Tell prolog assertion. But what happens when a prolog
rule contains another ACL query?
Agent Technology Green Paper, Jim Odell
Jim reviewed the several additions to the Agent Technology Green Paper.
Areas that still need work:
kinds of agent applications - b2b applications - Steve McConnell
agent-object interactions - Craig and Francis might add some text
add in other work in progress as well as adopted services (sec 10) - Jim
to add Craig's text on DARPA liaison
still need Climate section? Maybe move to section 9.
reference mailing list and agent wg homepage
add MASIF - framework for federating mobile objects
for each service, we need to not only say what they do but how they are
related to agent technology
need to critique, review, smooth the document
Message transport vs delivery - the term transport causes confusion
Agent White Paper and Roadmap
We ran out of time to go over the current draft of the white
paper and roadmap. So we will do that in Denver. We did
discuss one of the three pre-RFP areas that we had planned to discuss:
Agent Discovery Service, Craig Thompson
At the Boston meeting, we decided to assign folks to dig deeper on proposed
RFPs that seemed core to getting agent technolgy widely deployed.
These were agent identity, transport, and agent discovery and registration.
Thompson was charged with leading a discussion on the latter. See
Discovery and Registration Notes (internet/00-01-03).
Because of the overlap with the ECDTF Registration and Discovery RFP,
we discussed the two together. We generally think the ECDTF RFP will
meet the needs of the agent community for the purpose of registering agents
and finding them. It will require that agents be represented by some
standard means in XML Schema, at very least. It was thought not to
be too interesting to consider the discovery and registration service to
be itself an agent. Several ideas not in the RFP emerged: compositional
or inference objects, resource descriptions that span all of ontologies,
the need for a family of query capabilities for text, properties, xql,
prolog, or SL. Possible need for plugins. Also, we questioned
if anyone would define "policy" the way it was described in the RFP, or
know what was intended.
Agenda for Denver Meeting
... see Agent WG Denver agenda
updated to Green Paper - see list.
review and comment on White Paper - think hard about RFPs and the requirements
for each service or capability
cases? that could be a new section in the green paper