soa.ppt

Web-services June 13, 2006 1

Service Oriented Architecture

What is Software Architecture?

The overall structure of the software and the ways in which that structure provides conceptual integrity for the system

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.

How does this differ from an OO architecture?

Note SoA is a framework for designing software systems using a software

architecture hat views all components as services



In OO, we integrate data and methods into a single object

There is a strong coupling among objects

Communications are prescriptive -- not descriptive

Object discovery is not well understood although CORBA attempted this

SoA separates (most of the time) data from a service or behavior

The coupling among services is very loose (at least, desired)

Communications are descriptive (ideally)

Service discovery is inherent in SoA



Consider an analogy (somewhat controversial)

CDs and CD players

CD’s contain data/music, etc

CD players provide service to read or play CD’s

If using OO, we may have to embedded CD player service into each CD

data + methods encapsulated

If using SoA -- we can separate data from the actual service

Possibly even allow the service to interpret the data differently

Another analogy -- you want “food preparation” service at a restaurant.

You want to order food, but not provide a recipe on how to cook

Does polymorphism of OO help in this analogy?



We are talking about the design methodology associated, not an OO

programming language

In fact we can do OO based architecture using non OO languages

Consider other programming/design frameworks

Aspect Oriented

Agent Oriented

Autonomic oriented

Likewise we can build SoA using OO language



What is a service?

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

Consider the difference between providing data/information vs a

service.

We can provide a database or we can provide a service for using the

data.

In general services can extend beyond software



How do we encapsulate process/business logic in a SoA?

Note we translate both business logic and application logic into services



We first translate business processes into business logic and define services associated with the logic

Likewise, we separate the application logic from implementation and define services



Can’t we do this with OO?

Again the difference is in philosophy

separate behavior from dataloose coupling descriptive communication



A service can be both a provider and a consumer

For example in the restaurant case,

the restaurant is a service provider to dining clients

but a consumer of services from grocers

Is this still any different from OO?

Can’t we build SoA systems using Java and C++?

The key difference is to make the coupling as loose as possible



Make the interactions among components as simple as possible

In most software systems, this is often difficult

real dependencies among behaviors

artifact dependencies

Two SoA features leading to loose coupling1. A small set of simple interfaces to all services. Only generic semantics are encoded at the interfaces.Interfaces are universally available to all providers and consumers

2. Descriptive messages constrained by XML (or other) schemasNo or minimal system behavior is included in messages.Schema limits the vocabulary and structure of messages

Other descriptive message communication modelsKQML based on “speech directives”May be interesting to see if we can design XML based KQML



Interfaces and messages

Is there a difference?

Descriptive messages -- not instructive

Structure is limited by extensible schemas (to permit understanding of request for services)

Extensibility is important to permit evolution of services (but still compatible -- CDs, DVDs, HDVDs,)

Of course service discovery is needed for SoA

May need new services that can be used to locate needed services Semantics, ontologies, etc.

Interfaces should be generic and application specific semantics described in messages



Stateful vs Stateless services

Stateless -- a service does not maintain any state informationconsumer must provide all the needed informationpermits for easy implementations and mass production of services

(generic services)

Any disadvantages?

Cannot provide “sessions” between providers and consumerse.g., cannot provide security certificate once per session

Stateful services Needs to share consumer specific contextMay be part of interfaceOr exchanged as a sequence of messages

Not scalable



Instead of stateful services, we can consider “manager” services which provide an interface to a stateful service

We can define a manager service that establishes the context.After that we can have a manager that does not require state information

All manager services arestateless and can processmultiple customer requests



Idempotency of requests -- what is this why do we need this?

All these are ideal characteristics of SoACan we achieve them (at least for developing software systems)?

So what does standard interface mean?Power is standard (unless you want to use the toaster in Europe)How about the width of the slots? Can we think of standard interface?

Select a button or a number to specify the choice of widthand the toaster adjusts the slot approriately

Loose coupling with exensible services but fixed interfacesConsider an analogyWe want to provide more services from your toasterDo we need to change the interface?

Power outlet width of slots to accept a bagel instead of slice of bread or Pizza



In software we can state that the service requirements can be “described” with XML schema

What happens if the service changesMay be provide optional XML tags Extensible tags to facilitate interface to new services

But do the extended tags change the interface?

Of course, as in case of the toaster example, we can get rid of old service anddiscover (and buy) the new improved service

For software services interfaces are the specification of the number of messages or arguments

The actual messages describe the type of inputs



Web services is one realization of the SoA

Standard messages are specified by SOAP

Messages (at least ideally) are descriptive using XML tags

Service discovery facilitated by UDDI

So where do we fit quality of service characteristic of a service

That is not essential in SoA -- but needed for service discovery

Web services (at least ideally) satisfy the loose coupling facilitated using standards provided

Standard interfaces are specified using WSDL



Net Centric Operations and Service oriented Architecture

Net centric operations require all “information” available on network tasks, posting, processing and using of information

Can we translate operations into services?

We can define services to “pull” information, post (new) information to We can define services to “pull” information, post (new) information to requesters, process information (analyze)requesters, process information (analyze)

All these operations must be made available via (the) networkoperations must be interoperablemust be able to discover operations


Net Centric Operations

Recent trends in Network-Centric Warfare (NCW) have significant effect:Service-Oriented Architecture (SOA)

Network Centric Enterprise Services (NCES), GIG Enterprise Services (GES), JBMC2, FCS, JBI, and Composable FORCEnetDynamic publication, runtime selection and discovery, dynamic compositionDistributed services and agents

These systems must be dynamic and keep on changing even at runtime.These architectures are not static but dynamic and evolving

in other words, modern DoD systems need to respond to change at runtime and in real time.

Key questionAre the existing approaches to architecture powerful enough to handle these dynamic structure and mechanisms, which are key to building systems for Network-Centric Warfare?


Network Centric Enterprise Services(NCES)

CoreEnterpriseServices

(CES)

Comms

Backbone

Community-of-Interest

(COI) CapabilitiesUsers

MessagingESM

Discovery Collaboration

Mediation Security/IA

AppStorage

UserAsst

Levels of Services above

core level

Support real-time & near-real-time warrior needs and business usersSupport real-time & near-real-time warrior needs and business users

C2

Intel

Weapon Systems

Dynamically Created COIs

Logistics

Sensors

Personnel

Finance

Etc.


GIG Enterprise ServicesSOADR Supports real-time & near-real-time warrior needsSOADR Supports real-time & near-real-time warrior needs

DoD (Title 10) IC (Title 50)

UsersUsers

Business Domains Warfighter Domains

Domain/ COI

Capabilities

ICOrg Spaces

National Intelligence Domain

Transformational Communications (TC) & Computing Infrastructure

ICSIS Community Space

Technical Infrastructure Domain

Levels of Services Above

Core Level

COI’s

Capability Integrator

Inst

alla

tion

s &

Env

iron

men

t

Hum

an

Res

ourc

es

Man

agem

ent

Acq

uisi

tion

Stra

tegi

c P

lann

ing

& B

udge

t

Log

isti

cs

Acc

ount

ing

& F

inan

ceGovernance

COI’s

Capability Integrator

Com

man

d &

C

ontr

ol

Bat

tles

pace

A

war

enes

s

For

ce A

pplic

atio

n

Pre

cisi

on L

ogis

tics

Pro

tect

ion

Governance

Net-Centric Enterprise Services (NCES)

ApplicationUser

AssistantStorage Messaging IA/Security

IA/SecurityESM

IA/SecurityESM

IA/SecurityESM

Discovery

IA/SecurityESM

Collaboration

IA/SecurityESM Enterprise

Service Management

(ESM)

Mediation

IA/SecurityESM

IA/SecurityESM

ESM

IA/Security


SOA-based System Architecture

The system has three architectures:

The Application Architecture. This application architecture will be built on top of an SOA.

The Service Architecture. This is the commonly known SOA architecture.

The Component Architecture. This is sub-SOA architecture that describes the various elements that support the implementation of services.

Note -- although we used application architecture here, we apply this to both

application and business logic


Service Orientation of Enterprise Systems

Business Logic: documented implementation of the business requirement

typically structured into processes expressing the requirements,constraints, dependencies and external factors

Consider UNT EIS system

UNT business logic and processes

What EIS application logic allows us to do

Application Logic: implementation of business logic organized into various technology solutions

business processes through purchased or designed systems within the confines of the IT infrastructure, security constrains, technical capabilities and vendor dependencies


One view of Enterprise Service Orientation



One view of Enterprise Service Orientation



Components of Logic in Service Orientation

•Message (units of communication)

•Operations (units of work)

•Services (units of processing logic -- collection of units of work)

•Processes (units of logic -- coordinated aggregation of services)


How unit communicate


Components of Logic in Service Orientation



Modeling Service Layers for Business and Application logic




Application Service Layer:

Typically consists of Utility Services

policy implementation, QoS, Security

Wrapper Services

to encapsulate legacy functionalities

Business service layer

Task centric service -- encapsulates specific task

verify invoice

Get account info

Entity centric -- encapsulates a specific business entity

invoicing service




Task-centric and Entity-Centric services



Orchestration service layer

Applies the idea of process workflows to compose

application and business services

Abstracts business rules and service execution sequence logic from other services




Web services is one realization of the SoA


Software Engineering for SoA

What are the implications of SoA on SE processesrequirements and specificationsdesignimplementation and deploymenttesting and verificationmaintenance

SoA characteristics imply that we want use “macro” or coarse grained operations/activities as services

Don’t want to think of a class to support “queues” or “stacks” as a service

You may want to consider services to “search” or discover



SE Processes -- top down vs bottom up

Top down approachAnalysis first

assume business requirements are known

Ontology permits us to classify and develop vocabulary for our services

We may need to re-align business models to fit the ontologies



Bottom up approachCreate services based on application needs

May not fully take advantage of available services



In between approach

Do some top down to get Ontologies and vocabularies defined

Then perform analysis to identify or design services



Service modeling processHow do we identify what services are needed?How do we aggregate units of work into service?



An example



Some of the processes (or operations) are not suitable for service orientationmanual processeslegacy logic that cannot be converted

Abstract orchestration logicIf novice is valid flowif invoice not valid flow

Creating candidates for servicesdecide on task oriented or entity oriented servicesdecide on wrapper services and utility services

Refine reusabilityautonomydiscoverabilitystatelessness



Identify candidates for service compositionscommon scenarios -- like OO patterns improved performanceidentify missing workflow logic

Revise business service operationsprevious step (service compositions) may necessitate revisit to grouping of business operations/services

Analyze application processing requirementCan we achieve the service compositions with available application logic?

Create application service candidatesdealing with legacy systems



Do we have adequate methodologies, formalisms and tools for SoA

Can we use UML or extended UML for SoA?

How do we model, design, test/verify QoS properties?

We have an interest in developing some innovative ideas and tools

soa.ppt

Documents

serviceoriented architecture

service discovery

service provider

actual service

oo architecture

consumer of services

cd player service

services extensibility