Bernard Szlachta at 17:36, 7 February 2016

2016-02-07T17:36:53Z

New page

{{Cat|SoaML|SoaML26}}
{{Cat|Enterprise Architecture|41}}

* 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:

[[File:NobleProg Franchise Financial Reporting ServicesArchitecture.png|300px]]

Second, let us specify the MontlyFeePayment contract:

[[File:NobleProg MontlyFeePayment serviceContract.png|300px]]

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

[[File:SoaML ServiceContract Interfaces.png|300px]]

Forth, we can define the choreography for the contract:

[[File:NobleProg MonthlyFeePayment Choreography.png|300px]]

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

[[File:SoaML Multicontract Participants.png|300px]]

Ultimately, let us have a big picture:

[[File:NobleProg Franchise Financial Report (2nd way).png|300px]]

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

SoaML - ServiceArchitecture - Revision history

Bernard Szlachta at 17:36, 7 February 2016