Service Oriented Architecture
This is our portal for Service Oriented Architecture Things
Some thoughts links and information on SOA
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." (http://en.wikipedia.org/wiki/Service-oriented_architecture Wikipedia, 15.06.207)
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 [1][edit]
Service Registry[edit]
Additional information on service registries
SOA Delivery lifecycle[edit]
Additional information on SOA lifecycle
eSciDoc SOA[edit]
Additional information on eSciDoc architecture
Online resources[edit]
Books[edit]
- Enterprise SOA: Service-Oriented Architecture Best Practices, Dirk Krafzig, Karl Banke, Dirk Slama, Prentice Hall(2004), ISBN-13:978-0-13-146575-6 [1]
- Service-Oriented Architecture: Concepts, Technology, and Design, Erl Thomas, Prentice Hall(2005), ISBN-13: 978-0-13-185858-9 [2]
- Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services,Erl Thomas, Prentice Hall(2004), ISBN-13: 978-0-13-142898-0 [3]