SoaML - Introduction

From Training Material
Jump to: navigation, search
Title

SoaML
Author
Bernard Szlachta (NobleProg Ltd)
Subfooter

SoaML          Bernard Szlachta (NobleProg Ltd)


Source: OMG Spec

Overview of SoaML

What is an SOA? ⌘

  • SOA is a way of describing and understanding organizations, communities and systems to maximize agility, scale and interoperability
  • In SOA - people, organizations and systems provide services to each other
  • Services allow job to be done without doing it ourselves and without knowing how to do it
  • SOA works for new and existing capabilities
A service is value delivered to another through a well-defined interface 
and available to a community (which may be the general public).
A service results in work provided to one by another.

What is SoaML? ⌘

  • SoaML provides a standard way to architect and model SOA solutions in UML
  • OMG standard
  • Metamodel
  • UML Profile

Current Versions ⌘

  • 1.0 released March 2012
  • 1.0.1 released in May 2012

What is a System?

  • SOA is an approach to systems architecture
  • Architecture is a way to understand and specify how things can best work together to meet a set of goals and objectives
  • Systems include organizations, communities, processes and information technology systems
  • Services and Systems are there to support achievement of the organization goals

SOA Terminology ⌘

  • Participants
  • Ports
  • Service Description
  • Capabilities

Participants ⌘

  • Specific entities (e.g. Acme inc.) or
  • Kinds of entities (e.g. a client, a plane as a group of clients or planes who will use the service)
  • that provide or use services
  • Participants can represent people, organizations or information system components
  • Participants may provide and consume any number of services

Ports ⌘

  • Participants provide or consume services via ports
  • A port is the part or feature of a participant that is the interaction point for a service – where it is provided or consumed
  • A port where a service is offered may be designated as a «Service» port
  • A port where a service is consumed may be designated as a «Request» port

Service Description ⌘

There are three ways to specify a service interaction:

    • a UML Interface
    • a ServiceInterface
    • a ServiceContract

The service descriptions are independent of how the provider providers the service or how (or why) the consumer consumes it (i.e. service description is separated of the implementation)

A service specification specifies how consumers and providers are expected to interact through their ports to enact a service,
but not how they do it.

Capabilities ⌘

  • Participants that provide a service must have a capability to provide it
  • Different providers may have different capabilities to provide the same service
  • Some participants may even outsource or delegate the service implementation through a request for services from others

Three Approaches to Specify a Service ⌘

  1. Simple Interface
  2. ServiceInterface
  3. Service Contract

Simple Interfaces ⌘

  • A one-way interaction provided by a participant on a port represented as a UML interface
  • The participant receives operations on this port and may provide results to the caller
  • Can be used with anonymous callers and the participant makes no assumptions about the caller or the choreography of the service
  • Similar to RPC style web services, a method call
  • Use to implement simple services (getInvoice, changeAddress, etc..)
  • Can be used to define simpler services that have no protocols
  • Unidirectional – the consumer calls operations on the provider – the provider doesn’t callback the consumer and may not even know who the consumer is

ServiceInterface based ⌘

  • Allows for bi-directional services (i.e. there are 'callbacks' from the provider to the consumer)
  • A service interface specifies the interface that the provider offers as well as the interface, if any, it expects from the consumer
  • The service interface may also specify the choreography of the service
  • A consumer of a service specifies the service interface they require using a request port
  • The provider and consumer interfaces must either be the same or compatible
  • The ServiceInterface is the type of a «Service» port on a provider and the type of a «Request» port on the consumer
  • The ServiceInterface approach is most applicable where existing capabilities are directly exposed as services and then used in various ways, or in situations that involve one or two parties in the service protocol.

ServiceContract based ⌘

  • The service contract specify how providers, consumers and (potentially) other roles work together to exchange value
  • The exchange of value is the enactment of the service
  • The service contract approach defines the roles each participant plays in the service (such as provider and consumer) and the interfaces they implement to play that role in that service
  • These interfaces are then the types of ports on the participant, which obligates the participant to be able to play that role in that service contract
  • The service contract agreement includes the interfaces, choreography and any other terms and conditions
  • Service contracts are frequently part of one or more services architectures that define how a set of participants provide and use services for a particular business purpose or process
  • In summary, the service contract approach is based on defining the service contract in the middle (between the parties) and having the ends (the participants) agree to their part in that contract, or adapt to it
The fundamental differences between the contract and interface based approaches
is whether the interaction between participants are defined separately 
from the participants in a ServiceContract which defines  the obligations of 
all the participants, or individually on each participants' service and request.

Modelling Approaches ⌘

  • SoaML can be used for basic context independent services like the “Get stock quote” or “get time”
  • Basic services focus on the specification of a single service without regard for its context or dependencies (bottom-up)
  • SoaML can also be used “in the large” where we are enabling an organization or community to work more effectively using an inter-related set of services
  • Such services are executed in the context of this enterprise, process or community and so depend on agreements captured in the services architecture of that community
  • A SoaML ServicesArchitecture shows how multiple participants work together, providing and using services to enable business goals or processes.

Service Identification Methods ⌘

  • Designing services architectures and the service contracts
  • Using capabilities to identify service interfaces that expose them through services.
  • Using a business process to identify functional capabilities needed to accomplish some purpose as well as the roles played by participants
    • Processes and services are different views of the same system
  • Identifying services from existing assets
  • Identifying common data and data flows between parties and grouping these into services.