Service Oriented Architecture – Principles and Technologies

1. Service Oriented Architecture – Principles and Technologies Dr. Josef Withalm Mgr. Pavol Mederly

2. 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

3. 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, ...

4. Pondelok 11:30 – 13:05 akvárium VIalebo M-217 (bude vždy oznámené vopred + na webe) http://www.fmph.uniba.sk/~pmederly pavol.mederly@fmph.uniba.sk, M-171 ukončenie: projekt (ESB) + skúška

5. Today • Service Oriented Architecture • Enterprise Service Bus • Macro-Microflow Pattern • Sample scenario

6. 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

7. What is it good for ... ? • application integration • intra-enterprise • inter-enterprise (business-to-business) • application development

8. 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.

9. 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.

10. Systems involved • Validate customer ID and status Customer Relation Management (CRM) • Check customer credit Enterprise Resource Planning (ERP) • Check inventory and package goods Inventory Management • Start the delivery Delivery System (outsourced) • Prepare and send an invoice Enterprise Resource Planning (ERP)

13. SOA says to ... • publish relevant application functionality as services • create composite (integrating) application(s) that call them

14. (Some) services involved • Validate customer ID and status Customer Relation Management (CRM) GetCustomerDetails • Check customer credit Enterprise Resource Planning (ERP) CheckCustomerCredit • Check inventory and package goods Inventory Management PackageGoods • Start the delivery Delivery System StartDelivery • Prepare and send an invoice Enterprise Resource Planning (ERP) BillCustomer

15. 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

16. Today • Service Oriented Architecture • Enterprise Service Bus • Macro-Microflow Pattern • Sample scenario

17. 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.

18. Enterprise Service Bus ESB provides an infrastructure for communication of service 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 environmentfor (internal) services • common (centralized) management • configuring, administration, monitoring, logging, ...

19. Today • Service Oriented Architecture • Enterprise Service Bus • Macro-Microflow Pattern • Sample scenario

20. Business Owner View • Validate customer ID and status • Check customer credit • Check inventory and package goods • Start the delivery • Prepare and send an invoice

21. 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

22. Macro-Microflow Pattern– an approach to process-oriented SOA (Hentrich and Zdun, 2006) • 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

23. Options

24. Today • Service Oriented Architecture • Enterprise Service Bus • Macro-Microflow Pattern • Sample scenario

25. An Order <?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>

26. Service 1: GetCustomerDetails Input: 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>

27. HTTP HTTP document address (URL): http://server/document

28. Hypertext Transfer Protocol (HTTP) Client request – get document /www/index.html HTTP 1.1: RFC 2616

29. Methods

30. Return codes

31. 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>

32. 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)

33. Service 2a: CheckCustomerCredit Input: message sent to topicERP.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>

34. MessagingJMS flavor • clients communicate through messaging broker(s) • a broker provides message queues and topics

35. 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-pointmode of operation

36. Topics • a client sends a message into the topic • the message is delivered to all clients that • have subscribedthemselves to that topic • are currently connectedto broker (exception: durable subscriptions) • also known as publish/subscribe mode of operation

37. Message A message consists of: • header • properties • body

38. 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 when delivering the message

39. Message Properties and Body Properties • 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

40. 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

41. 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)

42. 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

43. Service 2b: CheckCustomerCredit Input:file nnnnnn.req stored into specified directory (server IBM01) „ 100347102.001“ Output:file nnnnnn.resp retrieved from the same directory „OK“

44. Service 3: PackageGoods Input: HTTP POST to http://inv.acme.org/apps/package OPEN;10200341;0;0 ADD;10200341;491;100 ADD;10200341;30132;3 ADD;10200341;43;20 ADD;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

45. Service 4: StartDelivery Input:SOAP message sent to URLhttp://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>

46. 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>

47. 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

48. 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)

49. 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> ...

50. <env:Envelopexmlns:env="http://www.w3.org/2003/05/soap-envelope"><env:Envelopexmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <wsse:Securityenv:mustUnderstand="true"xmlns:wsse=...> <wsse:UsernameToken> <wsse:Username>peter</wsse:Username> <wsse:Password>secret!</wsse:Password> </wsse:UsernameToken> </wsse:Security> ... </env:Header> <env:Body> <objednavkaxmlns="http://obchod.sk/schemy"> <predmet>matice M8</predmet> <mnozstvo>20 kg</mnozstvo> </objednavka> </env:Body> </env:Envelope> SOAP (3) - an example <env:Envelopexmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body> <objednavkaxmlns="http://obchod.sk/schemy"> <predmet>matice M8</predmet> <mnozstvo>20 kg</mnozstvo> </objednavka> </env:Body> </env:Envelope> tags defined by SOAP tags defined by WS-Security tags defined by the application