OASIS Service Oriented Architecture Reference Model Technical by iqm86975

VIEWS: 0 PAGES: 24

									                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.
• Work described herein defines what we have
  consensus on at present time.
• CAVEAT: Subject to change in future
                   Agenda

• What is SOA; what is a reference model for SOA
• Why is a reference model needed
• The OASIS SOA RM TC
                   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.”
       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.
       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
   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.
Draft Conceptual SOA Reference Model
                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.
  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.
                     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.
                        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.
                   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.
                   Agenda

• What is SOA; what is a reference model for SOA
• Why is a reference model needed
• The OASIS SOA RM TC
                 Existing situation




                                  Question: How do I account for
Requirements                      my requirements and organize
                                  components when building
                                  a concrete architecture?



                   WS-Security             WS-*
                                 WSDL     XML & WS-Trust
Base Standards
                      SOAP               Schema
                                             WS
                    UDDI         WS-RM    Addressing Reg/Rep
   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.
SOA RM used for range of architectures
                                        SOA-RM
                    Guides developments of




Requirements                        Specific
                   Input for      Architectures

                                             Uses



                 WS-Security             WS-*
                               WSDL     XML & WS-Trust
Base Standards
                    SOAP               Schema
                                           WS
                  UDDI         WS-RM    Addressing Reg/Rep
                   Agenda

• What is SOA; what is a reference model for SOA
• Why is a reference model needed
• The OASIS SOA RM TC
       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.
      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.
             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.
                References

• OASIS SOA RM TC - http://www.oasis-
 open.org/committees/tc_home.php?wg_abbrev=
 soa-rm
          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.
     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_Desi
    gn.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

								
To top