OMG ECDTF/ISIG

Agent Working Group


Co-chairs:  Stephen McConnell, Craig Thompson, James Odell
Minutes:  Craig Thompson

OMG Document internet/99-03-03

OMG Agent WG homepage:  http://www.objs.com/isig/agents.html

Agenda

Business

Minutes

Craig Thompson recorded the minutes.

Attendee List

43 attendees signed the attendance sheet:

New Agent WG Homepage

See http://www.objs.com/isig/agents.html, which is accessible from the OMG homepage via the ECDTF and Internet SIG homepages.

Agent Technology RFI, Craig Thompson, OBJS

On Monday we reviewed the Agent Technology RFI (see Agent WG homepage) page-by-page for an hour and a half and accepted a number of revisions. The revisions were added to the document Monday night and a new draft issued for review at Tuesday’s meeting. James Odell motioned to recommend the RFI to the DTC and Chris Rygaard (Ad Astra) seconded. We determined we were quorate with 13 companies. The vote was 8 FOR and 1 ABSTAIN. The motion PASSED. The RFI then progressed to DTC vote on Friday 3/26/99 where the vote passed. This means the current version of the document will be released to industry.  The new document number is ec/99-03-10.

Agent Technology Green Paper, James Odell

James Odell led the discussion of the current draft of the Agent Technology Green Paper (see Agent WG homepage). The main discussion on Monday covered the Table of Contents and additions to make it parallel the Agent Technology RFI so the mapping of what is submitted to what section of the green paper it goes in is as direct as possible. See the Agents WG Homepage for latest versions of this document.  The pre-assigned document number for the revised document is ec/99-03-14.  Watch Agent WG homepage for the update.

OMG-FIPA Liaison Proposal, Craig Thompson, OBJS

We reviewed the OMG-FIPA Liaison Proposal (see Agent WG homepage), made some revisions, then voted to recommend this document to the OMG Liaison Subcommittee. Craig Thompson participated in the Liaison Subcommittee meeting held on 3/24/99 at dawn.  The document was voted through with minor changes.  Henry Lowe (chair of the Liaison Subcommittee) took the document to the Architecture Board for a third passing vote on Thursday.  The document number is liaison/93-03-03 (same as ec/99-03-12).  The next step is to send the document to FIPA as a resolution.  FIPA meets in April.  If that passes, then the OMG Board will vote.

WG or SIG?

We discussed if, how, and when to escalate Agent WG to a SIG or TF. Consensus was: we have sufficient participation, expertise, and technical progress to justify a SIG (and possibly later a TF). We believe we should aim for a platform SIG in August to coincide with the meeting where we are analyzing RFI responses. That will require us to create an informational presentation covering Agent Technology and our process for presentation to other OMG groups at the Tokyo and San Jose meetings. McConnell has an initial presentation and Odell and Thompson will revise that draft before the next meeting.  All willing to give briefings to other OMG groups are requested to do so.

Mission Statement

In preparation for the move to SIG, we reviewed a draft Mission Statement (see Agent WG homepage) that several of us had drafted between the last and this meeting. We made some changes. See the Agent WG homepage for the latest version ecdtf/99-03-13.

Agendas for Next Meetings (Tokyo and San Jose)

We will invite informational presentations for Tokyo and focus on reviewing Agent Technology RFI responses for San Jose.  The chairs will solicit presentations.  Very tentative agendas are posted on the Agent WG homepage.

Presentations

FIPA Architecture Work in Progress, Francis McCabe, Fujitsu

FIPA has around 50 member organizations. At the last FIPA meeting, the idea of an agent architecture was formalized into a technical committee, which Francis is heading. The idea is to say what the component pieces are and how they fit together. Having an architecture makes it easier to create agent platforms (services) and agent systems (collections of agents that use an agent platform). They will say how you might build agents (not prescriptive but a default way). FIPA architecture might be reified via Java, IDL, UML and/or CORBA/services reifications. The timescale of the FIPA architecture is aggressive. The next FIPA meeting is in Nice in a few weeks, another is July 5-9. FIPA may be ready with an architecture submission to the OMG RFI by August.

FIPA was originally concerned about the message definitions (interchange formats, wire formats) between point A and B, not the shape or capabilities of agent systems at A and B. But they have gradually moved to see a need to specify common services at A and B.  For instance, needing to know what agents are there requires a directory service, which then requires agent lifecycle services. And a security service. … The point brought out was that FIPA is starting to see the need for OMG-like services so there could be a dependency of agents on objects. But the reverse is possibly true too, that OMA might get value out of adding agent capability to object systems so that parts of the OMA might come to depend on agent technology. Related, FIPA agent systems might not only want to depend on services but also insure or guarantee system-wide properties (scalability, survivability, reliability, evolvability, …)

This new abstract architecture work makes it potentially clearer how FIPA work might map to OMG OMA. But some issues remain. One is, how do you know if the umbrella of services is complete or not or over-specified? What does it mean if some agent systems are light-weight providing few services and others are heavy-weight but full-service (providing lots of services). Can services be added on the fly to agent systems. What does interoperability of agents and agent systems mean if this is the case?

COS Notification Q&A, Mike Greenberg, NEC

Mike provided an overview of the notification service, which is an extension of the Event Service in which Suppliers and Consumers connect to an event channel via proxies using either push or pull style on either side.

The primary addition notification adds in extensions of proxy objects is to add filters, which add constraints in a boolean constraint language. Filters can be dynamically defined. Can have many filters on same proxy which are OR-ed together. Or multiple constraints in one filter. Its easy to navigate the proxy. The boolean grammar is an extension to the Trader constraint language. Typically all proxies and filters are part of the same address space. Example filter is a string "$.filterable_body.cost > 5". In the absence of the security service, any process can modify any filter. That is a generic property of CORBA. Also, they define a QoS framework, especially related to reliability. Connection reliability remember states persistently in case of server crash. Consumer is still logically connected based on implementation specifically. Extended Trader Constraint Language looks like complex conditionals. They do not support correlation in this spec. Hitachi, Iona/NEC, Prism have implementations.

How is OCL related? OCL is a potential alternative. OCL is first order but this is less. Events carry data, not just boolean.

Notification uses not only any events but typed events. Supplier and Consumer Admins can share filters. This is good when a set of consumers are similar and follow a similar policy.

A new RFP on Management of Channel Networks is in the works, being worked in Telecom DTF.