Service Oriented Architecture by liaoqinmei

VIEWS: 8 PAGES: 22

									Service Oriented Architecture
      Reference Model
     An informal SOA Ontology




                                1
          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.
                                                    2
Reference Model




                  3
Service Oriented Architecture
• Service Oriented Architecture is a
  paradigm for organizing and utilizing
  distributed capabilities that may be
  under the control of different ownership
  domains.
• Goal of this reference model is to define
  the essence of Service Oriented
  Architecture
                                          4
      Why Service Oriented
         Architecture?
• Drivers:
  • Large scale Enterprise systems
  • Internet scale provisioning of services
  • Reduce the cost of doing business
• Benefits
  • Build scalable, evolvable systems
     • Scalable because minimizes assumptions
  • Manage complex systems
  • Encourage re-use of business function
                                                5
         Why is it different?
• SOA reflects the reality of ownership
  boundaries
  • CORBA, RMI, COM, DCOM, etc. all try to
    implement transparent distributed systems
  • Ownership is of the essence in SOA
• SOA is task oriented
  • Services are organized by function
     • Getting something done
• SOA is inspired by human organizations
  • It worked for us, it should work for machines
                                                    6
      What is not in the RM
• Service composition
  • Choreography, orchestration
  • Process Oriented Architecture
• Organizational framework
  • Who is doing what to whom
• Specific technologies
  • not even specific architectures

                                      7
Key concepts




               8
                             Service
• A mechanism to enable access to
  one or more capabilities
   • using a prescribed interface
   • consistent with constraints and
     policies as specified by the service
     description.




                                            9
                             Visibility
Visibility is the relationship
between service participants that is
satisfied when they are able to
interact with each other



• Awareness
     • Service description
     • Discovery
• Willingness
     • Policy & contract
• Reachability
     • Communication
                                          10
                             Interaction
 Interacting with a service involves performing actions against the service




The extent to which one system can
effectively interpret information from
another system is governed by the
semantic engagement of the
various systems.
The semantic engagement of a
system is a relationship between the
system and information it may
encounter.

                                                                              11
                 Real World Effect
The purpose of using a capability is to realize one or more real world effects.
At its core, an interaction is “an act” as opposed to “an object” and the
result of an interaction is an effect (or a set/series of effects).



                                    The real world effect is couched
                                    in terms of changes to the state shared by
                                    the participants and stakeholders in
                                    a service interaction




                                                                            12
About Services




                 13
     Conditions and Expectations



• Policy
   • Constraint representing the
     intention of a participant in a
     service
• Contract
   • Constraint representing an
     agreement between two or
     more participants.
                                       14
                          Description
  The service description
  represents the information
  needed in order to use,
  manage or provide a
  service.




• Service reachability
• Service Functionality
• Service Policies
• Service Interface



                                        15
             Execution Context
The execution context is the set of infrastructure elements,
process entities, policy assertions and agreements that are
identified as part of an instantiated service interaction,
and thus forms a path between those with needs and those
with capabilities




                                                               16
    Is a Reference Model an
           Ontology?
• Establishing a vocabulary
  • A lot of definitions
     • The RM glossary has 28 entries
• Formality was considered
  • Audience is not formal
  • Mechanical processing of RM not expected



                                           17
           What about UML
• UML obvious choice for an architecture
  spec
• But,
  • Inheritance (is-a) relationship almost never
    used
  • Extraneous precision
     • E.g. we tried to define Service, not count the
       number of service providers
  • It’s so ugly <duck/>
                                                        18
An early concept map




                       19
          Concepts Maps
Concepts maps
were excellent
graphical
indices     to
text




                     Concepts, and
                     relationships.
                     All we needed    20
On the cutting-room floor…




                             21
                      Where we are
 • Committee Specification published
 • Reference Architecture effort started




http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm   22

								
To top