SoaML - Planning for Implementation

From Training Material
Revision as of 14:56, 28 August 2014 by Bernard Szlachta (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Example

ServicesArchitecture and Wrappers.png


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

SoaML Capabilities.png

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.