Reference Architecture for SOA (OASIS SOA-RM TC work in-progress)

1. Reference Architecture for SOA (OASIS SOA-RM TC work in-progress) Frank McCabe Jeff Estefan Ken Laskey Danny Thornton

2. Agenda *Minutes

3. Introduction • SOA as eco system • Primary concepts from Reference Model • Plan for the tutorial

4. Systems and Eco-systems • Multiple ownership domains • No one entity controls everything • Parallel development, deployment and usage of services • A medium for people* to get their business done * We include organizations and robots, but the canonical use case is people using an SOA-based system as a medium to `act at a distance’

5. Reference Model for SOA It’s an OASIS Standard

6. What is a Reference Model • An abstract framework for understanding significant relationships among the entities of some environment. • Consists of a minimal set of unifying concepts, axioms and relationships within a particular problem domain. • Is independent of specific standards, technologies, implementations, or other concrete details.

7. Service Oriented Architecture • Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. • Goal of reference model is to define the essence of Service Oriented Architecture

8. Why is it different? • SOA reflects the reality of ownership boundaries • CORBA, RMI, COM, DCOM, etc. all try to implement transparent distributed systems • Ownership is of the essence in SOA • SOA is task oriented • Services are organized by function • Getting something done • SOA is inspired by human organizations • It worked for us, it should work for machines

9. Key concepts

10. Service • A mechanism to enable access to one or more capabilities • using a prescribed interface • consistent with constraints and policies as specified by the service description.

11. Visibility Visibility is the relationship between service participants that is satisfied when they are able to interact with each other • Awareness • Service description • Discovery • Willingness • Policy & contract • Reachability • Communication

12. Interaction Interacting with a service involves performing actions against the service The extent to which one system can effectively interpret information from another system is governed by the semantic engagement of the various systems. The semantic engagement of a system is a relationship between the system and information it may encounter.

13. Real World Effect The purpose of using a capability is to realize one or more real world effects. At its core, an interaction is “an act” as opposed to “an object” and the result of an interaction is an effect (or a set/series of effects). The real world effect is couched in terms of changes to the state shared by the participants and stakeholders in a service interaction

14. About Services

15. Conditions and Expectations • Policy • Constraint representing the intention of a participant in a service • Contract • Constraint representing an agreement between two or more participants.

16. Description The service description represents the information needed in order to use, manage or provide a service. • Service Reachability • Service Functionality • Service Policies • Service Interface

17. Execution Context The execution context is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities

18. Where the RA fits

19. Plan for Tutorial • Structure of the Reference Architecture • Three Views in Detail • Business via Service View • Realizing SOAs View • Owning SOAs View

20. This Architecture • Architectural goals & principles • What is a reference architecture? • What is this RA? • Views and viewpoints • Three views of SOA • Viewpoint specifications • UML conventions

21. Goals of this Architecture

22. Architectural Principles • Technology Neutrality • We want to focus on the issues • Parsimony • Ockham’s razor at work • Separation of Concerns • Pieces that are independent are kept separate • Applicability • We are looking for the 80/20 rule

23. What is a “Reference Architecture”? • A reference architecture elaborates further on the modelto show a more complete picture that includes showing whatis involved in realizing the modeled entities

24. What is this RA? • This Reference Architecture is an architectural description that documents (or describes) the abstract architectural elements of the paradigm that is SOA • It focuses on the elements and their relationships needed to enable SOA-based systems to be used, realized, and owned

25. What is this RA? • This Reference Architecture is an architectural description that documents (or describes) the abstract architectural elements of SOA-based systems • It focuses on the elements and their relationships needed to enable SOA-based systems to be used, realized, and owned

26. Views and Viewpoints • This RA uses the concepts of views and viewpoints as derived from the ANSI/IEEE Std 1471-2000 to describe system and software architectures • A view is a representation of the whole system from the perspective of a related set of concerns • Primarily comprised of models (although it has other attributes, e.g., textual descriptions) • A viewpoint is a specification of the conventions for constructing and using a view • Addresses stakeholders, their concerns, the language, modeling techniques, or analytical methods used in constructing views based on the viewpoint, and the source (if adapted from a viewpoint library)

27. Three Views of SOA • Using a SOA-based system • Captures what SOA means for people conducting their business • Realizing a SOA-based system • Deals with the requirements for constructing a SOA • Owning a SOA-based system • What are the issues involved in owning a SOA-based systems

28. Viewpoint Specifications

29. UML Conventions • Visual modeling notation based on Object Management Group (OMG) Unified Modeling Language (UML) • Every effort made to be compliant with latest normative standard (currently, UML V2.1.2 Superstructure) • Class diagrams reflect key concepts and relationships • Primarily use named associations (rather than roles) to model key relationships • Stereotypes used to assist in ambiguity resolution on some classifiers and to provide greater domain specialization

30. UML Conventions (2)

31. Business via Services View • What does it mean to be part of a SOA • Ownership boundaries • Acting in a Social Context • The role of policies and contracts

32. Stakeholders and Participants We use a lot of UML in this RA

33. Resources and Ownership Resources are foundational to the RA as a whole

34. Resources and Ownership Ownership is foundational to using a SOA

35. Needs and Capabilities Needs and Capabilities speak to participants’ motivations

36. Acting in a Social Context It is all about getting things done, in a social context It is all about interaction and communication

37. Semantics of Communication Communication is founded on vocabulary, semantics and intention

38. Roles and Responsibilities There is a social context for everything we do Clarity in rights and responsibilities is the foundation for security

39. Governance

40. Realizing SOAs View

41. General Description Model • Everything that is part of the SOA ecosystem can benefit from description • Some things, like service, require description for the SOA paradigm to work

42. Service Description Model • What it does • How to access it • How to communicate with it • What are conditions of use • Where to find measurements

43. Service Interface Model Note addition of Event Model and question of how that might extend Reference Model

44. Models Relating to Interaction and Policies Policies and Contracts as related to Service Participants Service Reachability • These models intended to ground description in places where it is used • May be moved from Service Description and as consistent with Service Interaction and Policy sections Policies and Contracts, Metrics, and Compliance Records

45. Service Description and Action Relationship • Classes in blue are leaf nodes in Service Description • Service Description is more than an incidental artifact • Service Description as integral information that comes together to get things done

46. Interacting with Services

47. Interaction Dependencies

48. Message Exchange & Operations • Message exchange is the means by which joint actions and event notifications of real world effects are coordinated by service participants (or their agents) • Operations are the sequence of actions a service must perform in order to validly participate in a given joint action

49. Message Exchange Patterns (MEPs)

50. Composition of Services • Composition of services is the act of aggregating or “composing” a single service from one or more other services • There are “atomic” and “composite” services • An atomic service is a service visible to a service consumer (or agent) via a single interface and described via a single service description that does not use or interact with other services • A composite service is a service visible to a service consumer (or agent) via a single interface and described via a single service description that is the aggregation or composition of one or more other services. These other services can be atomic services, other composite services, or a combination of both