Service Oriented Architecture
Jump to navigation
Jump to search
This is our portal for Service Oriented Architecture Things
On SOA definition[edit]
"There is no widely-agreed upon definition of service-oriented architecture other than its literal translation that it is an architecture that relies on service-orientation as its fundamental design principle. Service-orientation describes an architecture that uses loosely coupled services to support the requirements of business processes and users. Resources on a network in an SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation. These concepts can be applied to business, software and other types of producer/consumer systems." [1]
Service orientation principles [2][edit]
- Reusability — regardless of whether immediate reuse opportunities exist, services are designed to support potential reuse.
- Formalized contracts— For services to interact, they need not share anything but a formal contract that describes each service and defines the terms of information exchange.
- Loose coupling - services are loosely coupled— Services must be designed to interact without the need for tight, cross-service dependencies.
- Abstraction - of logic-the only part of a service that is visible to the outside world is what is exposed via the service contract. Underlying logic, beyond what is expressed in the descriptions that comprise the contract, is invisible and irrelevant to service requestors.
- Composability- services may compose other services. This allows logic to be represented at different levels of granularity and promotes reusability and the creation of abstraction layers.
- Autonomous - the logic governed by a service resides within an explicit boundary. The service has control within this boundary and is not dependent on other services for it to execute its governance.
- Statelessness - services should not be required to manage state information, as that can impede their ability to remain loosely coupled. Services should be designed to maximize statelessness even if that means deferring state management elsewhere.
- Discoverability - services should allow their descriptions to be discovered and understood by humans and service requestors that may be able to make use of their logic.
SOA structure [3][edit]
- IS NOT: a technology or a technology standard
- IS: high-level concept that provides architectural blueprints
- FOCUS: slicing, dicing, and composition
- RELATION: services represent business functionality
Service Repository[edit]
What a service repository enables[edit]
- discovery of a service, information on how to use the service
- information on the physical location, the service provider, contact persons, fees, technical constraints, security issues, and available service levels
- if cross-enterprise service integration: legal issues (terms and conditions of usage), style of presentation, security, user registration, service subscription, billing and versioning.
A service repository should be managed centrally within an organization
Service metadata in a service repository[edit]
- Service name, operation and arguments signatures (WSDL, XMLSchema)
- Service owner (business level, development level and operations level).
- Access rights such as ACL information and the underlying security mechanism, or a description of the process that must be followed so that a new system can utilize a particular service.
- Intended performance and scalability of the service, including average response times, and potential throughput limitations. This can be summarized as part of a generic SLA (Service Level Agreement) template.
- Transactional properties of the service and its individual operations(idempotency, compensation)
- Binding information. Development-time binding vs. Run-time binding
Service contract and service repository[edit]
- service contract is not pure "machine-readable" i.e. WSDL but contains also human-readable information
- service repository should also hold service contracts
- service repository is structured set of service contracts
SOA development life-cycle and service repository[edit]
- SOA development life-cycle should be supported by the service repository
- manual "management" of services in SOA becomes impossible as the number of services grows
SOA Delivery lifecycle[edit]
Additional information on SOA lifecycle
References[edit]
- ↑ Wikipedia definition on SOA, retrieved on 15.06.200)
- ↑ Erl, Thomas: Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall (2005), ISBN 978-0-13-185858-9
- ↑ Krafzig, Dirk; Karl Banke, Dirk Slama: Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall (2004), ISBN 978-0-13-146575-6
- Erl, Thomas: Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services, Prentice Hall (2004), ISBN 978-0-13-142898-0
- ZapThink
- OASIS Reference model
- The Open group SOA project
- ROA (aka REST)