Service-Oriented Architectures Instructor: Dr. Hany H. Ammar Dept. of Computer Science and...

Service-Oriented Architectures

Instructor: Dr. Hany H. Ammar

Dept. of Computer Science and Electrical Engineering, WVU

outline

Review of SOA The IBM Rational Software Development

Platform– The IBM Rational Unified Process for SOA

Software Service Engineering Developing Service Oriented Product

Lines

Introduction

Service-oriented architecture (SOA) is an architectural style based on common principles and patterns

These include Business Process Choreography and Enterprise Service Bus (ESB)

They allow engineers to effectively organize and deploy executable business processes, as loosely-coupled software services.

SOA is based on domains that include business process management, distributed computing, enterprise application integration, and software architecture,

What is SOA?A Technical Perspective

A Service Oriented Architecture is a collection of self-contained services that can communicate with each other.

Key characteristics of services: loosely coupled coarse grained typically published & available for invocation on a

Service Bus • Defining services at a “business level” enables

rapid composition of end-to-end business processes, delivering on the promise of greater IT flexibility and agility

SOA Elements Model

This diagram from „Web Services Architecture“ shows internal and external elements of the SOA architecture. Action e.g. is not an externally visible element. Note the important roles of „policy“ and „semantics“

Calls for a Paradigm Shift

Service Oriented Architecture

Functionality DrivenFunctionality Driven

Long development cyclesLong development cycles

Tightly CoupledTightly Coupled

Application SpecificApplication Specific

Designed to lastDesigned to last

Data OrientedData Oriented

Traditional Architecture

Process OrientedProcess Oriented

Iterative developmentIterative development

Loosely CoupledLoosely Coupled

HeterogeneousHeterogeneous

Designed for changeDesigned for change

Business Service OrientedBusiness Service Oriented

SOA v/s Traditional Architecture

But must be built on standards to enhance interoperability

Service-Oriented Architecture: Key Concepts Service A unit of business functionality that can be

invoked over the network

Web service A service that is called in a standard way, so anyone can use it without knowing its internals

“Loosely coupled”

When services are self-contained, and can be easily combined and disassembled, they are called loosely coupled.

Service-Oriented Architecture

A standards-based platform that lets you model, develop, find, and combine services into flexible business processes

Orchestration & Choreography

Combining and assembling services into a coherent business process – also known as business process management

Process Services

Orchestration

System BPM

Business Logic

Databases

Data Services

Enterprise Service Bus (ESB)

Systems of Record

Web Portals

Human Business Process Management (BPM)

Sec

urity

Reg

istr

y an

d R

epos

itory

Man

age

and

mon

itor

A Map of SOA Components

Invocation Synchronous and asynchronous transport protocols, service mapping (locating and binding)

Routing Addressability, static/deterministic routing, content-based routing, policy-based routing

Mediation Adapters, protocol transformation, service mapping

Messaging Message processing, message transformation and message

enhancement

Service Oriented Architecture (SOA) Style: Service Oriented Architecture (SOA) Style: The Enterprise Service Bus ESB The Enterprise Service Bus ESB FunctionsFunctions

Business Process Management• BPM is a structured approach that models an

enterprise's human and machine tasks and the interactions between them as processes

• Evolving from document management, workflow andenterprise application integration (EAI), a BPM system can monitor and analyze tasks

jBPM vision for BPM

BPEL example: Withdrawing and depositing

services of the banking system logic

Sample ESB

• Custom Services

• Transformation Services

• Orchestration

• Routing

• Application ServerB

PE

L S

ervi

ce

1

5

4 23

T

rans

form

S

ervi

ce

G

atew

ay S

ervi

ce

Rou

ting

Ser

vice

J2EE Application Server

Web

Servlet

Portlet

JMS

EJB

MDB

SSB

JCA

Cus

tom

Ser

vice

BPEL and SOA

outline




Lines

Model-Driven IBM SOA Foundation

The IBM SOA Foundation is a modular, integrated, and open set of software, best practices, and patterns that support the complete SOA lifecycle.

Business-Driven Development for SOA The IBM Rational Software Development Platform

The IBM Rational Software Development Platform

The IBM Rational Unified Process

The IBM Rational Unified Process

IBM Rational Unified Process, or RUP®, is a configurable software development process platform that delivers proven best practices and a configurable architecture.– The RUP Plug-In for SOA integrates support for service-

oriented architecture and service-oriented solutions into the RUP framework with SOA-specific concepts, guidelines, activities, artifacts, and tool mentors.

– The RUP Plug-In for WebSphere Business Modeler updates the Business Modeling discipline in RUP to leverage WebSphere Business Integration solutions and provide a unified approach for business modeling based on the essential capabilities of the IBM Rational Software Development Platform.

Transforming BPEL to UML

The IBM Rational Unified ProcessTop-Down development Rational Application Developer greatly simplifies

the process of creating a Web service top-down based on requirements specifications and UML models.

It automatically generate WSDL files that contain an XML schema to describe Web services, as well as skeleton JavaBeans or Enterprise JavaBean (EJB) files.

It also includes an XML schema definition (XSD) editor for specifying message format.

The IBM Rational Unified ProcessBottom-Up Development and Maintenance

When working bottom-up from an existing set of Java classes or EJBs, Rational Application Developer can also automates much of the process of turning those components into a Web service.

An easy to use Wizard will generate WSDL interfaces to methods in the Java Class, a SOAP deployment descriptor, and a Web page to be used as a test client to test interactions with the Web service.

It also has J2EE Connector Architecture tools that let the developer easily integrate existing Enterprise Information Systems (EIS) such as CICS or IMS into their SOA solution.

outline




Lines

Software Service Engineering

Software service engineering entails the science and application of concepts, models, methods, and tools to – define, – design, – develop/source, integrate, test, deploy, provision,

operate, and – evolve business-aligned and SOA-enabled software

systems in a disciplined and routinely manner.

Dagstuhl Seminar Proceedings 09021Software Service Engineering http://drops.dagstuhl.de/opus/volltexte/2009/2041


In 2009, a seminar was organized around the following themes:1. What are the novelties in Software Service Engineering

(SSE)?

2. Top-down SSE starting from business architecture and mapping to Information Technology (IT) architecture.

3. Bottom-up SSE service composition and service enablement of existing (legacy) applications.

4. Recurring design issues in meet-in-the-middle service realization and patterns for them.


What is new in Software Service Engineering (SSE)? The current models, techniques, and concepts of SSE fall

short in designing service-based systems that operate in open, dynamic, and uncontrolled environments.

SSE involves combining various programming models and development paradigms, including event-driven and asynchronous programming, declarative programming, process modeling, and protocol design.


Top-down SSE starting from business architecture and mapping to Information Technology (IT) architecture Currently, many uncorrelated approaches and tools are

available for developing SOAs on the one hand and for facilitating business (process) modeling on the other hand.

It remains a challenge, however, how these methods and supporting toolsets can be seamlessly integrated to formulate a holistic approach in which software services can be identified, specified, realized, tested, deployed, managed, and evolved in a consistent and standardized fashion.


Bottom-up SSE service composition and service enablement of existing (legacy) applications Technology is moving towards ubiquitous Internet

of services which combines software services with mobile devices, sensor networks, and social networks.

This leads towards the concept of services everywhere fuelled by various very heterogeneous building blocks.

There is a growing need for integrated approaches that cater for redeployment of legacy resources as services on clouds.


Architectural decision models and tools for meet-in-the-middle service realization Investigate how service design knowledge can

be made reusable and how to identify, make, and enforce architectural decisions during SOA design.

Architectural decision models complement pattern languages with domain-specific guidance and technology and asset-level refinements.


The observations conclusions were distilled into a set of defining SSE tenets, which fall in three complementary dimensions: architectural (platform), process, and engineering


The architectural (platform) tenets were compiled as follows:

• Service is the key design and runtime concept; a service is described by its contract.

• The services described in a contract are provided by endpoints (providers) and invoked by service requesters.

• Composition of services is facilitated by the service contract.

• Services communicate via document exchange using messaging technology.

• The service communication leverages protocols, which may support request coordination and support for conversations.

• Service virtualization supports location transparency.


From a process perspective, they identified the following process tenets:– • Scoping (application boundaries)/context. Services

should be designed in such a way that they routinely support business processes. This implies a scoping of processes so that their supporting software services are logically cohesive and loosely coupled, minimizing message, protocol, and context dependencies.

• Lifecycle, ownership, and versioning. The objective of SOA is to manage the lifecycle of a service starting from business goals over service definition, through deployment, execution, measurement, analysis, change, and redeployment.


process tenets (cont.):– Lifecycle, ownership, and versioning (cont.)

Specifically, during their life services are subject to two broad classes of changes: low-impact changes versus intrusive changes.

Intrusive changes include operational behavior changes and policy-induced changes,

Low-impact changes demand a comprehensive service versioning strategy that may cater for forward and backward compatibility.

A key issue regarding version management entails ownership of service data, logic, and transactions, especially in the context of processes that cross organizational boundaries.

Software Service Engineering process tenets (cont.):

– Reuse and variability. To cater for reuse in various process contexts, services should be designed as differentiated services that allow for multiple levels of service, depending on service request(er). Functional variability may also be built in by parameterization, delegation, or specialization/generalization.

– Governance and roles. Successful implementation and management of service-enabled processes is directly dependent on a strict service governance framework that clearly defines chains of responsibility, measurements to gauge efficacy, and controls to check on compliance.


Engineering tenets were established as follows:1. Technical federation

2. Dynamism

3. Organizational federation.

4. Boundaries.

5. Heterogeneity

6. Business-IT alignment.

7. Holistic approach.

We will discuss the first 4 tenets


Engineering tenets were established as follows:1. Technical federation. SSE has to cater for

service-enabled software applications that are highly distributed in nature with many asynchronous interactions between services.

SSE has to deal with services that may be deployed on various runtime platforms, including mobile devices, computing clouds, and legacy systems, and have been developed in various programming paradigms – including, but not limited to, OOAD and CBD.


Engineering tenets (cont.)2. Dynamism. A key tenet of SSE,

dynamism regarding both the services that are aggregated into dynamic service compositions via late binding – possibly into agile service networks

dynamism regarding the highly volatile context in which they operate. Firstly, dynamism implies that SSE methods, techniques, and tools have to deal with emergent properties and behavior of complex service networks, which may in fact be comprised of thousands of independent – yet cooperating – services.


Engineering tenets (cont.)– Dynamism. A key tenet of SSE,

This signifies that software applications that have been designed in accordance with SSE typically exhibit unpredictable, non-linear and non-deterministic behavior. Dynamism puts requirements on virtually all layers of the typical SOA stack

Late binding and loose coupling constitute two key principles for increasing the adaptability of service applications and for accommodating dynamic (re-)composition as well as (re-)configuration of services in a network.


Engineering tenets (cont.)– Dynamism. A key tenet of SSE

SSE has to accommodate various styles of composition, fostering user-friendly enterprise service mash-ups as well as heavy-weight compositions of industry strength enterprise applications by service development professionals.


Engineering tenets (cont.)– 3. Organizational federation.

Development and maintenance (operations) must be typically achieved in highly distributed organizational environments, involving multiple departments, units, enterprises, and governmental organizations.

Development and maintenance of applications will be a collaborative effort, implying that in fact design, coding, deployment etc. will occur in networks of collaborative service clients and providers.


4. Boundaries: Services developed with SSE methods or tools have to be endowed with clear and explicit boundaries. Services developed with SSE methods or tools have to be

endowed with clear and explicit boundaries. In particular, SSE has to respect service contracts that capture goals and constraints (pre- and post-conditions and invariants),

An intrinsic part of the service contract entails the service interface that clearly specifies the messages a service understands and the service endpoints that are available.

Enriching the service interfaces with additional semantic information such as scenarios or behaviors allows a more robust and stable service composition


What is the most important challenge of SSE? 32 participants submitted an answer, the top scored answers are as

follows:1. Address the ‘open-world’ assumption: unforeseen clients, execution

context, usage (16 points)2. Bridging a modeling chasm: design/develop and delivery/execution

(15)3. ‘Open world assumption’: uncertainty (15)4. IT-business alignment, adaptability (15)5. Alignment of technical and business engineering for services (14)6. New models and abstractions to represent and handle SOA dynamics

(14)7. To develop software without knowing in which context it is used (14)

outline



Software Service Engineering Developing Service Oriented Product Lines

– Heterogeneous Style based ArchitectureModel (HEART)

Developing Service Oriented Product Lines

Developing Service Oriented Product Lines The levels of Services

– Molecular services: The mass of low level services ( atomic services) are grouped into richer services as required by the product family are called ‘molecular’ services.

– Orchestrating services: High level services, that are specified first as workflows and

– their constituting tasks. The system integration and deployment activity

form a product and the orchestrating services provide services to users by integrating and parameterizing the molecular services at runtime.

Developing Service Oriented Product Lines Example: The virtual office of the future (VOF)

Developing Service Oriented Product Lines Example: The virtual office of the future (VOF) Molecular Service Specification

1: molecular service FOLLOW ME (user User)2: invariants user.employeeStatus == true3: precondition user.authentification == logged_in4: postcondition none;5: option Environment Visualization6: binding time runtime7: precondition user.device == desktop notebook8: postcondition none;9: option Automatic Log-on10: binding time runtime11: precondition user.rank == director manager and12: RFID bases user location method == available13: postcondition user.access == granted rejected;

Heterogeneous Style based ArchitectureModel (HEART)

Design Goals1. Support for late binding of networked resources to their

consumers:

2. Support for mobile products

3. Support for four main functionalities of a resource consumer: a resource consumer should be able to maintain connectivity to the system domain, recognize current context, interact with a user, and manage multiple active services at a certain moment.

4. Support for service level classification

5. Support for dynamic reconfiguration


The HEART model consists of three decomposition levels to address design goals


The next decomposition level supports the third design goal by adapting the communicating process style.


The next decomposition level supports the fourth and fifth design goals by adapting C2 style, which provides flexibility through its layered structure and modular components (called "bricks.“), a brick can send/receive messages to/from other bricks through its top and bottom ports, and bus-style connectors connecting ports.

References SOA Development Using the IBM Rational Software

Development Platform: A Practical Guide

Dagstuhl Seminar 09021: Software Service Engineering, An Executive Summary, Willem-Jan van den Heuvel1, Olaf Zimmermann2, Frank Leymann3, Tony Shan, 2009

An Approach for Developing Service Oriented Product Lines, Jaejoon Lee, Dirk Muthig and Matthias Naab, 12th International Software Product Line Conference, 2008 IEEE

Conclusions

This lectures reviewed the concepts of SOA We discussed the IBM Platform for SOA

application development We also discussed concepts of Software

Service Engineering Presented briefly an approach for SSE

development using product-line architecture concepts

Service-Oriented Architectures Instructor: Dr. Hany H. Ammar Dept. of Computer Science and...

Documents

Transcript of Service-Oriented Architectures Instructor: Dr. Hany H. Ammar Dept. of Computer Science and...