Agenda

What is SOA? Concept of service and web services SOA from different perspectives

SOA technologies and products

SOA pitfalls

This presentation has 40 slides.

Modern corporations are faced with a profound dilemma. Increasingly, they are becoming informationbased organizations, dependent on a continuous flow of data for virtually every aspect of their operations. Yet their ability to handle that data is breaking down because the volume of information is expanding faster than the capacity to process it. The result: Corporations are drowning in their own data. The problem doesnt lie in hardwarecomputers continue to increase in speed and power at a phenomenal rate. The failure lies in software. Developing software to tap the potential of computers turns out to be a far greater challenge than building faster machines.
David A. Taylor, Ph.D., in Object Technology: A Managers Guide

SOA Defined
Service-Oriented Architecture is an IT strategy that

organizes the discrete functions contained in enterprise applications into interoperable, standardsbased services that can be combined and reused quickly to meet business needs.

There are some keywords in this definition that need to

be inspected further, so lets do that.

IT Strategy
SOA is a strategy or paradigm to manage business

computing needs in an enterprise.

SOA is an approach to how to handle your IT to promote

successful business. SOA is an enterprise-level architecture for most of business applications.

Main aim and promise of SOA is to reduce the time and

cost of creating new applications through reuse. SOA builds its sphere around the concepts of business processes and services.

IT and Business Alignment

IT-Business tension has always been a problem in

enterprises. This tension should be overcome in order to have successful IT applications that create competitive edge for the enterprise.
IT Strategy

Business Strategy

SOA

Discrete Functions
Every enterprise has a number of its own business

functions. Most of those functions are discrete in that they handle different parts of the business mostly without touching another. Or if they are communicating, it mostly happens pointto-point basis or they share some data, etc. In fact those discrete functions should become part of applications that implement company-wide processes to create for example more integrated and less overlapping customer experience.

Enterprise Application
Functions are implemented by software applications.

By implementing functions, applications manage

business processes that consequently provide some functions to internal departments of the company or its partners and customers. Those discrete applications live in local contexts such as the individual departments or among a few of them.
Production, marketing, customer service, finance and

some others such as claims in insurance business or more technological ones in telecom business

Business Processes and Contexts

But SOA implements business processes at wider

contexts: Company-wide and/or a space from suppliers to customers. Thats because processes in an enterprise get more complex and they touch customers at more points and in more interactive and information-intensive ways.
And think that all these interaction points behave

distinctly and treat the customer without knowing anything about other interaction points! That creates frustrating experience for the customers.

Interoperable
The IEEE Glossary defines interoperability as the ability

of two or more systems or components to exchange information and to use the information that has been exchanged. Interoperability has always been hard and traditionally achieved with one of many Enterprise Application Integration (EAI) approaches
Two sides of the wire have mostly incompatible OSs, PLs,

protocols, file formats, etc.

EAI has been achieved by P2P, bus-based architectures.

Point-to-Point Integration
EAI
Custom API

Packaged CRM
CRM Application

Custom API

Client Tier

Custom Logic

Custom Packaged ERP API

Custom API

Client Application

ERP Application Custom Logic

Custom Mainframe API Custom API

Client Application

Custom Application

Custom Logic

Custom App Server API

Custom API

Client Application

EJB Application

Bus-based Integration

Standards-based
What takes for two persons with different languages to

understand each other?

Words and grammar.

What takes for two incompatible software systems to

work together?
Data types and protocol or language syntax

Unless two incompatible software system agree upon

data types and syntax they use, they cant work together.

Standards: XML
XML provides a standard, platform/OS/programming

language-independent way to express data types:

An XML document or message can be understood by

different languages as long as its semantic is known. The semantic of XML can be expressed in documents such as schemas.

Any enterprise can express its domain in XML. That means an enterprise can create its ontology And that ontology can be understood and consumed by

other enterprises.

Standards: SOAP
SOAP (Simple Object Access Protocol) provides

platform/OS/programming language-independent way to carry XML documents between disparate platforms.

When an XML massage is served through SOAP, which

is on the top of the ubiquitous HTTP, that makes a web service.

SOAP is not the only alternative to implement web

services. REST is getting more attention!

So web services became de-facto standard of

interoperability or EAI.

Service
Services are the most basic building block of SOA. What makes a service? Any application from a Fahrenheit2Celcius converter to an ERP can be a service or set of services. A service in SOA is a logical and self-contained business

function.

Services and SE
In terms of Software Engineering, services are the last

step in abstraction.

SOA Service Attributes

SOA services have following attributes: Stateless Discoverable Self-describing Unassociated Composable Loosely coupled Location and language transparent And mostly have following attributes: Coarse-grained Asynchronous

Service As New Or Existing One

Types of Service Access and Implementation Created from existing functionality Invoked through protocols and methods Created as new functionality

Service access

Service access

Can be achieved either by exposing existing functionality as Web services or by using adapters

Services can be invoked by using SOAP over HTTP, JMS adapters, or WSIF.

Can be developed by using service bus components, BPEL processes, or Web services implemented with Java or Java EE

SOA and Reusability I

Reusability is the nirvana of the computing!

Change in business is so fast that developing new

application from scratch all the time is not a solution! So marginal cost of each new application or feature should be as minimal as possible through reuse. SOA allows creating new applications built upon the existing ones exposed as services. In SOA reusable assets are the services that are created, configured, assembled in different applications many times over and over again and consumed.

SOA and Reusability II

Reuse does not come automatically with SOA! Reuse can only be achieved by a collaborative effort of

business and IT
So reuse is a mostly an organizational issue.

It takes planning, finding, classifying, prioritizing,

developing, packaging, etc. services.

Business Process Management

SOA is about orchestrating the services to implements

business processes. A business process consists of services that function as actions, rules, decisions, etc. and provides a value when finished. Managing a business service is called Business Process Management (BPM). And there are standards to create and manage business processes.

BPEL
Business Process Execution Language (BPEL), short

for Web Services Business Process Execution Language (WS-BPEL) is an OASIS standard executable language for specifying actions within business processes with web services Processes in BPEL export and import information by using web service interfaces exclusively. BPEL includes variable initialization, decision and repetition, XML data access, human interactions, rule evaluations, etc.

Credit service

<variable>

BPEL 10 a.m. Start process

<invoke>

<process>

Handle negative credit exception

<faultHandlers>

Get rating

<partnerLink>

Send order

<flow>

Send order

SM service

<invoke> <receive>
Receive quote

RD service

<partnerLink>

</flow>

Receive quote

<partnerLink>

<switch>
</process> End

Select lowest 3 p.m. quote

Standards Behind SOA

Service Component Architecture (SCA) Orchestration: BPEL
Service Data Objects (SDO)

Assembly model Business processes

Data access

Management WS-Policy WS-Security

WS-ReliableMessaging

WS-Security

Quality of service Discovery Description Message Transport

UDDI WSDL SOAP XML HTTP(S), IIOP, JMS, SMTP

What SOA is
SOA can be thought of as: An enterprise-level design approach A collection of services that interact with one another A set of services that are loosely coupled, with welldefined, reusable, platform-independent interfaces A higher level of application development Services provide access to data, business processes, and

IT infrastructure, ideally in an asynchronous manner. Before SOA we first develop then integrate, after SOA we first integrate then develop.

What SOA is not

SOA is not a technology but an approach to use

technology for more efficient IT and business architecture

SOA is not hardware nor software SOA is not web services, SOA is not business process management

SAO is not an IT job

SOA to CIO
To CIO, SOA is a way to reduce the total cost of

ownership of the whole business application suit in the enterprise. With SOA, CIO expects that the marginal cost and effort of each new application would be much lower because they will be created only by re-orchestrating the existing services. Services dont have to be developed locally, they can be provided as a service by third parties as SAAS.
Services from outside of the company would definitely

lower the costs and leading time.

SOA to Business Executive

To the business executive, SOA is a set of services that

can be exposed to their customers, partners, and other parts of the organization.
Applications serve the business because they are

composed of services that can be quickly modified or redeployed in new business contexts, allowing the business to quickly respond to changing customer needs, business opportunities, and market conditions.

SOA to IT Architect
To an IT Architect, SOA means the overall enterprise

architecture definition and the process that enables IT to develop and deploy business capability rapidly.
For architect, SOA is the architectural solution for

integrating diverse systems by providing an architectural style that promotes loose coupling and reuse.

SOA to Business Analyst

To business analyst, SOA is a mechanism to unlock

small and distinct business processes out of local applications to constitute more strategic business processes in a larger context.
Business analyst understands the strategy of the whole

business and extracts new requirements or changes in existing ones for the new services and new processes.

SOA to Developer
To the developer, SOA is a programming model or

paradigm where web services and contracts becomes a dominant design for interoperability. It is a web service when it uses a Web Service Description Language (WSDL) or equivalent specification for describing the service. So the developer keeps either developing new services using new requirements or extracting services from the existing applications.

SOA for Everything?

SOA is not for Everything

SOA may not be suitable for Homogeneous business and IT environments, Time-critical applications, Too transactional, mostly CRUD operations, Algorithmic applications that change very infrequently, When tight coupling is not an issue or something wanted, When sharing is not an issue.

Magic Quadrant of SOA

SOA Pitfalls (for Trkiye)

SOA is the most-awaited silver bullet.

Business-IT non-alignment.
Lack of process culture, more focus on technology. Lack of proper understanding regarding SOA, again

more focus on technology. Inability to restructure the companys business and IT resources around service and SOA needs. Starting with the most complicated process without establishing a reference architecture.

Teekkrler ve
Sorular.