1. Overview of OASIS SOA Reference Architecture Ken Laskey OASIS SOA-RM RA Subcommittee 19 February 2008 Ken Laskey OASIS SOA-RM RA Subcommittee 19 February 2008

2. Purpose of OASIS SOA RA from RA draft abstract Our focus in this architecture is on an approach to integrating business with the information technology needed to support it. The issues involved with integration are always present, but, we find, are thrown into clear focus when business integration involves crossing ownership boundaries. from RA draft abstract Our focus in this architecture is on an approach to integrating business with the information technology needed to support it. The issues involved with integration are always present, but, we find, are thrown into clear focus when business integration involves crossing ownership boundaries.

3. Today’s Presentation  How OASIS SOA-RM TC thinks about RA  Current approach and models being considered  Work in progress: a lot has been done but no current guarantee of completeness or consistency throughout  How OASIS SOA-RM TC thinks about RA  Current approach and models being considered  Work in progress: a lot has been done but no current guarantee of completeness or consistency throughout

4. History of OASIS SOA Reference Model Technical Committee  Chartered to fill SOA definition gaps that plagued ebSOA TC  Began late March 2005  Bi-weekly telecons  3 face-to-face TC meetings  Numerous additional editors meetings  3630 email messages as of 15 February 2006 when first Public Review  SOA-RM became OASIS Standard October 2006  Work continues on SOA reference architecture  Chartered to fill SOA definition gaps that plagued ebSOA TC  Began late March 2005  Bi-weekly telecons  3 face-to-face TC meetings  Numerous additional editors meetings  3630 email messages as of 15 February 2006 when first Public Review  SOA-RM became OASIS Standard October 2006  Work continues on SOA reference architecture

5. What is a Reference Architecture? (1)  A reference architecture describes abstract architectural elements that apply reference model concepts and relationships to a real problem  Abstract elements must be further designed and implemented to produce concrete solutions  Abstract elements modeled independent of technologies, protocols, and products used for implementation  Reference Model vs. Reference Architecture  A reference model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain  A reference architecture identifies abstract components and their use to elaborate on what is involved in realizing the modeled entities.  The RM provides the vocabulary for describing the RA  A reference architecture describes abstract architectural elements that apply reference model concepts and relationships to a real problem  Abstract elements must be further designed and implemented to produce concrete solutions  Abstract elements modeled independent of technologies, protocols, and products used for implementation  Reference Model vs. Reference Architecture  A reference model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain  A reference architecture identifies abstract components and their use to elaborate on what is involved in realizing the modeled entities.  The RM provides the vocabulary for describing the RA

6. What is a Reference Architecture? (2)  Possible to define RAs at many levels of detail or abstraction, and for many different purposes  per the RM, there may be more than one RA based on one RM  The RA for one domain may represent a further specialization of another RA, with additional requirements over those for which the more general RA was defined ex: the security portion of a RA for a subgroup dealing with classified materials may have elements not needed for the parent organization dealing with less sensitive material  Possible to define RAs at many levels of detail or abstraction, and for many different purposes  per the RM, there may be more than one RA based on one RM  The RA for one domain may represent a further specialization of another RA, with additional requirements over those for which the more general RA was defined ex: the security portion of a RA for a subgroup dealing with classified materials may have elements not needed for the parent organization dealing with less sensitive material

7. What is a Reference Architecture? (3)  A reference architecture need not be a concrete architecture  Not completely specify all the technologies, components and their relationships in sufficient detail to enable direct implementation  Avoid detail necessary in concrete architectures that may be forced by the technology choices available at the time and not by the requirements themselves  A reference architecture need not be a concrete architecture  Not completely specify all the technologies, components and their relationships in sufficient detail to enable direct implementation  Avoid detail necessary in concrete architectures that may be forced by the technology choices available at the time and not by the requirements themselves

8. What is this Reference Architecture?  An abstract realization of SOA  Elements and their relationships needed to enable SOA- based systems to be used, realized and owned  Avoiding reliance on specific concrete technologies.  Primarily focused on large-scale distributed IT systems where the participants may be legally separate entities  Resources are distributed across ownership boundaries  People and systems interact across ownership boundaries  Security, management and governance distributed across ownership boundaries  Interaction primarily through the exchange of messages with reliability that is appropriate for the intended uses  An abstract realization of SOA  Elements and their relationships needed to enable SOA- based systems to be used, realized and owned  Avoiding reliance on specific concrete technologies.  Primarily focused on large-scale distributed IT systems where the participants may be legally separate entities  Resources are distributed across ownership boundaries  People and systems interact across ownership boundaries  Security, management and governance distributed across ownership boundaries  Interaction primarily through the exchange of messages with reliability that is appropriate for the intended uses

9. Focus of this Reference Architecture  Total cost of ownership stance showing  How SOA fits into the life of users and stakeholders in a SOA ecosystem  How SOA-based systems may be realized effectively  What is involved in owning such a SOA-based system  Purposes of this approach  Ensuring that the true value of a SOA meeting the stated requirements can be realized using appropriate technology  Permitting the audience to focus on the important issues without becoming over-burdened with the details of a particular implementation technology  Total cost of ownership stance showing  How SOA fits into the life of users and stakeholders in a SOA ecosystem  How SOA-based systems may be realized effectively  What is involved in owning such a SOA-based system  Purposes of this approach  Ensuring that the true value of a SOA meeting the stated requirements can be realized using appropriate technology  Permitting the audience to focus on the important issues without becoming over-burdened with the details of a particular implementation technology

10. What this Reference Architecture is and is not  Is not  Complete blueprint for realizing SOA-based systems  Technology map identifying all the technologies needed  Does  Identify many of the key aspects and components that will be present in any well designed SOA-based system  Make clear which technology and design choices are needed and what their purpose is  Ensuring  True value of the SOA approach can be realized on any appropriate technology  Audience focus on important issue  Is not  Complete blueprint for realizing SOA-based systems  Technology map identifying all the technologies needed  Does  Identify many of the key aspects and components that will be present in any well designed SOA-based system  Make clear which technology and design choices are needed and what their purpose is  Ensuring  True value of the SOA approach can be realized on any appropriate technology  Audience focus on important issue

11. SOA – An Ecosystems Perspective  A network of independent services, machines, people  People operate, affect, use, and govern those services  Suppliers of equipment and personnel support people and services  Nobody "in control" or "in charge" of the whole but all stakeholders have some control and influence  Not an application hierarchy, but a network of peer-like entities  Not a hierarchy of control, but rules for interactions among participants  Three key principles  SOA is a medium for exchange of value between independently acting participants  Participants (and stakeholders in general) have legitimate claims to ownership of resources that are made available via the SOA  Behavior and performance of the participants is subject to rules of engagement which are captured in a series of policies and contracts  A network of independent services, machines, people  People operate, affect, use, and govern those services  Suppliers of equipment and personnel support people and services  Nobody "in control" or "in charge" of the whole but all stakeholders have some control and influence  Not an application hierarchy, but a network of peer-like entities  Not a hierarchy of control, but rules for interactions among participants  Three key principles  SOA is a medium for exchange of value between independently acting participants  Participants (and stakeholders in general) have legitimate claims to ownership of resources that are made available via the SOA  Behavior and performance of the participants is subject to rules of engagement which are captured in a series of policies and contracts

12. Format of OASIS SOA RA  Follows ANSI/IEEE 1471 Std. - recommended practice of describing architecture in terms of models, views, and viewpoints  SOA-RA has three main views  Business via Service View - lays the foundation for conducting business in the context of SOA  Realizing Services View - addresses the requirements for constructing a SOA  Owning Service Oriented Architectures view - focuses on governance and management of SOA-based systems.  Follows ANSI/IEEE 1471 Std. - recommended practice of describing architecture in terms of models, views, and viewpoints  SOA-RA has three main views  Business via Service View - lays the foundation for conducting business in the context of SOA  Realizing Services View - addresses the requirements for constructing a SOA  Owning Service Oriented Architectures view - focuses on governance and management of SOA-based systems.

13. OASIS SOA RA Viewpoints

14. Architectural Goals of SOA-RA Demonstrate 1.Effectiveness - participants with needs interact with services accessing appropriate capabilities 2.Confidence - participants have clear expectations from interactions 3.Scalability - applicable from few services to very large systems as needed Demonstrate 1.Effectiveness - participants with needs interact with services accessing appropriate capabilities 2.Confidence - participants have clear expectations from interactions 3.Scalability - applicable from few services to very large systems as needed

15. SOA-RA Requirements being revised

16. Principles of SOA-RA  Technology Neutrality: independence from particular technologies  Parsimony: economy of design, avoiding complexity where possible and minimizing the number of components and relationships needed  Understandability: Simple terms for simple concepts  Separation of stakeholders’ concerns  Applicability: Internet SOA vs Intranet SOA, ownership boundaries, internet-ready SOA  Technology Neutrality: independence from particular technologies  Parsimony: economy of design, avoiding complexity where possible and minimizing the number of components and relationships needed  Understandability: Simple terms for simple concepts  Separation of stakeholders’ concerns  Applicability: Internet SOA vs Intranet SOA, ownership boundaries, internet-ready SOA

17. Business via Services View  Capture what using a SOA-based system means for people conducting their business  Providing and consuming services to realize mutually desirable real world effects  Involving community of people & orgs: single enterprise or peer-to-peer network of enterprises and individuals  Capture what using a SOA-based system means for people conducting their business  Providing and consuming services to realize mutually desirable real world effects  Involving community of people & orgs: single enterprise or peer-to-peer network of enterprises and individuals

18. Business via Services View – Associated Models  Service Participants Model  Resources Model  Ownership Model  Needs and Capabilities Model  Social Structure Model  Shared State and social facts  Proposition Model  Acting in a Social Context  Transactions and Exchanges Model  Roles in Social Structures  Governance and Social Structures  Service Participants Model  Resources Model  Ownership Model  Needs and Capabilities Model  Social Structure Model  Shared State and social facts  Proposition Model  Acting in a Social Context  Transactions and Exchanges Model  Roles in Social Structures  Governance and Social Structures

19. Business via Services View – Service Participants Model being revised

20. Business via Services View – Resources Model

21. Business via Services View – Ownership Model

22. Business via Services View – Needs and Capabilities Model

23. Business via Services View – Social Structure Model

24. Business via Services View – Shared State and Social Facts

25. Business via Services View – Proposition Model

26. Business via Services View – Acting in a Social Context Model

27. Business via Services View – Governance and Social Structures being revised

28. Business via Services View – Awaiting Models  Transactions and Exchanges Model  Roles in Social Structures  Transactions and Exchanges Model  Roles in Social Structures

29. Realizing Service Oriented Architectures View  Focuses on the infrastructure elements that are needed support the discovery and interaction with services  The key questions asked are "What are services, what support is needed and how are they realized?"  Focuses on the infrastructure elements that are needed support the discovery and interaction with services  The key questions asked are "What are services, what support is needed and how are they realized?"

30. Realizing SOA View - Associated Models (1)  Service Description Model  The Model for Service Description  Service Description Model: General Description Model  Model Elements Specific to Service Description  Service Interface model  Service Reachability model  Model for Policies and Contracts as related to Service Participants  Policies and Contracts, Metrics, and Compliance Records Models  Use Of Service Description  Assigning Values to Description Instances Model  Service Description in support of Service Interaction  Service Description and Action Relationship Model  Execution Context model  Service Interaction Description model  Service Description Model  The Model for Service Description  Service Description Model: General Description Model  Model Elements Specific to Service Description  Service Interface model  Service Reachability model  Model for Policies and Contracts as related to Service Participants  Policies and Contracts, Metrics, and Compliance Records Models  Use Of Service Description  Assigning Values to Description Instances Model  Service Description in support of Service Interaction  Service Description and Action Relationship Model  Execution Context model  Service Interaction Description model  Service Visibility Model  Visibility to Business Model  Publishing Description  Discovering Description  Mediated Service Awareness  Awareness In a SOA Ecosystem  Determining Willingness  Business, Description and Willingness  Establishing Reachability  Mediated Registry-Repository  Federated Registry-Repository  Mechanisms for Willingness

31. Realizing SOA View - Associated Models (2)  Interacting with Services Model  Fundamental SOA Message Exchange Patterns (MEPs)  Service Composition  Orchestration of Service-Oriented Business Process  Choreography of Service-Oriented Business Collaboration  Policy & Contracts Model  Distinguishing between Policies & Contracts  Policy Constraints Model  Permission Policy Mechanisms  Obligation Policy Mechanisms  Interacting with Services Model  Fundamental SOA Message Exchange Patterns (MEPs)  Service Composition  Orchestration of Service-Oriented Business Process  Choreography of Service-Oriented Business Collaboration  Policy & Contracts Model  Distinguishing between Policies & Contracts  Policy Constraints Model  Permission Policy Mechanisms  Obligation Policy Mechanisms

32. Realizing SOA View - Service Description Model: General Description Model

33. Realizing SOA View - Model Elements Specific to Service Description

34. Realizing SOA View - Service Interface Model

35. Realizing SOA View - Service Reachability Model

36. Realizing SOA View - Model for Policies and Contracts as related to Service Participants

37. Realizing SOA View - Policies and Contracts, Metrics, and Compliance Records Model

38. Realizing SOA View - Assigning Values to Description Instances Model

39. Realizing SOA View - Service Description and Action Relationship Model

40. Realizing SOA View - Execution Context Model

41. Realizing SOA View - Service Interaction Description Model

42. Realizing SOA View - Visibility to Business Model

43. Realizing SOA View - Publishing Description

44. Realizing SOA View - Discovering Description

45. Realizing SOA View - Mediated Service Awareness

46. Realizing SOA View - Awareness In a SOA Ecosystem

47. Realizing SOA View - Determining Willingness

48. Realizing SOA View - Business, Description and Willingness

49. Realizing SOA View - Establishing Reachability

50. Realizing SOA View - Mediated Registry-Repository

51. Realizing SOA View - Federated Registry-Repository

52. Realizing SOA View - Mechanisms for Willingness

53. Realizing SOA View - Interacting with Services Model

54. Realizing SOA View - Fundamental SOA Message Exchange Patterns (MEPs)

55. Realizing SOA View - Service Composition

56. Realizing SOA View - Orchestration of Service-Oriented Business Process

57. Realizing SOA View - Choreography of Service-Oriented Business Collaboration

58. Realizing SOA View - Distinguishing Policy & Contracts

59. Realizing SOA View - Policy Constraints Model

60. Realizing SOA View - Permission Policy Mechanisms

61. Realizing SOA View - Obligation Policy Mechanisms

62. Owning SOAs 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  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

63. Owning SOAs View – Associated Models  Governance Model  Motivating governance model  Setting up governance model  Carrying out governance model  Ensuring governance compliance model  Security Model [in progress]  Services as Managed Entities Model [in progress]  Governance Model  Motivating governance model  Setting up governance model  Carrying out governance model  Ensuring governance compliance model  Security Model [in progress]  Services as Managed Entities Model [in progress]

64. Owning SOAs View – Motivating Governance Model

65. Owning SOAs View – Setting Up Governance Model

66. Owning SOAs View – Carrying Out Governance Model

67. Owning SOAs View – Ensuring Governance Compliance Model

68. Owning SOAs View – Awaiting Models  Security Model  Security Concepts  Threat Model  Mitigation Model  Services as Managed Entities Model  Management and Governance  Management Contracts and Policies  Management Infrastructure  Service Life-cycle  Security Model  Security Concepts  Threat Model  Mitigation Model  Services as Managed Entities Model  Management and Governance  Management Contracts and Policies  Management Infrastructure  Service Life-cycle

69. Summary  Educational for those involved -- you try to describe all this instead of just falling back on buzzwords!  Planned milestones  Next consolidated draft in March  Public review later this year  Lot has been done but a lot remains Help Wanted  Educational for those involved -- you try to describe all this instead of just falling back on buzzwords!  Planned milestones  Next consolidated draft in March  Public review later this year  Lot has been done but a lot remains Help Wanted