Precedence Health Care The MAS – SE Gap: Bridging the Divide Michael Georgeff Precedence Health Care & Monash University Autonomous Agents and Multiagent Systems, Estoril, Portugal, May 2008

Precedence Health Care We have not identified the value proposition for MAS across sufficient application domains to make it compelling; We have not translated the way we describe MAS into the framework used in conventional SE development environments We have not sufficiently focused on the key ideas, instead selling a whole package of complex concepts and mechanisms that go beyond the needs of mainstream SE; and We have not sufficiently well integrated our methodologies, frameworks and languages with existing standards and development infrastructures. Why aren’t we having an influence?

Conventional Hard-Wired Process Selection OfferP1 C2 Assess Customer OfferP2 OfferP3 OfferP4 Close Sale C1 C3 C4 OfferP1 OfferP2OfferP3 OfferP4 The names of the called processes and the conditions (C1, etc) determining which to call in which circumstances are included in the calling process, complicating design, validation, reuse, and change. Development of called and calling processes cannot proceed independently of one another.

Semantic encapsulation: Key to SE Assess Customer Close Sale OfferP1 OfferP2OfferP3 OfferP4 Offer Product Sell Process Maximum adaptability and reuse when the calling process is fully independent of the called processes. Should not need to know (i) the locations/names, (ii) the context of use, (iii) the data needs, or (iv) the implementation of other processes. It should be sufficient to state what service or outcome is requested and what service or outcome is provided. Calling process and each of the called processes should be able to be developed independently of one another by independent developers

AO: Goal-Directed Process Selection Assess Customer Close Sale Offer Product Goal: Offer Product Condition: C1 OfferP1 Conditions of use are contained in the called processes. Processes are “loosely coupled”– i.e., selection is made dynamically at run time based on context of use (applicability). The called processes can be created/changed independently of each other and the calling process. Benefits multiply when the requested goal is reused in other calling processes. Goal: Offer Product Condition: C2 OfferP2 Goal: Offer Product Condition: C3 OfferP3 Goal: Offer Product Condition: C4 OfferP4 Loosely Coupled

AO: Automatic Exception Handling Assess Customer Close Sale Offer Product Goal: Offer Product Condition: C1 OfferP1 Using goal-directed processing, no coding is needed in the calling process or the called processes for handling exceptions or failures. Conventional languages require explicit exception-handling links and routines to be coded into the process flows, rapidly turning into spaghetti code. Goal: Offer Product Condition: C2 OfferP2 Goal: Offer Product Condition: C3 OfferP3 Goal: Offer Product Condition: C4 OfferP4 If any selected process fails or is unsuccessful, the call is repeated (reposted) and any newly matching processes invoked. Retry on failure

Conventional SE: Hard-Wired Data Flow OfferP1 C2 Assess Customer OfferP2 OfferP3 OfferP4 Close Sale C1 C3 C4 OfferP1 OfferP2OfferP3 OfferP4 Data D1 Data D2 Data D3 Data D4 The data (D1, etc) needed by the sub-processes has to be passed from the calling process to the called processes (via parameters or interface dialogue). This requires the calling process to know what data the called processes need. This reduces process independence, complicating development, maintenance and change. Development of called and calling processes cannot proceed independently of one another.

AO: Common data shared across processes Assess Customer Close Sale Offer Product Goal: Offer Product Condition: C1 OfferP1 Common data is shared among processes, so that there is no need to explicitly code the data flow. The calling process is simple and independent of the data needs of the called processes. The called processes can therefore be created/changed independently of each other and the calling process. Benefits multiply when the requested goal is reused in other calling processes. Goal: Offer Product Condition: C2 OfferP2 Goal: Offer Product Condition: C3 OfferP3 Goal: Offer Product Condition: C4 OfferP4 Shared Data D (Beliefs) Get D1 Get D2 Get D4 Get D3

AO: Agents as Services Enterprise Services Bus Loosely Coupled Loosely Coupled Agents separate the interface from the implementation and provide a Services Interface to each other and to other components. Internal goals and shared data are localized to an agent. The Services Interface supports loosely coupled Services and Event-Driven processing. Semantics of goal- directed processing is extended to the service level. Seller Agent Shipping Agent

Precedence Health Care Influence the influencers: Get uptake from the Gartner’s, Forresters, and large early adopters of the technology. Transform the story into something that conventional SEs understand. Make it an extension or progression of service oriented and event driven architectures. Identify the weak points in SOA and show how MAS solves these problems. Focus on the concepts and methodologies, not new languages. Let the concepts and methodologies drive extensions to BPEL, SOA. Focus on and standardize the key ideas, preferably by extensions to existing concepts. Don’t try to sell the whole package. Or alternatively, give up on the enterprise level and focus instead on niche markets requiring high flexibility, high complexity software solutions. What do we have to do?