SoaML - Planning for Implementation
- 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.
- Design a Manufacture architecture
- 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
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
- Connect following capabilities with usage dependency: OrderProcessing, Invocing, Shipping
- Draw a diagram, where a Capability Shipping interface realizes ShippingService <<ServiceInterface>> which have requestShipping operation.
- To the diagram describe in the above exercises (no 2), add a Shipper participant which realizes Shipping Capability
- Make sure that you type the Shipper participant port with appropriate ServiceInterface
- Add to the Shipper participant a part typed with Shipping capability and draw the delegate from the participant port
- Draw an "Expose" dependence between Sales and Marketing capability and Orders service interface.