Service Oriented Architecture – Principles and Technologies

Dr. Josef Withalm

Mgr. Pavol Mederly

Course Content• „Theoretical part“ (jw) – 7 lectures

– Evolution of architectures „from OO to SO“– Web Services and Semantic Web– SOA: Technological basis– SOA: Basing on Java EE– SOA: Focus on business processes– B2B Frameworks and related standards– Web 2.0 and Grid computing

• „Practical part“ (pm) – 6 lectures– Application integration based on SOA principles– Enterprise Service Bus as an implementation technology

Practical part• „integration studio“

– Progress Sonic ESB– Jetty webserver-based sample service– JMS-based sample services– JAX-WS web sample services– SoapUI Test Client– some other ESB ?– ...

• experiences with– practical service integration / adaptation tasks– WSDL, SOAP, XSLT, XPath, JMS, ...

Pondelok 11:30 – 13:05

akvárium VI alebo M-217(bude vždy oznámené vopred + na webe)

http://www.fmph.uniba.sk/~pmederlypavol.mederly@fmph.uniba.sk, M-171

ukončenie: projekt (ESB) + skúška

Today

1. Service Oriented Architecture

2. Enterprise Service Bus

3. Macro-Microflow Pattern

4. Sample scenario

A definition (one of)

Service-oriented architecture (SOA) is a distributed systems architecture that is typically characterized by the following properties:– systems developed under SOA paradigm consist of services– the service provides an abstracted (logical) view of actual HW/SW

components (programs, databases, business processes, ...)– the service is formally defined in terms of the messages exchanged

between provider agents and requester agents– the service description is published in machine-processable form– services tend to use a small number of operations with relatively large and

complex messages– services tend to be oriented toward use over a network– messages are sent in a platform-neutral, standardized format (typically

XML, but not necessarily)

W3C Web Services Architecture, 2004

What is it good for ... ?

• application integration– intra-enterprise– inter-enterprise (business-to-business)

• application development

Enterprise Application Integration

• there are plenty of apps in a typical enterprise

• there is a strong need for them to cooperate– e.g. in order to automate business processes

supported by more than one application

• main obstacle: apps developed independently, having different assumptions, data models, interfaces, platforms, etc.

An example – purchase order processing

Input: purchase order

• Validate customer ID and status• Check customer credit• Check inventory and package goods• Start the delivery• Prepare and send an invoice

Output: delivery started, invoice sent.

Systems involved

1. Validate customer ID and statusCustomer Relation Management (CRM)

2. Check customer creditEnterprise Resource Planning (ERP)

3. Check inventory and package goodsInventory Management

4. Start the deliveryDelivery System (outsourced)

5. Prepare and send an invoiceEnterprise Resource Planning (ERP)

CRM

Data

ERP

Data

Inv. Mgmt

Data

Delivery

Data

SOA says to ...

• publish relevant application functionality as services

• create composite (integrating) application(s) that call them

(Some) services involved

1. Validate customer ID and statusCustomer Relation Management (CRM)

GetCustomerDetails

2. Check customer creditEnterprise Resource Planning (ERP)

CheckCustomerCredit

3. Check inventory and package goodsInventory Management

PackageGoods

4. Start the deliveryDelivery System

StartDelivery

5. Prepare and send an invoiceEnterprise Resource Planning (ERP)

BillCustomer

Research in SOA / SOC

• IEEE International Conference on Web Services (ICWS)• IEEE International Conference on Services Computing (SCC)• International Conference on Service-Oriented Computing (ICSOC)• International World Wide Web Conference• IEEE Intl Enterprise Distributed Object Computing Conference

• IEEE Digital Library• ACM Digital Library• The DBLP Computer Science Bibliography

• service composition (esp. Semantics- and QoS- aware)

SOC Research Roadmap, 2006

Today

1. Service Oriented Architecture

2. Enterprise Service Bus

3. Macro-Microflow Pattern

4. Sample scenario

Nice idea but ...

• the world is not so simple• not everyone speaks WSDL 2.0 / SOAP 1.2• what about security ?• not everyone shares your data model• failures do occur• ...

Communication IS hard.

Enterprise Service Bus

ESB provides an infrastructure for communication ofservice provider and service consumers, namely:• communication using various transport protocols

– SOAP, HTTP(S), JMS, SMTP, file transfer, ...

• configurable message transformation and routing• service orchestration

– possibility to define processes consisting of individual services– centralized or decentralized execution

• common run-time environment for (internal) services• common (centralized) management

– configuring, administration, monitoring, logging, ...

Today

1. Service Oriented Architecture

2. Enterprise Service Bus

3. Macro-Microflow Pattern

4. Sample scenario

Business Owner View

1. Validate customer ID and status

2. Check customer credit

3. Check inventory and package goods

4. Start the delivery

5. Prepare and send an invoice

IT Department View• Customer Relation Management (CRM)

– packaged application, Windows, MS SQL Server– interface: HTTP, XML

• Enterprise Resource Planning (ERP)– packaged application, Windows, Oracle, Java– interface: messaging, XML

• Enterprise Resource Planning (ERP) 2– custom built application, IBM OS/390, IMS– interface: exchanging files, fixed length records

• Inventory Management– packaged application, Unix, Oracle– interface: HTTP, comma-separated values

• Delivery System– external service– interface: Web Services (SOAP), XML

Macro-Microflow Pattern – an approach to process-oriented SOA

• Macroflow Layer– processes as seen by business owners/analysts– no (or little) technicalities– long running processes– utilizes Macroflow Integration Services

• Microflow Layer– implements Macroflow Integration Services– using processes solving all the technical details– no (or little) business logic– short running processes– utilizes services of back-end applications

(Hentrich and Zdun, 2006)

Options

Macroflow Layer Microflow Layer

Option 0 custom code

Option 1 custom code custom code

Option 2 custom code standard infrastructure (ESB)

Option 3 standard infrastructure (BPM)

custom code

Option 4 standard infrastructure (BPM)

standard infrastructure (ESB)

Today

1. Service Oriented Architecture

2. Enterprise Service Bus

3. Macro-Microflow Pattern

4. Sample scenario

<?xml version=“1.0” encoding=“UTF-8”?>

<Order>

<OrderID>10200341</OrderID>

<Customer>

<CustomerID>100347</CustomerID>

</Customer>

<TotalPrice currency=“EUR”>103.00</TotalPrice>

<Items>

<Item>

<ProductID>491</ProductID>

<Quantity>100</Quantity>

<UnitPrice currency=“SKK”>1.03</UnitPrice>

</Item>

...

</Items>

<Shipping>

<ShipTo>Astronomicko-geofyzikálne observatórium,

920 01 Modra</ShipTo>

</Shipping>

</Order>

An Order

Service 1: GetCustomerDetailsInput: HTTP POST to http://crmserver.acme.org/custinfo

<?xml version=“1.0” encoding=“UTF-8”?>

<GetCustomerDetails>

<ID>100347</ID>

</GetCustomerDetails>

Output: HTTP data returned

<?xml version=“1.0” encoding=“UTF-8”?>

<GetCustomerDetailsReply>

<ID>100347</ID>

<Type>CORP</Type>

<Level>GOLD</Level>

<Name>Fakulta matematiky, fyziky a informatiky UK</Name>

<Address>Mlynská dolina, 84248 Bratislava</Address>

<Status>OK</Status>

</GetCustomerDetailsReply>

HTTP

browser (client)

server

request (document address)

reply (document)

HTTP

document address (URL): http://server/document

Hypertext Transfer Protocol (HTTP)GET /www/index.html HTTP/1.0 HTTP/1.0 200 Sending document MIME-version: 1.0 Server: OSU/2.0 Content-type: text/html Content-transfer-encoding: 8bit Last-Modified: Wednesday, 27-Aug-97 07:24:20 GMT Content-length: 2965 <HTML> <HEAD> <TITLE>Univerzita Komenskeho Bratislava</TITLE> </HEAD> <BODY> <IMG SRC="/www/pic/comenius1.gif"> <H1>Univerzita Komenskeho, Bratislava</H1> . . .

Server Reply: Server identification Document type Encoding used Time of last modification Document size Document itself

Client request – get document /www/index.html

HTTP 1.1: RFC 2616

Methods

Return codes

Using HTTP for application communication

method: GET; parameters in URL (limited size)

GET /getCustDetails?id=100347 HTTP/1.1

method: POST; parameters in message body

POST /getCustDetails HTTP/1.1

Content-Type: text/xml

<?xml version=“1.0” encoding=“UTF-8”?>

<Customer>

<ID>100347</ID>

</Customer>

Properties

• simple• rich existing infrastructure

– application servers– proxy servers and load balancers– standard security solution (HTTPS = HTTP + SSL/TLS)– monitoring tools, test clients, client libraries, ...

• almost no compatibility issues at the protocol level• synchronous mode

– both parties + network connection must be available– in order to be reliable the client must implement retry

mechanisms– server should respond in “reasonable” time (max. minutes)

Service 2a: CheckCustomerCreditInput: message sent to topic ERP.General.Entry

(broker MgmtBroker)

<?xml version=“1.0” encoding=“UTF-8”?>

<CheckCustomerCredit>

<Account>C-2004-10-997</Account>

<AmountEUR>102.00</AmountEUR>

<Category>A</Category>

</CheckCustomerCredit>

Output: message recv’d from JMS Topic specified in “Reply-To”

<?xml version=“1.0” encoding=“UTF-8”?>

<Credit>OK</Credit>

MessagingJMS flavor

• clients communicate through messaging broker(s)• a broker provides message queues and topics

Client 1

Messaging Broker

Client 2

Queue 1 Queue 2 Topic 1...

Queues

• a client sends a message into the queue• the message waits there until (another) client consumes it• there can be more consumers but every message is

delivered to only one of them• also known as point-to-point mode of operation

Topics• a client sends a message into the topic• the message is delivered to all clients that

– have subscribed themselves to that topic– are currently connected to broker (exception: durable

subscriptions)

• also known as publish/subscribe mode of operation

Message

A message consists of:• header• properties• body

Message Header

• JMSDestination (queue or topic name)• JMSDeliveryMode (persistent, non-persistent)• JMSExpiration• JMSPriority• JMSMessageID• JMSTimestamp• JMSCorrelationID• JMSReplyTo• JMSType• JMSRedelivered

black: can be set by sending client

blue: set by JMS provider whendelivering the message

Message Properties and BodyProperties• contain client-defined (application specific) name-value pairs

Body• contains client-defined content of following types:

– TextMessage (plain text)– MapMessage (java Map object)– BytesMessage (stream of bytes)– StreamMessage (stream of primitive java types)– ObjectMessage (arbitrary java object)– Message (empty one)– XMLMessage (contains XML stored as text)– MultipartMessage (contains more independent parts)

blue: Sonic specific

Other processing options

• acknowledgments– receipt of message has to be acknowledged, either:

• implicitly by the provider after client having read it, or:• explicitly by client by calling message.acknowledge()

– messages received but not acknowledged would be redelivered

Other processing options

• transactions– messages can be sent and received transactionally

(i.e. in “all or none” mode); transactions are either• local (operations on one JMS connection are transacted), or• distributed (operations on more JMS connections and on other

resources are transacted)

Properties

• reliable– acknowledgments, transactions

• synchronous or asynchronous– the only component that has to be available is the broker (can be

replicated)– need to correlate requests and replies

• suitable also for event notifications– topics with durable subscriptions

• many implementations of the idea (of messaging)– various APIs; Java Message Service API as a standard– JMS: portable, not interoperable

Service 2b: CheckCustomerCreditInput: file nnnnnn.req stored into specified directory

(server IBM01)

„ 100347 102.001“

Output: file nnnnnn.resp retrieved from the same directory

„OK“

Service 3: PackageGoodsInput: HTTP POST to http://inv.acme.org/apps/package

OPEN;10200341;0;0ADD;10200341;491;100ADD;10200341;30132;3ADD;10200341;43;20ADD;10200341;400;150...CLOSE;10200341;0;0(header X-OperationType: atomic)

Output: HTTP data returned

OK

or

OutOfStock (<list of product IDs>)

or

HTTP Status Code 4xx or 5xx

Service 4: StartDeliveryInput: SOAP message sent to URL http://express.com/services

<?xml version=“1.0” encoding=“UTF-8”?>

<env:Envelope xmlns:env=„http://www.w3.org/2003/05/soap-envelope“>

<env:Body>

<OrderDelivery>

<ID>1235471943:3381</ID>

<Customer>8991</Customer>

<Package>10200341</Package>

<From>...</From>

<To>...</To>

</OrderDelivery>

</env:Body>

</env:Envelope>

Output: SOAP response (via HTTP)

<?xml version=“1.0” encoding=“UTF-8”?>

<env:Envelope xmlns:env=„http://www.w3.org/2003/05/soap-envelope“>

<env:Body>

<OrderConfirmation>

<ID>1235471943:3381</ID>

<Status>CONFIRMED</Status>

</OrderConfirmation>

</env:Body>

</env:Envelope>

SOAP

• flexible protocol for transfer of XML messages between applications– application A (initial SOAP sender) sends message to

application Z (ultimate SOAP receiver); message can go through applications B, C, D, ... (SOAP intermediaries) on the way

• independent of transport protocol– usually HTTP(S), can be JMS, SMTP, ...

• message = header + body

SOAP (2)

• the header is typically used for control information for “advanced” services such as– security (authentication, integrity, confidentiality)– transactions– reliable delivery– addressing– ...

• consists of header blocks– generalized form of well-known headers of HTTP, RFC 822, ...– standard attributes: role, mustUnderstand, relay

• not defined by SOAP as such, but by various WS-* specs

• the body is application-specific (except for faults)

XML Namespaces

• names of elements and attributes can be globally unique, if there is a namespace specified for them

• examples:

<cat:PriceList xmlns:cat=“http://warehouse.sk/catalogue”>

<cat:Item> ...

<PriceList xmlns=“http://warehouse.sk/catalogue”>

<Item> ...

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

<env:Body> <objednavka xmlns="http://obchod.sk/schemy"> <predmet>matice M8</predmet> <mnozstvo>20 kg</mnozstvo> </objednavka> </env:Body></env:Envelope>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

<env:Header> <wsse:Security env:mustUnderstand="true" xmlns:wsse=...> <wsse:UsernameToken> <wsse:Username>peter</wsse:Username> <wsse:Password>secret!</wsse:Password> </wsse:UsernameToken> </wsse:Security> ... </env:Header>

<env:Body> <objednavka xmlns="http://obchod.sk/schemy"> <predmet>matice M8</predmet> <mnozstvo>20 kg</mnozstvo> </objednavka> </env:Body></env:Envelope>

SOAP (3) - an example

tags defined by SOAPtags defined by WS-Securitytags defined by the application

SOAP (4)

• message exchange can be – synchronous (e.g. request and reply in one HTTP session)– asynchronous (e.g. request and reply as separate HTTP

sessions)– one-way– ...

Properties

• platform neutral, generally accepted– rich programming support– though compatibility is not 100% (as of today)

• extensible– though more advanced specifications are not so widespread as

the basic protocol

• human-friendly (sometimes)– due to the use of XML

• performance issues– though alternative XML encodings are emerging

References• Hentrich, C., Zdun, U. (2006). Patterns for Process-Oriented Integration in

Service-Oriented Architectures. EUROPLOP 2006.• Papazoglou, M., van den Heuvel, W.-J. (2007). Service oriented

architectures: approaches, technologies and research issues. The VLDB Journal, 16, 389-415.

• Sonic Software Corporation (2005). Sonic ESB: An architecture and lifecycle definition. http://www.sonicsoftware.com/products/whitepapers/docs/esb_architecture_definition.pdf

• Booth, D., Haas, H., McCabe, F., Newcomer, E., Champion, M., Ferris, Ch., Orchard, D. (2004). Web Services Architecture. W3C Working Group Note. http://www.w3.org/TR/ws-arch/

• McKenzie, C. M., Laskey, K., McCabe, F., Brown, P. F., Metz, R. (2006). Reference Model for Service Oriented Architecture 1.0. OASIS. http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

• Papazoglou, M. P., Traverso, P., Dustdar, S., Leymann, F., & Krämer, B.J. (2006). Service-Oriented Computing Research Roadmap, In: Cubera, F., Krämer, B.J., Papazoglou, M.P. (eds.) Dagstuhl Seminar Proceedings 05462. Internationales Begegnungs-und Forschungszentrum für Informatik (IBFI), Schloss Dagstuhl, Germany.