1. Models of the OASIS SOA Reference Architecture Foundation Ken Laskey Chair, SOA Reference Model Technical Committee 20 March 2013

2. History ■OASIS Reference Model for Service Oriented Architecture (SOA-RM) –OASIS Standard, October 2006 –http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdfhttp://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf ■OASIS Reference Architecture Foundation for Service Oriented Architecture (SOA-RAF) –OASIS Committee Specification, December 2012 –http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/cs01/soa-ra- v1.0-cs01.pdfhttp://docs.oasis-open.org/soa-rm/soa-ra/v1.0/cs01/soa-ra- v1.0-cs01.pdf 2

3. 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. 3

4. What is a Reference Architecture ■A reference architecture elaborates further on the model to show a more complete picture that includes showing what is involved in realizing the modeled entities ■This Reference Architecture –Abstract realization of SOA –Focusing on the elements and their relationships needed to enable SOA-based systems to be used, realized, and owned –At the more abstract end of the continuum, and constitutes what is described in [TOGAF v9] as a foundation architecture  SOA-RAF 4

5. Architectural Relationships 5

6. Use of UML Notation ■Visual modeling notation based on Unified Modeling Language (UML) ■Used as standard modeling representation ■When conflict between formalism and more accessible expression of ideas, emphasized accessibility ■For example, Trusting Actor and Trusted Actor are roles rather than separate classes ■Decision that this is imperfect modeling but useful way to convey intended ideas ■Other visuals 6

7. 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) ■Views used in SOA-RAF –Participation in a SOA Ecosystem View –Realization of a SOA Ecosystem View –Ownership in a SOA Ecosystem View 7

8. Viewpoint Definition 8

9. Participation in a SOA Ecosystem View 9

10. SOA Ecosystem and Social Structure 10 Participation in a SOA Ecosystem View

11. Stakeholders, Actors, Participants and Delegates 11 Participation in a SOA Ecosystem View

12. Social Structures, Roles and Action 12 Resources Participation in a SOA Ecosystem View

13. 13 Participation in a SOA Ecosystem View Willingness and Trust

14. Policies, Contracts and Constraints 14 Participation in a SOA Ecosystem View A Policy is an enforceable constraint on the behavior and states of participants and resources that is adopted by a stakeholder A Contract is an enforceable constraint on the behavior and states of participants and resources that is agreed to by two or more actors

15. Activities and Action 15 An Activity, expressed informally as a graph of Actions, with a single Start point and alternative End points Activity involving Actions across an ownership boundary Participation in a SOA Ecosystem View Joint Action – The coordinated set of actions involving the efforts of two or more actors to achieve an effect.

16. Realization of a SOA Ecosystem View 16 Realization of a SOA Ecosystem View

17. General Description 17 Realization of a SOA Ecosystem View Everything that is part of the SOA ecosystem can benefit from description Some things, like service, require description for the SOA paradigm to work

18. Representation of a Description 18 Realization of a SOA Ecosystem View

19. Service Description 19 What it does What are conditions of use Where to find measurements How to communicate with it How to access it Realization of a SOA Ecosystem View

20. Service Interface Description 20 Realization of a SOA Ecosystem View

21. Models Relating to Interaction and Policies 21 Service Functionality Policies and Contracts as related to Service Participants Policies and Contracts, Metrics, and Compliance Records These models intended to ground description in places where it is used

22. Realization of a SOA Ecosystem View Relationship between Action and Components of Service Description Model 22 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

23. Execution Context & Interaction Description 23 Realization of a SOA Ecosystem View

24. Visibility to Business 24 Realization of a SOA Ecosystem View

25. Awareness in a SOA Ecosystem 25 Realization of a SOA Ecosystem View

26. Service Reachability 26 Realization of a SOA Ecosystem View

27. Interaction Dependencies 27 Realization of a SOA Ecosystem View

28. Actions, Events, and Message Exchange 28 Realization of a SOA Ecosystem View

29. Fundamental SOA Message Exchange Patterns (MEPs ) 29 Message exchange is the means by which joint actions and event notifications of real world effects are coordinated by service participants (or their agents) Realization of a SOA Ecosystem View

30. Simple Model of Service Composition 30 Composition of services is the act of aggregating or “composing” a single service from one or more other services Often discussed in terms of “atomic” and “composite” services But that turned out not to be a distinction Realization of a SOA Ecosystem View

31. Service-Oriented Business Processes 31 Abstract example of a simple business process exposed as a service Realization of a SOA Ecosystem View

32. Service-Oriented Business Collaborations 32 Abstract example of a more complex composition that relies on collaboration Realization of a SOA Ecosystem View

33. Ownership in a SOA Ecosystem View 33 Ownership in a SOA Ecosystem View Focuses on functions required in achieve value for the enterprise by owning a SOA-based system Significantly different challenges to owning other complex systems -- such as Enterprise suites Strong limits on the control and authority of any one party when a system spans multiple ownership domains Applicable when multiple internal stakeholders involved and no simple hierarchy of control and management

34. Governance Models (1) 34 Ownership in a SOA Ecosystem View Motivating Governance Setting Up Governance Governance is about how decisions are made Management is about how decisions are realized Nested – management at one level is governance at another

35. Governance Models (2) 35 Ownership in a SOA Ecosystem View Ensuring Governance Compliance Carrying Out Governance

36. Relationship Among Types of Governance 36 SOA infrastructure – the ‘plumbing’ that provides utility functions that enable and support the use of the service Service inventory – the requirements on a service to permit it to be accessed within the infrastructure Participant interaction – the consistent expectations with which all participants are expected to comply Ownership in a SOA Ecosystem View

37. Security – Authorization 37 Ownership in a SOA Ecosystem View Security topics Secure Interaction Concepts Where SOA Security is Different Security Threats Security Responses Access Control

38. Management ■Manageability – a capability that allows a resource to be controlled, monitored, and reported on with respect to some properties Service inventory – the requirements on a service to permit it to be accessed within the infrastructure ■Manageability property – a property used in the manageability of a resource. The fundamental unit of management in systems management 38 Ownership in a SOA Ecosystem View

39. Management in SOA Ecosystem 39 Ownership in a SOA Ecosystem View

40. Management Means and Relationships 40 Ownership in a SOA Ecosystem View

41. Management of the Service Interaction 41 Ownership in a SOA Ecosystem View

42. SOA Testing 42 Ownership in a SOA Ecosystem View ■No models! ■Traditional Software Testing as Basis for SOA Testing ■Testing and the SOA Ecosystem ■Elements of SOA Testing ■Testing SOA Services

43. Conformance and Architectural Implications ■SOA-RAF Target Architecture – an architectural description of a system that is intended to be viewed as conforming to the SOA ‑ RAF ■The SOA-RAF focuses on concepts, and the relationships between them, that are needed to enable SOA-based systems to be realized, owned, and used. The Architectural Implications reflect specific elements that will be reflected in a more concrete architecture based on the SOA-RAF. 43

44. Excerpt of Architectural Implications The discussion of SOA Testing indicates numerous architectural implications that are to be considered for testing of resources and interactions within the SOA ecosystem: ■SOA services MUST be testable in the environment and under the conditions that can be encountered in the operational SOA ecosystem. ■The distributed, boundary-less nature of the SOA ecosystem makes it infeasible to create and maintain a single testing substitute of the entire ecosystem to support testing activities. Test protocols MUST recognize and accommodate changes to and activities within the ecosystem. ■A standard suite of monitoring services SHOULD be defined, developed, and maintained. This SHOULD be done in a manner consistent with the evolving nature of the ecosystem. ■Services SHOULD provide interfaces that support access in a test mode. 44 MUST and SHOULD used per IETF RFC 2119

45. Conformance and Architectural Implications Conformance can therefore be measured both in terms of how a SOA-RAF Target Architecture uses the concepts and models outlined in the SOA-RAF; and how the various Architectural Implications have been addressed. ■Concepts described in the RAF SHOULD be expressed and used in the target architecture. If used, such expression MUST reflect the relationships identified within this document. ■Terminology within the target architecture SHOULD be identical to that in the RAF and the terms used refer to the same concepts; and any graph of concepts and relationships between them that are used MUST be consistent with the RAF ■The SOA-RAF Target Architecture MUST take account of the Architectural Implications in the sections listed above 45

46. Current Status of SOA-RAF ■Approved as Committee Specification through formal vote of Technical Committee ■Discussions underway with IEEE effort to create SOA Reference Architecture. ■Awaiting review and discussions in IEEE working group before move on to OASIS Standard 46