Malek

Sam Malek

SOA Research IssuesJan., 22, 2009

Outline• Service-Oriented Architecture– Software Architecture– Architectural Style– Service

• Realizing SOA–Web Services

• Research Challenges

3

What is Service-Oriented Architecture?

• Service-Oriented Architecture (SOA) is an architectural style. Applications built using an SOA style deliver functionality as services that can be used or reused when building applications.

Software Architecture Definition

• Definition. A software system’s architecture is the set of principal design decisions about the system.

• Software architecture is the blueprint for a software system’s construction and evolution.

4

Why Software Architecture?

5

Why Software Architecture?

6

What should be in software architecture?

• “Principal design decisions”

• “Principle” implies a degree of importance that grants a design decision “architectural status”

• It also implies that not all design decisions are architectural, that is, they do not necessarily impact a system’s key characteristics

• How one defines “principal” will depend on what the stakeholders define as the system goals

7

Software Architecture’s Elements

• A software system’s architecture typically is not (and should not be) a uniform monolith

• A software system’s architecture should be a composition and interplay of different elements– Processing – Data, also referred as information or state– Interaction

8

Component• Elements that encapsulate processing and data in a

system’s architecture are referred to as software components.

• Definition. A software component is an architectural building block that encapsulates a subset of the system’s functionality and/or data, and restricts access to them via an explicitly defined interface.

9

Connector • In complex systems interaction might become more

important and challenging than the functionality of the individual components.

• Definition. A software connector is an architectural building block tasked with regulating interactions among components.

• In traditional, desktop software systems, connectors would have usually manifested themselves as simple procedure calls or shared data accesses.

10

Example of a Software Architecture

Architectural Style• An architectural style is a named set of constraints

(e.g., rules) you put on your development– Constraints may be topological, behavioral, communication-

oriented, you name it

12

VS.

Race Car vs. SUV

13

Race Car vs. SUV

14

Basic Properties of Styles

• A vocabulary of design elements– In civil engineering we have: mortar, brick, column, concrete, …– We want to have the same in software: pipes, filters, objects, servers,

clients, publication, notification, advertisement, …

• A set of configuration rules– Topological constraints that determine allowed compositions of

elements

• A semantic interpretation– Compositions of design elements have well-defined meanings– Brick structure vs. concrete structure vs. wood structure vs. …– Client-server vs. peer-to-peer vs. publish-subscribe vs. C2 vs. …

15

Client-Server vs. C2

16

What is a Service (Merriam-Webster Dic.)

• A facility supplying some public demand • the work performed by one that serves HELP, USE, BENEFIT

http://www.m-w.com/dictionary/serves

http://www.m-w.com/dictionary/help

http://www.m-w.com/dictionary/use

http://www.m-w.com/dictionary/benefit

18

What is a Service?

• A service is a reusable component that can be used as a building block to form larger, more complex applications• A service may be as simple as “get me

some person’s name” or as complex as “process a purchase”

19

services become first classsuppliers register their capabilities,

consumers look for services not specific components

• suppliers are developed with no knowledge about which and how many components will consume their services

c2c1

invokesrequestsconsumes

providessupplies

service

clientuser agentconsumer

server“service”compone

ntprovidersupplier

20

server 1:supplier factory

two models for activating service supply: factory & pool

c2c1

create instance

servicerequest

mid

dle

ware

glu

e c

od

e

server 2:supplier pool

c3

mid

dle

ware

glu

e c

od

e

c3

c3

21

stateful suppliers keep state of conversation,stateless don’t

server 1:supplier factory

c2c1

create instance

servicerequest

accessstate

mid

dle

ware

glu

e c

od

e

server 2:supplier pool

c3

c3

c3

r1

r2 r1, r2

c1:r1, r2

c1’: r1’c1”: r1”, r2”,

r3”

mid

dle

ware

glu

e c

od

er1

r2

example: EJB entity beans and session beans

SOA Style




24

CORBA defines interfaces, not implementations,to shield apps from heterogeneity of language, OS, hardware…

an implementation of CORBA manages:•object location •connection & memory management•parameter marshaling•event & request delivery•error handling & fault tolerance•object/server activation•concurrency & synchronization•securitycredits: Douglas C. Schmidt

25

J2EE defines specific infrastructure (containers) and communication mechanisms (JMS, RMI)

26

Middleware solutions for SOAhave significant challenges

• too many “standards”one born every few months: code evolution nightmare

• integration with legacy systemsmillions of LOC and billions of $ already invested– strategy: wrappers around old code

• with wrappers latency becomes an issue

27

middleware may alleviate dependencyon programming language and OS but

… introduces dependency on middleware

• suppose that your company decided to use J2EE & JMS to integrate applications

• now your company is about to merge with another that used (RPC-based) CORBA to integrate their apps

• and business is pressing towards buying a 3rd party product that uses DCOM

how do you integrate all of that?

28

web servicescome in as an integration technology

• focus on bridging existing technologiesmiddleware for middleware– it’s about how to access an application,

it is not an implementation technology

• looser coupling than RPC-based middleware– avoid proprietary APIs– Simple Object Access Protocol (SOAP)

based on sending XML messages over http,no SOAP API or ORB

• wider industrial support than previous middleware– Microsoft’s .net, IBM’s Webshpere, Sun’s J2EE

29

service description

messages

directory

web servicesintroduces its own set of standards

data

data types

…and:

UDDIuniversal description, discovery and integration

WSDLweb services description language

SOAPsimple object access protocol

XML Schema

XMLeXtensible markup language

which work on top of:

30

multiple proposals forservice composition and coordination

• Business Process Execution Language BPEL• Web Services Conversation Language WSCL• Web Services Coordination WS-C• Web Services Transaction WS-Tx

credits:Frank Leymann,Kai Guentzel

SOAP

RPC

31

the W3C is actively working on the definition of the Web Service Description Language (v 2.0)

<description namespace = “http/… “><types> xschema types </types><interface> ways to access the service </interface><binding> communication protocols </binding><service> a list of interfaces and bindings </service>

</description >

structure of a service description:

let’s take a quick look at each of these

32

namespacesdisambiguate identifiers

<description namespace = “http/… “><types> … </types><interface> … </interface><binding> … </binding><service> … </service>

</description >

<description xmlns="http://www.w3.org//01/wsdl" targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc" xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc" xmlns:wsoap= "http://www.w3.org//01/wsdl/soap" xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsdlx= "http://www.w3.org//01/wsdl-extensions">…

33

types are definedusing XML schema or DTDs


</description >

<types> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://greath.example.com/2004/schemas/resSvc" xmlns="http://greath.example.com/2004/schemas/resSvc">

<xs:element name="checkAvailability" type="tCheckAvailability"/> <xs:complexType name="tCheckAvailability"> <xs:sequence> <xs:element name="checkInDate" type="xs:date"/> <xs:element name="checkOutDate" type="xs:date"/> <xs:element name="roomType" type="xs:string"/> </xs:sequence> </xs:complexType> …

34

interfaces support operations with in and out parameters

<interface name = "reservationInterface" > <fault name = "invalidDataFault" element = "ghns:invalidDataError"/> <operation name="opCheckAvailability" pattern="http://www.w3.org//01/wsdl/in-out" style="http://www.w3.org//01/wsdl/style/iri" wsdlx:safe = "true"> <input messageLabel="In" element="ghns:checkAvailability" /> <output messageLabel="Out" element="ghns:checkAvailabilityResponse" /> <outfault ref="tns:invalidDataFault" messageLabel="Out"/> </operation>


</description >

35

differentcommunication patterns

are supported

• in-only: receives a message but will not respond• robust in-only: receives a message and may issue a fault message• in-out: receives a message and may issue a reply or fault message

• …eight patterns defined, but open to moresome are just the symmetric, e.g., out-in


</description >

<operation name="opCheckAvailability" pattern="http://www.w3.org//01/wsdl/in-out" style="http://www.w3.org//01/wsdl/style/iri" wsdlx:safe = "true">…

36

binding defines the communication protocol

typically SOAP

<binding name="reservationSOAPBinding" interface="tns:reservationInterface" type="http://www.w3.org//01/wsdl/soap" wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP"> <fault ref="tns:invalidDataFault" wsoap:code="soap:Sender"/>

<operation ref="tns:opCheckAvailability" wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>

</binding>


</description >

37

service associates theinterfaces with a URL

and protocol (binding)

<service name="reservationService" interface="tns:reservationInterface">

<endpoint name="reservationEndpoint" binding="tns:reservationSOAPBinding" address ="http://greath.example.com/2004/reservation"/> </service>


</description >

38

WS descriptionsmay be posted on UBRs

UDDI Business Registry

3. UBR assigns a programmatically unique identifier to each service and business registration

Marketplaces, search engines, and business apps query the registry to discover services at other companies

4.

Service TypeRegistrations

SW companies, standards bodies, and programmers populate the registry withdescriptions of different types of services

1.

BusinessRegistrationsBusinesses

populate the registry withdescriptions of the services they support

2.

Business uses this data to facilitate easier integration with each other over the Web

5.

credit

s: T

evfik B

ult

an

39

businessEntitybusinessKeynameURLdescriptioncontactsbusinessServicesidentifierBagcategoryBag

PhoneAddressEmail

Contact

businessServiceKeyNameDescriptionBindingTemplates

PhoneAddressEmail

Contact

businessServiceserviceKeytModelKeyNameDescriptionBindingTemplates

keyedReferencetModelKeykeyNamekeyValue




a UDDI Business Registrysupports business registrations

• XML document• created by supplier

company (or on its behalf)

• may have multiple service listings

credit

s: T

evfik B

ult

an

40

service type registrations in UDDIdefine a signature (tModelKey) and

are meant to be interpreted by programmers

businessEntityTB993… Harbour Metalswww.harbourmetals.co.au“Serving Inner Sydney Harbour for …contactsbusinessServicesidentifierBagcategoryBag

872-68914281 King’s Blvd, Sydney, [email protected]

Peter Smythe

businessServiceKeyNameDescriptionBindingTemplates

businessService23T701e54683nf…Online catalog“Website where you can …BindingTemplates

BindingTemplate5E2D412E5-44EE-…http://www.sydneynet/harbour…tModelInstanceDetails

tModelInstanceInfo

4453D6FC-223C-3ED0…

http://www.rosetta.net/catalogPIP

keyedReferenceDFE-2B…DUNS45231

keyedReferenceEE123…NAICS02417

tModelKeys…service descriptions may or may not be WSDL




SOC Research Road Map

Research Challenges

• Foundation– Dynamically reconfigurable runtime architectures– End-to-end security solutions– Semantically enhanced service discovery

• Composition– Dynamic and

adaptive processes– QoS-aware service

composition

Research Challenges• Management and Monitoring– Self-configuring, self-adapting, self-healing, self-

optimizing, self-protecting management services

• Design and Development– Engineering of

service apps– Service versioning

and adaptivity– Service governance

Topics Covered in This Course• Software Architecture• Autonomic Computing• Coordination• Modeling• Service Discovery and Selection• Quality of Service and Analysis• Monitoring• Service Composition

Documents

Malek