Bernard Szlachta at 14:56, 28 August 2014

2014-08-28T14:56:13Z

New page

{{Cat|SoaML|SoaML3}}

== Example ==
[[File:ServicesArchitecture and Wrappers.png|300px]]

== 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 ===
# 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 ==

[[File:SoaML Capabilities.png|300px]]

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 ===
# 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.

SoaML - Planning for Implementation - Revision history

Bernard Szlachta at 14:56, 28 August 2014