SoaML - Planning for Implementation

Example

Participant Architecture

• The example below illustrates the participant services architecture for a particular “Franchisee”.
• It indicates that this architecture consists of a number of other participants interacting through service contracts.

• Other Franchisees may have different internal participant architectures but will have the same responsibilities and interfaces in the services architecture
• Separating the concerns of the “inside” Vs. the “outside” is central to SOA and good architecture in general

• The services architecture in the example is the architecture for a specific Franchisee (NobleProg UK Ltd), realizing the requirements of Franchisee in general
• Note that the roles “outside” of the Franchisee are indicated by the roles with green colour (:MasterFranchisee) where as the roles played by entities within NobleProg UK Ltd are normal roles
• The net effect is that services architectures may be used to specify how system and systems of systems work “all the way down”.
• These architectures can then be realized by any number of technology components.

Exercises

1. Design a Manufacture architecture

Wrappers (Adapters)

• Adapter pattern joins top-down and bottom-up services
• These adapters may be created automatically or manually
• Adaptation is used where a “bottom up” interface is provided but is overly coupled with the supporting technology
• A top-down “enterprise service” is defined to be more general and less coupled

• Xero exposes certain interfaces, but they cannot work directly with the FinancialModule
• Franchisees should be able to change their accounting system provider as well as in Germany or Poland franchisees use different accounting systems
• The FinacialAdapter decouples Xero from the FinancialModule

Capabilities

Use Capabilities when:

• the abstract Participants are not know
• you want to specify the behavior of a service or capability that will realize or implement a ServiceInterface
• want to map existing system to plan adapters in order to match the architecture
• you want to communicate the needs and capabilities of a service area

Capabilities represent an abstraction of the ability to affect change.
Capabilities identify or specify a cohesive set of functions or resources 
that a service provided by one or more participants might offer.

• Each Capability may have owned behaviors that are methods of its provided Operations
• These methods would be used to specify how the Capabilities might be implemented, and to identify other needed Capabilities
• Alternatively, ServiceInterfaces may simply expose Capabilities of a Participant.

Usage dependencies shows how these capabilities are related

Capability realizing ServiceInterface

• Capabilities can be used to specify the behavior and structure necessary to support a ServiceInterface
• Capability allows for the specification of a service without regard for how that service might be implemented and subsequently offered to consumers by a Participant
• It allows architects to analyze how services are related and how they might be combined to form some larger capability prior to allocation to a particular Participant.

Capabilities realized by a Participant

• When that Capability itself realizes a ServiceInterface, that ServiceInterface will normally be the type of a Service on the Participant

Capabilities specifying parts of Participants

• The capabilities the participant has to actually provide its services
• The CourseOutlinePush ServicePoint delegates requests to the cosm_us part that is typed by the CourseOutlineSynchronizationModule Capability
• This would normally indicate that the CourseOutlineSynchornizationModule realizes the CourseOutlinePush ServiceInterface.

ServiceInterfaces exposes Capabilities

• Done with the Expose Dependency
• Can be used as the inverse of a Realization between a Capability and a ServiceInterface it realizes
• Can be used to represent a means of identifying candidate services or a more general notion of “providing access” to a general capability of a Participant

Exercises

1. Connect following capabilities with usage dependency: OrderProcessing, Invocing, Shipping
2. Draw a diagram, where a Capability Shipping interface realizes ShippingService <<ServiceInterface>> which have requestShipping operation.
3. To the diagram describe in the above exercises (no 2), add a Shipper participant which realizes Shipping Capability
   1. Make sure that you type the Shipper participant port with appropriate ServiceInterface
4. Add to the Shipper participant a part typed with Shipping capability and draw the delegate from the participant port
5. Draw an "Expose" dependence between Sales and Marketing capability and Orders service interface.