Difference between revisions of "Service Oriented Architecture"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 10: Line 10:
"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)
"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 [[[Service-Oriented Architecture: Concepts, Technology, and Design]]]


=== Service orientation principles ===


*Reusability— Regardless of whether immediate reuse opportunities exist, services are designed to support potential reuse.
*Reusability— Regardless of whether immediate reuse opportunities exist, services are designed to support potential reuse.
Line 31: Line 31:
== Books ==
== Books ==
*[http://proquest.safaribooksonline.com/0131465759 Enterprise SOA: Service-Oriented Architecture Best Practices], Dirk Krafzig, Karl Banke, Dirk Slama, Prentice Hall(2004), ISBN-13:978-0-13-146575-6
*[http://proquest.safaribooksonline.com/0131465759 Enterprise SOA: Service-Oriented Architecture Best Practices], Dirk Krafzig, Karl Banke, Dirk Slama, Prentice Hall(2004), ISBN-13:978-0-13-146575-6
*<ref name="SOAConcepts">[http://proquest.safaribooksonline.com/0131858580 Service-Oriented Architecture: Concepts, Technology, and Design], Erl Thomas, Prentice Hall(2005), ISBN-13: 978-0-13-185858-9</ref>
*[http://proquest.safaribooksonline.com/0131858580 Service-Oriented Architecture: Concepts, Technology, and Design], Erl Thomas, Prentice Hall(2005), ISBN-13: 978-0-13-185858-9
*[http://proquest.safaribooksonline.com/0131428985 Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services],Erl Thomas, Prentice Hall(2004), ISBN-13: 978-0-13-142898-0
*[http://proquest.safaribooksonline.com/0131428985 Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services],Erl Thomas, Prentice Hall(2004), ISBN-13: 978-0-13-142898-0

Revision as of 13:22, 15 June 2007

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

Online reources[edit]

Books[edit]