Service-oriented Architecture with Respect to Reusability

Shahid Bahonar University of Kerman

An Introduction to

Service Oriented Development

with respect to

Reusability


Prof. H. Sanat NamaProf. of Computer Science Dept. at Shahid

Bahonar University of Kerman

Supervised by:


Ali ShakibaLecture#1Hamid Bahrol OlumLecture#2ArabLecture#3GhainiLecture#4

Group 2Service-Oriented

Development

Table of Contents

Introduction to Service Oriented

Reusability and its relation with SOA

SOA Tools

SOA Case Studies 33

00

11

22

Green IT

کارآییاقتصادی

کارآییاجتماعی

کاراییاکولوژی

؛ استفاده بهینه و موثر Green ITهدف از منابع رایانه ای به منظور رسیدن به سه هدف فوق می باشد. یعنی در کنار

تالش برای رسیدن به کارآیی اقتصادی؛ همزمان کارآیی محیط زیست و اجتماع

نیز منظور شود.

Green IT


Introduction to Service-Oriented

Lecture # 1


presented by:

Ali Shakiba<a.shakiba.iran@gmail.

com>// I can guarantee no fast responses!

Table of Contents

Overview of Service Oriented Architecture

Service Oriented Computing

Web Services Technology for SOA

SOA Lifecycle 44

11

22

33

SOA Design Patterns 55


Overview of Service Oriented Architecture

Part I

Incremental approach to an SOA

Monolithic Applications In software

engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

• From wikipedia.org

http://www.wikipedia.org/


Intermediate stage: Individual services broken out


Service-oriented architecture

An Example: Bank Teller Analogy Different types of tellers offer different services

Tellers specialized to perform only certain types of transactions (which are typically closely related)

Example partitioning:• Account Management (Opening and closing accounts)• Credits (inquiry about conditions, consulting, applying for

mortgages)• Cash Register (Withdrawals, deposits, funds transfers)• Currency exchange (buy and sell foreign currencies)

There may be several tellers offering the same set of services (for load balancing / failover)

What happens behind the counter is not your business (bulletproof glass, iron bars)

If you require a complex transaction, you may have to visit several tellers (customer as transaction coordinator)

It’s all about service! What do you mean?

A service is a package of closely related standardized functions, which are called repeatedly in a similar fashion, and should therefore be implemented by a dedicated facility, which can be specialized to perform them. Example: Account Management

A service can be partitioned and have multiple service functions. Example: Open new account

The smallest subunits within service functions are called service primitives (also sometimes called the service). Example: Generate next available account number

Characteristics To Describe A Service

Service requester (“client”) Who/which components use or need the service? For the service requester, the provided service is most

important, and not how it is implemented (principle of information and implementation hiding)

Service provider (“server”) Who/which components implement or provide the

service? is responsible for hosting the service, and ensuring the

promised QoS may charge for service usage

Qualities of Service (QoS) What are the parameters that allow to distinguish good

service provisioning from bad? Examples: Reliable, predictable execution, cost,

execution time, level of privacy, other guarantees

Service, a picture rather a million words!

Request Response

How Services relate

How services communicate

Logic encapsulation by service

Example

Interface (Def.) An interface constitutes the specification of a service,

that is implemented by a certain component. The interface defines a contract, to which the component that implements it has to comply.

Interfaces can be described using formal languages Web Services Description Language (WSDL) OMG/ISO Interface Definition Language (IDL) (for

CORBA) UML Object Constraint Language (OCL) But also: Java, C++ headers, . . .

Type-safe interfaces sometimes introduce tight coupling Web Services don’t force you into type-safe interfaces Different message types may be acceptable to a service

So you said WSDL! What is it?

A WSDL document describes a web service using these major elements

<portType>• The operations performed by the web

service <message>

• The messages used by the web service <types>

• The data types used by the web service <binding>

• The communication protocols used by the web service

The main structure of a WSDL Document

<definitions><types>

…</types><message>

…</message><portType>

…</portType><binding>

…</binding>

</definitions>

Hey WSDL! Give me synonyms in my world!

<portType> is the most important thing! Syn. To a function library, a class or a

module<message>

Syn. To parameters of a function<types>

Defines data types that web service uses!<binding>

Desc. The protocol details and message format for each port!

OK! I know it’s hard!A simplified part of WSDL code!

<message name="getTermRequest"><part name="term" type="xs:string"/>

</message><message name="getTermResponse">

<part name="value" type="xs:string"/> </message><portType name="glossaryTerms">

<operation name="getTerm"><input message="getTermRequest"/><output

message="getTermResponse"/></operation>

</portType> Source: W3Schools.org

Software Architecture (Def.)

Software architecture encompasses the set of significant decisions about the organization of a software system selection of the structural elements from which

the system is composed, and the interfaces to these

behavior as specified in collaborations among those elements

(de/-)composition of these structural and behavioral elements into a larger system

architectural style that guides this organization• Def. from Mary Shaw at Carnegie Mellon Univ.

Architectural Style (Def.)

An architectural style defines a family of systems in terms of a pattern of structural organization [Garland/Shaw 96]

An architectural style defines: a vocabulary of design elements

• components (client, server, filter, layer, adapter…), and connector types (pipe, broadcast, queue,...)

a set of configuration rules (constraints) on how they can be combined

Example styles in Software Architecture: Event-based, Repository-based, virtual machines, layered.

Service-Oriented Architecture (SOA)

The architectural style is service-oriented if: It is not monolithic; common blocks of functionality are

broken out of the applications and are instead provided by services

• A significant part of the overall functionality is implemented by services, which exist otherwise independent of the application

Design elements for an SOA are:• Components: services (can be composites), consumers,

providers• Connector type: (remote) service invocations

Configuration rules for an SOA are:• No strict layering (service implementations can use other

services) • No centralized control entity• Services are designed for shared use, and for use that may

not even have been anticipated at design time

Service Orientation (Def.)

Service-Orientation is an organizational principle. A set of principles for building large systems

which is not tied to any particular technology. Examples:

• Common “horizontal” services:– Logging, authentication/single-sign-on, systems

management, Directory lookup of services, event notification

• “Vertical” services, specific to your business domain– Product feature search service, Address management,

Order Status Tracking Service, Truck/trailer tracking service

As in organizations, there is always more than one way to structure a large system

Quality criteria for (software) architecture

Criteria to evaluate a decomposition:1. Derived from top rank use cases (adequateness)2. Balanced with existing assets: platform

technology, frameworks, components3. Balanced with requirements (trade-offs,

performance vs. security,…)4. Compliance with (domain-specific) industry

standards and reference models (interoperability, readiness for merging)

5. Designed to make the system more resilient to future changes (20 years?) (maintainability)

6. Designed for substantial reuse, and with substantial reuse

7. Intuitively understandable (people buy-in!) (usability)

Forces and quality factors for software arch.

A Real-world SOA Project! ( A Dream )Large-scale distributed systems, such as

healthcare systems, are difficult to develop due to their complex and decentralized nature. The Service Oriented Architecture facilitates the development of such systems by supporting modular design, application integration and interoperation, and collaboration between independent software systems. Using open standards, such as XML, SOAP, WSDL and UDDI, the Service Oriented Architecture supports interoperability between services operating on different platforms, and between applications implemented in different programming languages. We designed and implemented distributed e-healthcare system that uses the Service Oriented Architecture as a basis for designing, implementing, deploying, invoking and managing healthcare services. The e-healthcare system that we have developed provides support for physicians, nurses, pharmacists and other healthcare professionals, as well as for patients and medical devices used for monitoring patients. Multi-media input and output, with text, images, speech and keyboard, make the system more user friendly than existing healthcare systems.

www.uweb.ucsb.edu/~fkart/research.htm

http://www.uweb.ucsb.edu/~fkart/research.htm

Challenges and problems Technology heterogeneity of existing applications Many integration projects during the last three years

Have been tactical, not strategic (no enterprise focus) Only solved problems for one project (e.g. for one

channel) Result: Stovepipe integrations

Large organizations run 100s of apps and multiple ERPs These systems were designed independently of each

other They overlap in functionality

• They overlap in the data they manage Integration does not remove any overlap

• Consolidation would be better SOA helps to address these issues

Benefits of SOA Design More flexibility (“business agility”)

Assumption: business process logic and business rules are no longer buried inside applications

Result:• Since they are now explicit, processes can be changed

easier• Existing services can be used in different contexts• Shorter time-to market for changed processes

Reduced cost of operation through consolidation Assumption: Redundant functionality is eliminated Result:

• Fewer servers• Fewer licenses• Fewer assets to manage• Lower maintenance cost

Benefits of SOA Design (contd.)

Higher quality Eliminating redundancy reduces inconsistent data and

behavior More transparency Improved system architecture – easier to understand

Reduced risk, cost and complexity for development Clean architecture reduced cost and risk Increased developer productivity through reuse Projects can leverage existing services “Black box” reuse instead of copy&paste reuse

Lessen the dependencies on vendors Service implementations can be replaced if interfaces stay

the same Services can be relocated from one platform to another Services can even be outsourced to an external provider

Benefits of SOA Design (contd.)

Good service design (partitioning) will outlive your middleware or implementation technology All you have to do is to put a wrapper around it, if required Many mainframe systems today provide many useful

services that should be made available to applications elsewhere in the enterprise

Commoditizing more and more parts of the IT infrastructure Off-the-shelf infrastructure components are moving up the

layers and coming closer to the application! Due to existing industry standards and available products,

developers stop building this stuff themselves:• 1990: DBMS, TP Monitors• 1992: Networking stacks• 1995: CORBA, RPC Middleware, Reliable Messaging• 1998: Naming Service, Publish and Subscribe, Event Notification• 2000: Various J2EE Services

SummaryPrecise terminology helps

to understand and handle the problem to identify and debunk unbaked concepts

Service-orientation is an architectural styleSOA benefits us by

Reduced risk, cost and complexity for development

Reduced cost of operation through consolidation

business agility

Summary (Contd.)A Service is formally characterized by

Client Server QoS

It’s an incremental approach to reach SOA.


Part II

Service Oriented Computing

SOC DefinitionSOC is an emerging cross-disciplinary

paradigm for distributed computing that is changing the way software applications are designed, architected, delivered and consumed

SOC is a new computing paradigm that utilizes services as the basic constructs to support the development of rapid, low-cost and easy composition of distributed applications even in heterogeneous environments

SOC vs. Object OrientedThe major innovation of SOC is the move

from OO paradigm into a SO one! Object Oriented

• Stateful Service Oriented

• Stateless

A Deeper Comparison!Methodology

OO• Application development by identifying

tightly coupled classes. • Application architecture is hierarchical based

on the inheritance relationships. SO

• Application development by identifying loosely coupled services and composing them into executable applications.

A Deeper Comparison! (contd.)

Level of abstraction and cooperation OO

• Application development is often delegated to a single team responsible for the entire life cycle of the application.

• Developers must have knowledge of application domain and programming.


Level of abstraction and cooperation SO

• Development is delegated to three independent parties

– application builder– service provider – service broker.

• Application builders need to understand application logic and may not know how individual services are implemented.

• Service providers can program but do not have to understand the applications that use their services.


Code sharing and reuse OO

• Code reuse through inheritance of class members and through library functions.

– Library functions have to be imported at compilation time and are platform dependent.

SO• Code reuse at the service level. • Services have standard interfaces and are published

on Internet repository. – They are platform-independent and can be searched and

remotely accessed. • Service brokerage enables systematic sharing of

services.


Dynamic binding and re-composition OO

• Associating a name to a method at runtime. – The method must have been linked to the

executable code before the application is deployed. SO

• Binding a service request to a service at runtime.

• The services can be discovered after the application has been deployed.

– This feature allows an application to be recomposed at runtime.


System maintenance OO

• Users need to upgrade their software regularly.

– The application has to be stopped to perform the upgrading.

SO• The service code resides on service

providers' computers. • Services can be updated without users‘

involvement.

Who is using SOC?All major computer corporations, including

IBM, HP, Oracle, Intel, Cisco, Sun and Microsoft have moved toward SOC.

SOC is being adopted by major computer uses including Banks

• Web Banking Services Retailers

• Web Shopping Services Airlines

• Web Booking Services

SOC ElementsService Oriented ArchitectureService OrientationService Oriented Solution LogicServicesService CompositionsService Inventory

Service CompositionServices can be composed of other servicesServices can be composed by using other

services in a business logic

Service InventoryA service inventory is an independently

standardized and governed collection of complementary services within a boundary that represents an enterprise or a meaningful segment of an enterprise

Service orient . {ation + ed solution logic}

Service orientation: Is a design paradigm comprised of a

specific set of design principles Specifies the creation of automation logic

in the form of servicesService oriented solution logic:

The application of these design principles to the design of solution logic results in service oriented solution logic

SummaryService Oriented Computing is a new

approach for software development; just like Object Oriented.


Part III

Web Services Technology for SOA

Basic Web Tech required for WS

XML eXtensible Markup Language Documents are based on XML XML docs are described by XML Scheme

SOAP A simple way to send docs A way to format XML docs for transmission

WSDL Defines Implementation details about a service

UDDI Universal Description, Discovery and Integration Store, advertise and discover services!

What’s a Web Service?Web services are application components Web services communicate using open

protocols Web services are self-contained and self-

describing Web services can be discovered using UDDI Web services can be used by other

applications XML is the basis for Web services

How does it work?Basic WS platform is XML + HTTPOther Elements

SOAP UDDI WSDL

The future of WSWS platform is

Simple Interoperable Messaging

… framework but it lacks Security Routing

… but they’ll be provided as SOAP advances!

Why Interoperability is so important?

All different major platforms can access Web using Web browsers; different platforms can interact! An Idea! Developing Web Applications to

make these platforms work together.Web Applications are simple applications

run on the web. Built around web browser standards so

they can be used by any browser on any platform.

WS is an advanced Web Application

Using WS; the web application Publish its

• Function• Message

… to the rest of the world!WS uses

XML• To code/decode data

SOAP• To transport it through open protocols

Two types of uses for Web Services

Reusable Application Component Offering Application Components

• Like– Currency conversion– Weather report– Language translation– …

Connect Existing Software Make it possible to exchange data

between different applications and platforms.

What is SOAP?SOAP stands for Simple Object Access Protocol SOAP is a communication protocol SOAP is for communication between

applications SOAP is a format for sending messages SOAP is designed to communicate via Internet SOAP is platform independent SOAP is language independent SOAP is based on XML SOAP is simple and extensible SOAP allows you to get around firewalls

WSDL (Reminder)WSDL stands for Web Services Description

Language WSDL is written in XML WSDL is an XML document WSDL is used to describe Web services WSDL is also used to locate Web services

What’s UDDI?UDDI stands for Universal Description,

Discovery and Integration UDDI is a directory for storing information

about web services UDDI is a directory of web service

interfaces described by WSDL UDDI communicates via SOAP

SummaryWS is a way for converting applications into

Web Applications.WS uses XML to send messages between

applications.WS = exporting a function from an

application.WSDL is an XML based language for

describing services.SOAP is an XML based protocol for

exchanging data through HTTP.


Part IV

SOA Lifecycle

SOA LifecycleLogical steps to implement an SOA system.

1. Model2. Assemble3. Deploy4. Manage

Model PhaseModeling the current business processesOptimizing Business processes for agility

and more performanceModeling the result of optimization for

target business processesSimulating the models and evaluating

possible outcomes Helps in agility of the enterprise

Assemble PhaseIt’s splited into 3 sub-phases

Service Design Service Building Service Integration

In this phase, in fact, Services are implemented; then they are assembled Means discovered

… and composed to implement the bussiness processes that are tested for requirements. Functional or Non-functional

Deploy PhaseThe assembled business processes are

deployed on the operating run-time environment.

What’s a run-time?After Assemble phase; the BPs are ready to

be deployed into a run-time. It should support the execution of

Dynamic BPs It should provide open-standards based

execution environment to allow services to readily invoke other services.

Execution Environment3 basic must support features:

Protocol translation between various service invocations

Routing between appropriate service providers

Mediation to provide features like security, auditing, logging, and so on

Manage PhaseThe services and the business processes

that are executing on the run time are monitored and analyzed to ensure their smooth operations.

IT metrics like security, performance, and availability are also measured.

The services and business processes are further monitored to ensure compatibility with the business metrics and service-level agreements (SLA) that are supposed to be met.

Manage PhaseIt can be broken out into 4 sub-categories

Manage Business Processes Manage Service Layer Manage Transaction performance Manage Service Security


Part V

Design Patterns for SOA

SOA Scenarios IBM has found 8 common design patterns for SOA

It names them as SOA Scenarios They can be classified into 5 classes according to their

entry points People

• Enabling human and process interaction Process

• Enabling and achieving greater efficiency and effectiveness through business model innovation

Information• Delivering trusted information to enable business processes

Connectivity• Achieving an on-demand flexibility by connecting software

systems and services

SOA Scenarios (contd.) Reuse

• Minimizing complexity of SOA adoption and implementation by fostering reuse of high-value enterprise assets

Each scenario is further broken down into realizations They are specific development tasks

design to solve a particular problemScenarios can be categorized into 2 parts

Functional Supporting

SOA Scenarios (contd.)The functional scenarios map directly to

one or more SOA entry points.The supporting scenarios cut across all the

entry points.

Functional ScenariosService CreationService ConnectivityInteraction and Collaboration ServicesBusiness Process ManagementInformation as a Service

Supporting ScenariosSOA DesignSOA GovernanceSOA Security and Management

Service CreationCreating flexible, service-based business

applications. A new service-oriented application exposes

business behavior as a service and also reuses business logic, which is exposed as a service.

The scenario also provides guidelines on how to provision the services as soon as they are created.

The identification and realization of services are the first steps in implementing the vision of a set of optimized business processes

Service Creation (contd.)Services can be identified essentially from

three main sources Existing assets

• Services that are identified from high-value business functions already deployed in existing systems

– for example, legacy or packaged applications External service provider

• Services that are provided by an external vendor, most likely a vendor who provides services in a specific area

Service Creation (contd.) New services identified using a "top-

down" approach• Services that are identified through a top-

down decomposition technique– process decomposition

» These services fill the gaps that are not addressed by the first two sources; they are new services that need to be implemented from scratch

Service ConnectivityBuilds on the Service Creation scenario

According to which services have been identified, designed, and built, and focuses on the underlying connectivity used to support a business-centric SOA.

This scenario enables users to have the flexibility of independently changing the service consumer or the service consumer in a manner that is nondisruptive to either.

Service Connectivity (contd.) The scenario helps in identifying the characteristics

Such as routing, transformation, mediation of an Enterprise Service Bus (ESB) that may be used to provide decoupled connectivity between service providers and consumers.

The scenario also provides guidance on how to create a logical as well as physical realization of a service gateway pattern That provides mediation capabilities to enable

transparent interoperations across mismatched and evolving systems, both at the protocol and interface level.

The service gateway pattern also provides guidance on how to enforce security on service invocations.

Interaction and Collaboration Services

Presents a service or set of services to a human user through a browser, PC, mobile device, voice response system, etc.

It focuses on usability issues such as offering single sign-on to multiple systems

and providing role-based portals to consolidate access to information and applications within the enterprise and between enterprises.

The key drivers for this scenario are improving productivity of the people who use the system and consumability of the applications and content that make up the system. The content can be personalized in the aggregated

portal page based on the user role.

Business Process Management

Assists in the optimization and automation of business processes and aligns an organization's core assets people, process, information, and technology

… in order to create a single integrated view, real-time intelligence, and appropriate business and IT metrics that enable operational efficiency.

This scenario concentrates mainly on process modeling and simulation, process integration, process monitoring (also called business activity monitoring, or BAM), process-oriented content aggregation, business rules management, and effective collaboration between people, process, and technology.

Enterprises that are process-centric can gain from using this scenario in their SOA transformation.

Information as a Service Makes information usable in an SOA by expanding the

business value of data. This scenario is especially applicable when an

enterprise: Has too much information but is not sure of its

business relevance Stores multiple versions of information, making it

difficult to determine which information source to use Does not rigorously enforce data quality in its

store(s) of information Maintains disconnected silos of information that may

duplicate each other or contain different sets of data that cannot be reconciled

Information as a Service (contd.)

The crux of this scenario is the virtualization and centralization of information to create a set of consistent, reliable data. That virtual single version of data can

then be made available as a service to the entire SOA system, which can use it in a standardized way for business process enablement.

SOA DesignA cross-cutting scenario that focuses on

methodologies for modeling, design, and architecture of an SOA-based software development.

This scenario aligns the modeling of business design and IT solution design through a set of roles, methods, and artifacts. Once this is accomplished, business

processes can be optimized and realized as services so that the services are aligned with the business and offer true business value.

SOA GovernanceA cross-cutting scenario focusing on a

decision-making and enforcement process to oversee SOA planning and execution.

It is based on a decision rights and management framework that includes the establishment of chains of authority, roles, controls, and so forth, for the four phases of the SOA life cycle.

This scenario also focuses on defining high-value business services and measuring their effectiveness at run time.

SOA Security and Management

A cross-cutting scenario focusing on management of services at run time and ensuring secure external consumer access to high-value business services.

The management of services focuses on automating and simplifying IT processes, managing service levels of services and applications, and predicting and managing change across interdependent and composite services.

SOA Security and Management (contd.)

Service security focuses on managing the federated identity and access control across services, securing access to services and applications, and consistently enforcing security policies for services.

SOA scenarios and their relationships

IBM recommends a process for SOA Scenario usage

SummaryThe SOA scenarios represent a set of

generic business scenarios in which SOA is being used in typical customer engagements.

The SOA scenarios are representative of common scenarios of use of IBM products and solutions that are used in SOA engagements to solve real-world problems.


Reusability and its relation with SOA

Lecture # 2


presented by:

Hamid Bahrol Olum

Table of Contents

************

************

*****************

************** 33

00

11

22


SOA Tools

Lecture # 3


presented by:

Arab

Table of Contents

************

************

*****************

************** 33

00

11

22


SOA Case Studies

Lecture # 4


presented by:

Ghaini

Table of Contents

************

************

*****************

************** 33

00

11

22


Part VI

References

Refrence1. SOA: Principles of Service Design; Thomas Erl;

Prentice-Hall2. Introduction to Service oriented computing;

W.T.Tsai, Yinong Chen3. Service oriented computing: Key concepts and

principles; Michael N. Huhns, Munindar P.Singh

4. Introduction to Web Services (WS) & Service-Oriented Architecture (SOA); Eric Newcomer; Presented at SOA, MDA, and Web Services Workshop: Integrating the Enterprise, and Beyond, 2006 by OMG

Reference (contd.)

5. Architecture in practice; 7 parts; by Tilak Mitra; at IBM developerWorks.

6. W3School at www.w3school.org

http://www.w3school.org/


Thanks & Ready for

Questions and NO ANSWERS!

Service-oriented Architecture with Respect to Reusability

Technology

Transcript of Service-oriented Architecture with Respect to Reusability