SoaML - ServiceArchitecture

From Training Material
Revision as of 17:36, 7 February 2016 by Bernard Szlachta (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
  • A ServicesArchitecture (or SOA) is a network of participant roles providing and consuming services to fulfill a purpose.
  • The services architecture defines the requirements for the types of participants and service realizations that fulfill those roles
  • The purpose of the services architecture is to specify the SOA of some organization, community, component or process to provide mutual value

A services architecture has components at two levels of granularity:

  • The community services architecture:
    • the top level view of how independent participants work together for some purpose
    • does not assume or require any one controlling entity or process
  • A participant services architecture:
    • specifies how parts of that participant (e.g., departments within an organization) work together to provide the services of the owning participant
    • usually realized by a UML class or component
    • participants that realize this specification must adhere to the architecture it specifies
    • within a participant, where there is a concept of “management” exists
  • A ServicesArchitecture or specification class may be composed from other services architectures and service contracts
  • Participants are classifiers defined both:
    • the roles they play in services architectures (the participant role)
    • the “contract” requirements of entities playing those roles
  • Each participant type may “play a role” in any number of services architecture
  • Requirements are satisfied by the participant having service ports that have a type compatible with the services they must provide and consume

Steps when developing full architecture

First, let us determine participants and contracts:

NobleProg Franchise Financial Reporting ServicesArchitecture.png

Second, let us specify the MontlyFeePayment contract:

NobleProg MontlyFeePayment serviceContract.png

Third, let us define Consumers and Providers and dependencies between them:

SoaML ServiceContract Interfaces.png

Forth, we can define the choreography for the contract:

NobleProg MonthlyFeePayment Choreography.png

Fifth, we can design ports and exposed interfaces to better understand the design:

SoaML Multicontract Participants.png

Ultimately, let us have a big picture:

NobleProg Franchise Financial Report (2nd way).png


Based on the example above, design an servicesArchitecture for a "Dealer Network Architecture".

Use following components:

  • participants types: Dealer, Manufactures, Shipper
  • contracts: Purchasing (roles: buyer, seller), Ship (from, agent), Ship Status (enquire, ship info)
  • do not use embeded contracts