Transcript Document

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/~pmederly
[email protected], M-171
ukončenie: projekt (ESB) + skúška
Today
1.
2.
3.
4.
Service Oriented Architecture
Enterprise Service Bus
Macro-Microflow Pattern
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 status
Customer Relation Management (CRM)
2. Check customer credit
Enterprise Resource Planning (ERP)
3. Check inventory and package goods
Inventory Management
4. Start the delivery
Delivery System (outsourced)
5. Prepare and send an invoice
Enterprise Resource Planning (ERP)
CRM
ERP
Data
Data
Inv. Mgmt
Delivery
Data
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 status
Customer Relation Management (CRM)
GetCustomerDetails
2.
Check customer credit
Enterprise Resource Planning (ERP)
CheckCustomerCredit
3.
Check inventory and package goods
Inventory Management
PackageGoods
4.
Start the delivery
Delivery System
StartDelivery
5.
Prepare and send an invoice
Enterprise 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.
2.
3.
4.
Service Oriented Architecture
Enterprise Service Bus
Macro-Microflow Pattern
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 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 environment for (internal) services
• common (centralized) management
– configuring, administration, monitoring, logging, ...
Today
1.
2.
3.
4.
Service Oriented Architecture
Enterprise Service Bus
Macro-Microflow Pattern
Sample scenario
Business Owner View
1.
2.
3.
4.
5.
Validate customer ID and status
Check customer credit
Check inventory and package goods
Start the delivery
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
–
–
–
–
(Hentrich and Zdun, 2006)
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
Options
Macroflow Layer
Option 0
Microflow Layer
custom code
Option 1 custom code
custom code
Option 2 custom code
standard
infrastructure (ESB)
standard
Option 3
custom code
infrastructure (BPM)
standard
standard
Option 4
infrastructure (BPM) infrastructure (ESB)
Today
1.
2.
3.
4.
Service Oriented Architecture
Enterprise Service Bus
Macro-Microflow Pattern
Sample scenario
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>
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>
HTTP
document address (URL): http://server/document
request (document address)
browser
(client)
server
reply (document)
HTTP
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>
Client request – get
document /www/index.html
Server Reply:
Server identification
Document type
Encoding used
Time of last modificatio
Document size
Document itself
<HEAD>
<TITLE>Univerzita Komenskeho Bratislava</TITLE>
</HEAD>
<BODY>
<IMG SRC="/www/pic/comenius1.gif">
<H1>Univerzita Komenskeho, Bratislava</H1>
.
.
.
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: CheckCustomerCredit
Input: 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>
Messaging
JMS flavor
• clients communicate through messaging broker(s)
• a broker provides message queues and topics
Client 1
Client 2
Messaging Broker
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
black: can be set by sending client
JMSReplyTo
JMSType
blue: set by JMS provider when
JMSRedelivered
delivering the message
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)
blue: Sonic specific
– Message (empty one)
– XMLMessage (contains XML stored as text)
– MultipartMessage (contains more independent parts)
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: CheckCustomerCredit
Input: file nnnnnn.req stored into specified directory
(server IBM01)
„
100347
102.001“
Output: file nnnnnn.resp retrieved from the same directory
„OK“
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
Service 4: StartDelivery
Input: 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/soapenvelope“>
<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/soapenvelope“>
<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> ...
SOAP (3) - an example
<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>
tags defined by SOAP
...
tags defined by WS-Security
</env:Header>
tags defined by the application
<env:Body>
<objednavka xmlns="http://obchod.sk/schemy">
<predmet>matice M8</predmet> <mnozstvo>20 kg</mnozstvo>
</objednavka>
</env:Body>
</env:Envelope>
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.