Difference between revisions of "Application Role"
Rene spronk (talk | contribs) m (typo) |
Rene spronk (talk | contribs) (add patterns) |
||
| Line 1: | Line 1: | ||
| − | Application Roles reflect business roles. Application Roles represent groupings of functionality that an application can do. | + | Application Roles reflect business roles. Application Roles represent groupings of functionality that an application can do. This includes [[Interaction]]s an application can send, as well as interactions it can receive. It also includes the ability to execute the [[Receiver Responsibilities]] associated with received interactions, as well as the ability to support all Interactions which may be returned as part of the [[Transmission Pattern]] once the application has sent an interaction. |
Application Roles will form the basis for a suite of [[Conformance Claim]]s, in the same manner as was originally documented in the Version 3 Statement of Principles. | Application Roles will form the basis for a suite of [[Conformance Claim]]s, in the same manner as was originally documented in the Version 3 Statement of Principles. | ||
| − | If simple stereotype roles are used these may use the stereotype names Placer, Fulfiller, Informer and Tracker. | + | === Notes === |
| + | |||
| + | *One and the same interaction can be used by different application roles. | ||
| + | *If simple stereotype roles are used these may use the stereotype names Placer, Fulfiller, Informer and Tracker. | ||
| + | *An Application Role does not indicate support all Interactions which may be returned as part of the [[Interaction Pattern]]; as a minimum all the interactions of the [[Transmission Pattern]] need to be supported. | ||
== Discussion == | == Discussion == | ||
Revision as of 15:05, 9 December 2005
Application Roles reflect business roles. Application Roles represent groupings of functionality that an application can do. This includes Interactions an application can send, as well as interactions it can receive. It also includes the ability to execute the Receiver Responsibilities associated with received interactions, as well as the ability to support all Interactions which may be returned as part of the Transmission Pattern once the application has sent an interaction.
Application Roles will form the basis for a suite of Conformance Claims, in the same manner as was originally documented in the Version 3 Statement of Principles.
Notes
- One and the same interaction can be used by different application roles.
- If simple stereotype roles are used these may use the stereotype names Placer, Fulfiller, Informer and Tracker.
- An Application Role does not indicate support all Interactions which may be returned as part of the Interaction Pattern; as a minimum all the interactions of the Transmission Pattern need to be supported.
Discussion
The answer to “what are the business application roles” is in the heads and in the implementation specifications of the many experienced (V2) implementers and implementations. We need to tap into what has already been done – not the V2 standard, but how it is implemented by most V2ers most of the time. This is how we define “application roles” in the real world all the time.
The domain committees will have to use this experience and include business role based application roles (even if only as informative material) in their ballot material. In cycles subsequent to the initial ballot, the committees will define specific specializations or instantiations of the generic application roles defined above.
