1 / 22

Service Oriented Architecture Reference Model

The Service Oriented Architecture Reference Model is an abstract framework for understanding the relationships within a problem domain, independent of specific details. Discover the essence, benefits, and uniqueness of SOA with drivers like scalability and cost reduction.

wcardwell
Download Presentation

Service Oriented Architecture Reference Model

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. Service Oriented ArchitectureReference Model An informal SOA Ontology

  2. 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.

  3. Reference Model

  4. 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

  5. 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

  6. 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

  7. 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

  8. Key concepts

  9. 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.

  10. 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

  11. 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.

  12. 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

  13. About Services

  14. Conditions and Expectations • Policy • Constraint representing the intention of a participant in a service • Contract • Constraint representing an agreement between two or more participants.

  15. 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

  16. 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

  17. 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

  18. 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/>

  19. An early concept map

  20. Concepts Maps Concepts maps were excellent graphical indices to text Concepts, and relationships. All we needed

  21. On the cutting-room floor…

  22. Where we are • Committee Specification published • Reference Architecture effort started http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

More Related