[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] OMG Pro Use of Agents
I am not that clear on though like it as well: Service is the Agent that takes on the Intent of the Service Consumer to realize the Real World Effects of the underlying capabilities, realizing these effects in ways that are consistent with the policies and any other constraints (such as technical assumptions) as contained in the service description. In particular, is it always the case that the RWE belongs to the underlying capabilities, especially, if capabilities are not functions but resources (as we talked before), and cannot be realized without resources? Im, probably, missing the conclusion about relationship between functionality and capabilities. To me, it would be much simpler if capabilities would included *functionality* & *resources*; in this case the Real World Effects of the underlying capabilities becomes fully consistent statement in my view. - Michael ============================================= Subject: Re: [soa-rm-ra] OMG Pro Use of Agents From: Ken Laskey <klaskey@mitre.org> To: Francis McCabe <frankmccabe@mac.com> Date: Thu, 24 Jul 2008 00:20:27 -0400 Hallelujah! The RM says, "A service is a mechanism to enable access to one or more capabilities ..." without saying anything about the mechanism. Here, we (may) elaborate on the mechanism by describing it in terms of a non-BDI agent. So it may not be that much of a different animal: we said it had stripes; now we're saying the stripes are green and zigzag. I won't push the counts-as but to me an agent is the clearest example. Ken =========================================== On Jul 23, 2008, at 10:31 PM, Francis McCabe wrote: in the world of BDI agents (otherwise known as beady-eyed agents), an agent may have beliefs, desires and intent. Desire seems akin to goal, belief is akin to the partially known state of the world and intent is... Anyway, I rather this definition of Intent: Intent is a willingness to perform actions to achieve a stated goal And, I think I also like: Service is the Agent that takes on the Intent of the Service Consumer to realize the Real World Effects of the underlying capabilities, realizing these effects in ways that are consistent with the policies and any other constraints (such as technical assumptions) as contained in the service description. Although, personally I think that this makes Service a different animal that envisaged in the RM, I can definitely buy into this version. I do not think, though, that you need to invoke the transfer of Intent to account for counts-as. That is partly because transferring Intent is something that the Service Agent (yet another qualified term?) does within itself, whereas counts-as can be formulated in a purely public semantics pov. This feels like progress to me!! Frank On Jul 23, 2008, at 7:04 PM, Ken Laskey wrote: The OMG Agent is in the context of autonomous agents, and I don't think we are going there for the RA. Jeff and I had a follow-on discussion in the context of the work we're coordinating for the Realizing View, and my notes from that are as follows: <KenThoughts> Participant has Intent. Agent (1) takes on Intent of a Participant, (2) adds Intent that is purely mechanistic to realize Participant's Intent ex: I have Intent to have addition built to my house and hire general contractor as my Agent. Intent of contractor is specifically to carry out my Intent. So if I want the addition to be painted putrid green, that is the Intent of my Agent. However, my Agent has a related Intent of purchasing the paint and sees to this Intent solely because it is necessary to realize the Intent I passed to him. If not acting as my Agent, the contractor has no independent Intent to buy the green paint. Participant is a Stakeholder whereas Agent is not because it has no independent Intent. So we might modify the definition of Stakeholder to say it has "an 'independent' interest in the states of services" (where I think I have a suggested rewording for "states of services"). Thus, a Stakeholder has Intent, where Intent is a willingness to perform actions to achieve a stated goal (proposed change to section 3) and action is still up for grabs. Can the Service be a Participant if it doesn't have independent Intent? [no] Does this imply the Service Provider is the Participant because that is where the Intent resides? [yes] So Service is indeed the Agent. [yes] <lateAddition> Or more in line with the RM, Service is the Agent that takes on the Intent of the Service Consumer to realize the Real World Effects of the underlying capabilities, realizing these effects in ways that are consistent with the policies and any other constraints (such as technical assumptions) as contained in the service description. The Service may carry out additional private actions to apply the policies and constraints, e.g. invoke an Authentication Service to identify the Service Consumer. </lateAddition> Interacting with Service counts-as interacting with Service Provider because there is a transferring of Intent. [possibly the missing definition of counts-as.] If the same entity is the Service Provider and Service Consumer, is that one Participant? No, because each Participant "role" has a different Intent. So Participant, Role, and Intent are related. </KenThoughts> I think most of what I said here is consistent with what Danny said but adds a few bits which I hope provides elaboration without raising anyone's blood pressure. Onwards! Ken On Jul 23, 2008, at 9:05 PM, Danny Thornton wrote: The OMG Pro has an elaborate stereotype description for Agent which is included at the end of this message. The definition is somewhat consistent with how we have discussed using Agent for the SOA RA. One distinction between the two is how Frank modeled an agent as being employed by a participant but the agent itself is not a participant. In th OMG Pro, an agent extends a participant. Jamie mentioned a distinguishing characteristic between participants and agents using volition. Participants act with volition but agents do not. For the RA, if we qualify agents to electronic services that do not act with volition, then we have a clear distinction for the use of agents and participants in the document. Owning participants of agents are responsible for the actions of the agents but the agent itself is not responsible for its actions since it does not act with volition. This would change Franks model of Agent such that agents do not have goals or intents. In the real world, people can act as agents on behalf of other people, but we do not have to be that all encompassing with regards to agents in the SOA RA. Danny The OMG Pro use of Agents: Agent An Agent is a classification of autonomous entities that can adapt to and interact with their environment. It describes a set of agent instances that have features, constraints, and semantics in common. Generalizes Participant Description In general, agents can be software agents, hardware agents, firmware agents, robotic agents, human agents, and so on. While software developers naturally think of IT systems as being constructed of only software agents, a combination of agent mechanisms might in fact be used from shop-floor manufacturing to warfare systems. 2 These properties are mainly covered by a set of core aspects each focusing on different viewpoints of an agent system. Even if these aspects do not directly appear in the SOAPro metamodel, we can relate them to SOA-Pro-related concepts. Depending on the viewpoint of an agent system, various aspects are prominent. Even if these aspects do not directly appear in the SOA-Pro metamodel, we can relate them to SOA-Pro-related concepts. Agent aspect - describes single autonomous entities and the capabilities each can possess to solve tasks within an agent system. In SOA-Pro, the stereotype Agent describes a set of agent instances that provides particular service capabilities. Collaboration aspect - describes how single autonomous entities collaborate within the multiagent systems (MAS) and how complex organizational structures can be defined. In SOA-Pro, a ContractFulfillment (CollaborationUse) indicates which roles are interacting (i.e., which parts they play) in the contract. Collaboration can involve situations such as cooperation and competition. Role aspect - covers feasible specializations and how they could be related to each role type. In SOA-Pro, the concept of a role is especially used in the context of service contracts. Like in agent systems, the role type indicates which responsibilities an actor has to take on. Interaction aspect - describes how the interaction between autonomous entities or groups/organizations take place. Each interaction specification includes both the actors involved and the order which messages are exchanged between these actors in a protocol-like manner. In SOA-Pro, contracts take the role of interaction protocols in agent systems. Like interaction protocols, a services contract takes a role centered view of the business requirements which makes it easier to bridge the gap between the process requirements and message exchange. Behavioral aspect - describes how plans are composed by complex control structures and simple atomic tasks such as sending a message and specifying information flows between those constructs. In SOA-Pro, a ServiceInterface is a BehavioredClassifier and can thus contain ownedBehaviors that can be represented by UML2 Behaviours in the form of an Interaction, Activity, StateMachine, ProtocolStateMachine, or OpaqueBehavior. Organization/Group aspect - Agents can form social units called groups. A group can be formed to take advantage of the synergies of its members, resulting in an entity that enables products and processes that are not possible from any single individual. Attributes No additional attributes. Associations No additional associations. Constraints The property isActive must always be true. Semantics The purpose of an Agent to specify a classification of autonomous entities (agent instances) that can adapt to and interact with their environment, and to specify the features, constraints, and semantics that characterize those agent instances. Agents deployed for IT systems generally should have the following three important properties: Autonomous - is capable acting without direct external intervention. Agents have some degree of control over their internal state and can act based on their own experiences. They can also possess their own set of internal responsibilities and processing that enable them to act without any external choreography. As such, they can act in reactive and proactive ways. When an agent acts on behalf of (or as a proxy for) some person or thing, its autonomy is expected to embody the goals and policies of the entity that it represents. In UML terms, agents can have classifier behavior which governs the lifecycle of the agent. Interactive - communicates with the environment and other agents. Agents are interactive entities because they are capable of exchanging rich forms of messages with other entities in their environment. These messages can support requests for services and other kinds of resources, as well as event detection and notification. They can be synchronous or asynchronous in nature. The interaction can also be conversational in nature, such as negotiating contracts, marketplace-style bidding, or simply making a query. In the Woodridge-Jennings definition of agency, this property is referred to as social ability. Adaptive - capable of responding to other agents and/or its environment. Agents can react to messages and events and then respond in a timely and appropriate manner. Agents can be designed to make difficult decisions and even modify their behavior based on their experiences. They can learn and evolve. In the Woodridge-Jennings definition of agency, this property is referred to as reactivity and proactivity. Agent extends Participant with the ability to be active, participating components of a system. They are specialized because they have their own thread of control or lifecycle. Another way to think of agents is that they are "active participants" in an SOA system. Participants are Components whose capabilities and needs are static. In contrast, Agents are Participants whose needs and capabilities may change over time. In SOA-Pro, Agent is a Participant (a subclass of Component). A Participant represents some concrete Component that provides and/or consumes services and is considered an active class (isActive=true). However, SOA-Pro restricts the Participant's classifier behavior to that of a constructor, not something that is intended to be long-running, or represent an "active" lifecycle. This is typical of most Web Services implementations as reflected in WS-* and SCA. Agents possess the capability to have services and requisitions and can have internal structure and ports. They collaborate and interact with their environment. An Agent's classifierBehavior, if any, is treated as its life-cycle, or what defines its emergent or adaptive behavior. <bottom.letterhead> ----------------------------------------------------------------------------- Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 ----------------------------------------------------------------------------- Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]