SoaML - ServiceArchitecture

From Training Material
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
  • 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

Exercise

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