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]

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 Registry[edit]

Additional information on service registries

SOA Delivery lifecycle[edit]

Additional information on SOA lifecycle

eSciDoc SOA[edit]

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

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.

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.

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.

For more details, check eSciDoc SOA

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]