Difference between revisions of "Service Oriented Architecture"

From MPDLMediaWiki
Jump to navigation Jump to search
m (minor change in category)
 
(28 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{Portal|SOA}}
{{Portal|SOA}}
''Some thoughts links and information on SOA''


== On SOA definition ==
== On SOA definition ==


"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." <ref>[http://en.wikipedia.org/wiki/Service-oriented_architecture Wikipedia definition on SOA], retrieved on 15.06.200)</ref>


=== Service orientation principles [2]===
=== Service orientation principles <ref>Erl, Thomas: [http://proquest.safaribooksonline.com/0131858580 Service-Oriented Architecture: Concepts, Technology, and Design], Prentice Hall (2005), ISBN 978-0-13-185858-9</ref> ===


*'''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 21: Line 16:
*'''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.
*'''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]===
=== SOA structure <ref>Krafzig, Dirk; Karl Banke, Dirk Slama: [http://proquest.safaribooksonline.com/0131465759 Enterprise SOA: Service-Oriented Architecture Best Practices], Prentice Hall (2004), ISBN 978-0-13-146575-6</ref> ===
 


[[Image:SOAElements.jpg]]
[[Image:SOAElements.jpg]]


* IS NOT: a technology or a technology standard
* IS NOT: a technology or a technology standard
Line 33: Line 26:




=== [[Service Repository]] ===
=== Service Repository ===
Additional information on service registries
 
 
=== [[SOA Delivery lifecycle]] ===
Additional information on SOA lifecycle


==== What a service repository enables ====


== [[eSciDoc SOA]] ==
*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.


The eSciDoc system is designed as a service-oriented architecture (SOA) to implement a scalable, reusable, and extensible service infrastructure. Application- and discipline-specific solutions can then be built on top of this infrastructure. The heterogeneity of the envisioned solutions in addition imposes an efficient handling of different kinds of content.
''A service repository should be managed centrally within an organization''


A service-oriented architecture fosters the reuse of the existing services. An eSciDoc service may be reused by other projects and institutions, either remotely or locally, thus becoming one building block with a broader e-Science infrastructure. At the same time, the SOA approach of eSciDoc comes with other advantages. Instead of a complex and monolithic application, the eSciDoc service infrastructure is rather to be seen as a set of loosely coupled services, which can be specified and implemented independently. This allows for an iterative implementation strategy for services. First services may already be implemented while others are still in their design phase. Based on feedback from early adaptor users (“pilots”), new services can be easily added, thus fulfilling user expectations in a more timely and user-driven manner.
==== Service metadata in a service repository ====


The core technology used to implement the services is based on Java and XML. Instead of building the infrastructure “from a scratch”, the eSciDoc team chose to integrate existing open-source components as much as possible.
*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


eSciDoc services in general provide both SOAP and REST style interfaces. This allows for further development of solutions without con-straining the selection of the programming languages, thus accelerating their implementation and enabling the involvement of various developer groups. Even simple scripting and “Web 2.0”-style mash-ups are supported.
==== Service contract and service repository ====
*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


The eSciDoc service infrastructure groups its services into three service layers: basic services, intermediate services and application services. At present it does not implement the process layer services. We consider the implementation of process layer services at a later stage. This will enable the more complex service interactions such as service orchestration.
==== SOA development life-cycle and service repository ====
*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


For more details, check [[eSciDoc SOA]]
=== [[SOA Delivery lifecycle]] ===
 
Additional information on SOA lifecycle
See also [http://www.ges2007.de/papers/ eSciDoc – a Scholarly Information and Communication Platform for the Max Planck Society]
 
 
== Online resources ==
 
*[http://en.wikipedia.org/wiki/Service-oriented_architecture Wikipedia on SOA]
*[http://www.zapthink.com ZapThink]
*[http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm OASIS Reference model]
*[http://opengroup.org/projects/soa The Open group SOA project]




== Books ==
== References ==


*[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 [1]
<references/>
* Erl, Thomas: [http://proquest.safaribooksonline.com/0131428985 Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services], Prentice Hall (2004), ISBN 978-0-13-142898-0
* [http://www.zapthink.com ZapThink]
* [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm OASIS Reference model]
* [http://opengroup.org/projects/soa The Open group SOA project]
* [http://intertwingly.net/blog/2006/08/08/WOA-vs-ROA ROA (aka REST)]


*[http://proquest.safaribooksonline.com/0131858580 Service-Oriented Architecture: Concepts, Technology, and Design], Erl Thomas, Prentice Hall(2005), ISBN-13: 978-0-13-185858-9 [2]
== eSciDoc SOA related pages==
* [[eSciDoc_SOA | eSciDoc service architecture]]
* [[eSciDoc Service repository | eSciDoc service repository]]  


*[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 [3]
[[Category:ServiceOrientedArchitecture| ]]

Latest revision as of 13:16, 8 January 2009

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]

SOAElements.jpg

  • 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]

  1. ↑ Wikipedia definition on SOA, retrieved on 15.06.200)
  2. ↑ Erl, Thomas: Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall (2005), ISBN 978-0-13-185858-9
  3. ↑ Krafzig, Dirk; Karl Banke, Dirk Slama: Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall (2004), ISBN 978-0-13-146575-6

eSciDoc SOA related pages[edit]

Service-Oriented Architecture

Web Services Description Language

Access Control List

Service-Level-Agreement

International Standard Book Number

Enhanced Scientific Documentation

Retrieved from "https://colab.mpdl.mpg.de/mw010/index.php?title=Service_Oriented_Architecture&oldid=26272"