2 (18) - SOFTWARE ARCHITECTURE Service Oriented Architecture - Sven Arne Andreasson - Computer Science and Engineering.

(1)

1 (18) - SOFTWARE ARCHITECTURE Service Oriented Architecture - Sven Arne Andreasson - Computer Science and Engineering

Service Oriented Architecture

Definitions

Services

Organizational Impact

SOA principles

Web services

Definition (1)

A service-oriented architecture is essentially a collection of services.

These services communicate with each other.

The communication can involve either simple data passing or it could involve two or more services coordinating some activity.

Some means of connecting services to each other is needed

Definition (2)

Unifies business processes by structuring large applications as an ad hoc collection of smaller modules called “services”.

Integration of company’s information systems. All systems share the same information, e.g. customer personal data.

Service Oriented Architecture (SOA) provides a design framework with a view to realizing rapid and low- cost system development and to improving total system-quality. SOA may use web services standards and web technologies and is rapidly becoming a standard approach for enterprise information systems.

The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification.

Definition (3)

Service-oriented architecture (SOA)

provides methods for systems development and integration where systems group functionality around business processes and package these as interoperable services.

A SOA infrastructure allows different applications to exchange data with one another as they participate in business processes.

Service-orientation aims at a loose coupling of services with operating systems, programming languages and other technologies that underlie applications.

SOA separates functions into distinct units, or services, which developers make accessible over a network in order that users can combine and reuse them in the production of business applications.

These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

(from Wikipedia)

(2)

Services

A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services.

Services generally adhere to the following principles of service-orientation:

abstraction

autonomy

compose ability

discoverability

formal contract

loose coupling

reusability

statelessness

Organizational Impact

Some researchers claim that SOA will affect the whole organization, not only the information system:

not only technology but

cultural change

A Service Oriented organization.

and even Object-Oriented

Business Modeling

Often Business Modeling is part of a Software project.

From Traditional Architecture to SOA

Traditional

Application Layer

Business Logic Layer

Information Layer

SOA

Services Application Layer

Information Layer

(3)

SOA, more sophisticated

Application Layer

Information Layer Business Services Application Services

SOA Orchestration

SOAs build applications out of software services.

Services comprise intrinsically unassociated units of functionality that have no calls to each other embedded in them.

They typically implement functionality most humans would recognize as a service, e.g.

• filling out an online application for an account,

• viewing an online bank-statement, or

• placing an online booking or airline ticket order.

Instead of services embedding calls to each other in their source code, they use defined protocols that describe how one or more services can “talk” to each other.

Orchestration

A business process expert links and sequence services, to provide business system requirements.

associating relatively large chunks of software functionality (services) in a non-hierarchical arrangement (in contrast to a class hierarchy)

using a special software tool that contains an exhaustive list of all of the services, their characteristics, and a means to record the designer's choices that the designer can manage and the software system can consume and use at run-time.

SOA principles

Guiding principles for development, maintenance, and usage of the SOA:

Reuse, granularity, modularity, compose ability, componentization, portability, and inter operability

Standards compliance (both common and industry-specific)

Services identification and categorization, provisioning and delivery, and monitoring and tracking

Service Principles

Service encapsulation

• Many web services are consolidated to be used under the SOA. Often such services were not planned to be under SOA.

Service loose coupling

• Minimize dependencies

• only require that they maintain an awareness of each other

Service contract

• Services adhere to a communications agreement defined by one or more service description documents

Service abstraction

• Services hide logic from the outside world

Service reusability

(4)

Service Principles (cont.)

Service compose ability

• Collections of services can be coordinated and assembled to form composite services

Service autonomy

• Services have control over the logic they encapsulate

Service optimization

• All else equal, high-quality services are generally considered preferable to low-quality ones

Service discoverability

• Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms

Service Relevance

• Functionality is presented at a granularity recognized by the user as a meaningful service

Additional Principles

efficient use of system resources

service maturity and performance

EAI Enterprise Application Integration

SOA Implementation

Implementors commonly build SOAs using Web services standards (for example, using SOAP).

One can, however, implement SOA using any service-based technology, such as Jini, CORBA or REST.

Web services

Web services can implement a service-oriented architecture.

Web services make functional building-blocks accessible over standard Internet protocols independent of platforms and programming languages.

Web services use the SOAP communication protocol.

SOAP is a standardized XML message (W3C).

uses Request and Response.

Web services consist of a Service Provider and a Service Requester (Web service client).

Web services use Web Service Description Language (WSDL) to describe the service.

Web services use Universal Discovery, Description and Integration (UDDI) to localize the services.

Web services are platform independent.

(5)

Benefits

SOA can help businesses respond more quickly and cost-effectively to changing market conditions.

SOA promotes reuse at the macro (service) level rather than micro (classes) level.

SOA can also simplify interconnection to – and usage of – existing IT (legacy) assets.

An indirect benefit of SOA is dramatically simplified testing.

Services are autonomous, stateless, with fully documented interfaces, and separate from the cross- cutting concerns of the implementation.

Criticisms of SOA

Is there anything new?

The use of XML will result in additional XML layers, Performance problems.

But, XML is part of Web Services and not of SOA. SOA can use other communication techniques, e.g. CORBA (which also might have performance problems!).

If we require Stateful services both the consumer and the provider will have to share the same consumer- specific context, which is either included in or referenced by messages exchanged between the provider and the consumer.

This could reduce the overall scalability of the service provider.

It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult.

Applying the SOA paradigm to a real-time system presents many problems, including response time, support of event-driven, asynchronous parallel applications, complicated human interface support, reliability, etc.