Service Oriented Architecture – Principles and Technologies Dr. Josef Withalm Mgr. Pavol Mederly.
-
Upload
marcia-welch -
Category
Documents
-
view
219 -
download
0
Transcript of Service Oriented Architecture – Principles and Technologies Dr. Josef Withalm Mgr. Pavol Mederly.
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– Apache Camel– ...
• experiences with– practical service integration / adaptation tasks– WSDL, SOAP, XSLT, XPath, JMS, ...
Mondays 11:30 – 13:05
akvárium IV or M-217(will be announced in advance)
http://www.fmph.uniba.sk/[email protected]
course end: a project (ESB) + examination
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
Why?
• interoperability
• flexibility (run-time & design-time)
Real use?
• application integration– intra-enterprise– inter-enterprise (business-to-business)
• application development (some day...)
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=“EUR”>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.