1 / 24

OASIS Service Oriented Architecture Reference Model Technical Committee (SOA-RM)

OASIS Service Oriented Architecture Reference Model Technical Committee (SOA-RM). BOOT CAMP April 13 2005. DRAFT: Not approved by the OASIS SOA RM TC. Purpose. This slide deck is designed to bring new TC members up to speed.

liam
Download Presentation

OASIS Service Oriented Architecture Reference Model Technical Committee (SOA-RM)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • A Service is a set of functionality provided by one entity for the use of others. • Services are conceptually autonomous (self sufficient) and opaque (independent of underlying technology) in nature. • There is no need to make architectural distinctions between services that are consumed as part of a process vs. ones that are not. • There is not always a one to one correlation between “on the wire” requests to invoke a service and service responses being consumed. • Each logical Service has exactly one canonical Service Description.

  12. SOA Axioms • 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. • A security policy is a specialized type of the Service Description policy noted above. • Service Policy may mandate security requirements to be met, and if they are not, interaction (with the service) may be refused.

  13. SOA Axioms • A null security policy is still logically considered a policy. • A Service Description is advertised to consumers on a fabric to make it discoverable. • 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 Question: How do I account for my requirements and organize components when building a concrete architecture? Requirements WS-* WS-Security WSDL WS-Trust XML & Schema Base Standards SOAP WS Addressing UDDI WS-RM Reg/Rep

  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 SOA-RM Guides developments of Specific Architectures Requirements Input for Uses WS-* WS-Security WSDL WS-Trust XML & Schema Base Standards SOAP WS Addressing UDDI WS-RM Reg/Rep

  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

  23. Other orientation activities • Review member submissions in our document repository. • Review glossary - 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.pdf • Review message archives.

  24. Links to non-related Reference Models • 1. http://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.pdf • A Mathematical formula of the above Reference Model for Topic Maps • 3. http://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_Design.pdf • X12 reference model for XML. 120 pages – more technical. • 5. http://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.pdf • Workflow Reference Model that includes specific technology – 55 pages

More Related