1. OASIS Service Oriented Architecture Reference Model Technical Committee (SOA-RM) BOOT CAMP April 13 2005 DRAFT: Not approved by the OASIS SOA RM TC.

2. Purpose This slide deck is designed to bring new TC members up to speed. Work described herein defines what we have consensus on at present time. CAVEAT: Subject to change in future

3. Agenda What is SOA; what is a reference model for SOA Why is a reference model needed The OASIS SOA RM TC

4. Defining SOA If Service Oriented Architecture is Architecture, as the name implies, it should be definable as architecture. This should not be done by referencing specific implementations. Definition of Architecture (from Charter): –“Architecture: A software architecture for a system is the structure or structures of the system, which consist of elements and their externally visible properties, and the relationships among them.”

5. Closer look: “Service Oriented” Is a paradigm (model) for software architecture. –Focus herein is “software & systems architecture” “Services” are the central concept; other concepts are present. SOA not currently defined other than a “common law” or “defacto” perception of what it is. Perceptions for definition of SOA are vastly disparate.

6. What is a SOA Reference Model? Is a model for developing a range of Service Oriented Architectures and analysis/comparison thereof. Is not architecture for a single implementation. This is very important to understand since things you may see in other architecture might not be present in the Reference Model. Is a framework for understanding significant relationships among the elements of a SOA environment. Is based on concepts present in all SOA’s. A Reference Model defines SOA in an abstract sense. Example: Abstract = Service Description Concrete = WSDL

7. To develop a Reference Model for SOA The TC is asking itself these questions: –What elements are common in all implementations of SOA? ( be careful – think about this) (Paraphrased) What are the core things that make SOA service oriented? –How do we describe those as abstract concepts? –What relationships exist amongst those concepts? –How do we represent those concepts without referencing concrete implementations.

8. Draft Conceptual SOA Reference Model

9. Base Components Service: A behavior, or set of behaviors provided for use by another entity. Service Description: A specification of the information necessary to: –allow a potential consumer to determine whether or not this service is applicable, and –facilitate invocation. Advertisement: A methodology to convey awareness of (the existence of) a service(s) to all consumers on a fabric. Advertising makes discovery possible.

10. Base Components and Concepts of SOA Data Model: The logical expression of a set of information items associated with the consumption of a service or services. Contract: The syntactic, semantic and logical constraints governing on the use of a service.

11. SOA Axioms 1.A Service is a set of functionality provided by one entity for the use of others. 2.Services are conceptually autonomous (self sufficient) and opaque (independent of underlying technology) in nature. 3.There is no need to make architectural distinctions between services that are consumed as part of a process vs. ones that are not. 4.There is not always a one to one correlation between “on the wire” requests to invoke a service and service responses being consumed. 5.Each logical Service has exactly one canonical Service Description.

12. SOA Axioms 6.A Service Description is comprised of three logical parts - Data Model - The logical expression of a set of information items associated with the consumption of a service or services; - Policy - Assertions and obligations that service consumers and/or providers must adhere to or provide; and - Contract (and/or offer thereof) - the syntactic, semantic and logical constraints governing on the use of a service. 7.A security policy is a specialized type of the Service Description policy noted above. 8.Service Policy may mandate security requirements to be met, and if they are not, interaction (with the service) may be refused.

13. SOA Axioms 9.A null security policy is still logically considered a policy. 10.A Service Description is advertised to consumers on a fabric to make it discoverable. 11.Discovery does not constitute authorization to execute against the service.

14. Agenda What is SOA; what is a reference model for SOA Why is a reference model needed The OASIS SOA RM TC

15. Existing situation WSDL XML & Schema SOAP Base Standards WS-RM WS Addressing Reg/Rep UDDI WS-Security WS-Trust WS-* Requirements Question: How do I account for my requirements and organize components when building a concrete architecture?

16. Thoughts on developing specific SOA’s Probably not logical to try and develop a “one size, fits all” architecture for SOA or WS. Not rational to develop multiple architectures in standards bodies for every set of requirements. Best solution: develop an SOA reference Model. –Used by architects to guide development of specific service oriented architectures. –Model for a “way of thinking” when architecting. –Re-useable by multiple architects writing SOA for multiple domains. –Helps architects slot existing standards into their architectures.

17. SOA RM used for range of architectures WSDL XML & Schema SOAP Base Standards WS-RM WS Addressing Reg/Rep UDDI WS-Security WS-Trust WS-* Requirements Guides developments of SOA-RM Specific Architectures Uses Input for

18. Agenda What is SOA; what is a reference model for SOA Why is a reference model needed The OASIS SOA RM TC

19. OASIS SOA Reference Model TC Chartered February 2005 Problem to be solved: –"Service Oriented Architecture" (SOA) as a term is being used in an increasing number of contexts and specific technology implementations, sometimes with differing or conflicting understandings of implicit terminology and components. –The proposal to establish a Reference Model is intended to encourage the continued growth of specific and different SOA implementations whilst preserving a common layer that can be shared and understood between those or future implementations.

20. OASIS SOA Reference Model TC Purpose: –The SOA-RM TC will deliver a Service Oriented Architecture Reference Model (SOA-RM). –The TC may also create sub-committees, promotional material, liaisons or other promulgation of the TC's work, in order to promote the use of the SOA Reference Model. –May help vertical industries develop SOA for their requirements.

21. Charter Definition Reference Model: A reference model is an abstract framework for understanding significant relationships among the entities of some environment, and for the development of consistent standards or specifications supporting that environment. A reference model is based on a small number of unifying concepts. A reference model is not directly tied to any standards, technologies or other concrete implementation details, but it does seek to provide a common semantics that can be used unambiguously across and between different implementations.

22. References OASIS SOA RM TC - http://www.oasis- open.org/committees/tc_home.php?wg_abbrev= soa-rm http://www.oasis- open.org/committees/tc_home.php?wg_abbrev= soa-rm

23. Other orientation activities Review member submissions in our document repository. Review glossary - http://www.tekni.ca/twiki/bin/view/SoaRefModel/ SoaReferenceModelGlossary http://www.tekni.ca/twiki/bin/view/SoaRefModel/ SoaReferenceModelGlossary Review SOA axioms - http://www.oasis- open.org/apps/org/workgroup/soa- rm/download.php/12246/SOA%20Axioms.pdfhttp://www.oasis- open.org/apps/org/workgroup/soa- rm/download.php/12246/SOA%20Axioms.pdf Review message archives.

24. Links to non-related Reference Models 1. http://www.isotopicmaps.org/TMRM/TMRM-latest.htmlhttp://www.isotopicmaps.org/TMRM/TMRM-latest.html Short and to the point. A good demonstration of how efficient and small a good reference model can be. 2. http://www.isotopicmaps.org/tmrm/rm20031014.pdfhttp://www.isotopicmaps.org/tmrm/rm20031014.pdf A Mathematical formula of the above Reference Model for Topic Maps 3. http://www.dpconline.org/docs/lavoie_OAIS.pdfhttp://www.dpconline.org/docs/lavoie_OAIS.pdf The OAIS Reference Model overview. Another good example of a small, compact, lean reference model. 4. http://www.x12.org/x12org/comments/X12Reference_Model_For_XML_Desi gn.pdf http://www.x12.org/x12org/comments/X12Reference_Model_For_XML_Desi gn.pdf X12 reference model for XML. 120 pages – more technical. 5. http://www.digitalearth.gov/derm/v05/derm05.pdfhttp://www.digitalearth.gov/derm/v05/derm05.pdf This reference model actually brings together implementation technologies with abstract concepts. 6. http://www.wfmc.org/standards/docs/tc003v11.pdfhttp://www.wfmc.org/standards/docs/tc003v11.pdf Workflow Reference Model that includes specific technology – 55 pages