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