WEB SERVICES SOAP, WSDL, UDDI, WS-BPEL

WEB SERVICES SOAP, WSDL, UDDI, WS-BPEL

SOA as Web Services Business data as XML messages Sent in a SOAP body Enriched with metadata in SOAP headers Described in WSDL and XML schema Configured through WS-Policy (security, SLA, QoS) Registered in UDDI registry, discovered using WS- Discovery

SOA as Web Services UDDI gives a services listing WSDL UDDI WSDL describes the service Technical service interface (+SLA, policies, etc.) WSDL reads Is accessed using SOAP describes + registers Application SOAP client communicates SOAP server Application SOAP messages (envelopes) carrying the message payload

SOA as Web Services Considerable advantages of WS technologies Independent of programming language, platform, data models, etc. Standards are open Some vendor-specific extensions Should enable reasonably easy (and inexpensive) interoperability and integration over the boundaries of systems and organizations, and firewalls (HTTP) Can be used to expose existing application functionality as a service

Web Services Standards Pyramid Vertical Non-Standard Business Semantics Horizontal (Non-)Standard Security, Routing, Workflow, Transaction Management Horizontal Standard WSDL, UDDI SOAP, XML-RPC XML, XML Schema HTTP, FTP, SMTP Internet, Intranet, Exranet

WS Standards as of Q1 2007 http://www.innoq.com/resources/ws-standards-poster/ http://en.wikipedia.org/wiki/list_of_web_service_specifications#web_service_standards_listings

WSDL Web Services Description Language A document written in XML that describes a Web Service Specifies the location of a service and the methods the service exposes Without WSDL, the calling syntax must be determined from a documentation prior to execution With WSDL, the generation of proxies for Web Services can be automated in a language and platform independent way

WSDL Service operation messages messages operation input output input output porttype Service Resource

WSDL

UDDI Universal Description, Discovery and Integration An open industry initiative sponsored by Organization for the Advancement of Structured Information Standards (OASIS) Either public or private registry that can be used to publish and discover service listings Contains information about the service provider, service metadata and technical instructions for the use of service

UDDI Registry contains three components for different types of information White Pages: Provider s addresses, contant information, identifiers Yellow Pages: Industrial categorization based on standard taxonomies (e.g., branch of industry, geographical locations) Green Pages: Technical information about the provided services (e.g., functions, network address)

UDDI http://soapclient.com/uddiadv.html Provider: Information about the entity who offers a service 0 n Service: Descriptive information about a particular family of technical offerings 0 n tmodel: Descriptions of specifications for services. Bindings contains references to tmodels. These references declare the interface specifications for a service. 0 n Binding: Technical information about a service entry point

tmodel refering to a service WSDL <tmodelxmlns="urn:uddi-org:api tmodelkey="uuid:aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"> <name>hp-com:creditcheck</name> <descriptionxml:lang="en">checklimitreporter</description> <overviewdoc> <overviewurl>http://schema.com/creditcheck.wsdl</overviewurl> </overviewdoc> <categorybag> <keyedreference tmodelkey="uuid:cd153257-086a-4237-b336-6bdcbdcc6635 keyname="consumercreditgatheringorreportingservices keyvalue="84.14.16.01.00"/> <keyedreference tmodelkey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4 keyname="types keyvalue="wsdlspec"/> </categorybag> </tmodel>

SOAP Formerly known as Simple Object Access Protocol. Now just SOAP it is not simple and has nothing to do with objects. An XML-based protocol for the communication between a client and a service Originates in XML-RPC Implementations available practically for every programming language Defines An envelope that encapsulates an XML message (payload) Headers for additional functionality (e.g., security, transactions) Data serialization for RPC and document-styled communications Binding to a carrier protocol (usually HTTP)

SOAP used in RPC style 1 2 Client App SOAP Client Server App SOAP Server 7 6 1. Call method / Return response 2. Marshal parameters 3. Serialize / Deserialize 4. Transport 5. Deserialize / Serialize 6. Unmarshal parameters 7. Method executes Stub SOAP HTTP 4 Stub 3 5

SOAP float addition(float a, float b); request response

SOAP message structure Headers can be used to define additional and application specific features on top of basic features. In this case, the service is required to understand (mustunderstand) the Transaction element Body, Payload Faults can be used to inform a client about an occurred error

SOAP with Attachments Multipart MIME messages can be used to attach, for example, binary data to a SOAP message Part A of a MIME message is the actual SOAP envelope Part B is an encoded binary data block which SOAP message references to

Supported communication models It is possible to implement different distributed applications on top of SOAP Request/Response interaction style similar to object- ja procedure-oriented programming (RPC) Asynchronous messaging similar to MOM systems (document Asynchronous messaging similar to MOM systems (document style messaging) Broadcasting Forwarding via SOAP intermediaries (e.g., routing and caching) Can use an additional functionality of messaging services and middleware (e.g., JMS)

RESTful Web Services Representational State Transfer is an architectural style that builds upon web standards such as HTTP, URI XML, HTML, JPEG, etc. (resource representations) text/xml, text/html, image/jpeg, etc. (MIME types) In practice, the web as we know it is a REST system Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use. R. Fieldman

RESTful Web Services Examples from R. L. Costello http://www.xfront.com/rest-web-services.html Resources of a service are represented via URIs, e.g., Collection URI http://www.parts-depot.com/parts Element URI http://www.parts-depot.com/parts/00345 The client issues an HTTP GET request to the collection URI to receive the parts listing <?xml version="1.0"?> <p:parts xmlns:p="http://www.parts-depot.com" xmlns:xlink="http://www.w3.org/1999/xlink"> <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/> <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/> <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/> <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/> </p:parts> The representation can be rendered human readable by a web browser or it can be processed programmatically That how the resource is actually implemented is transparent to a client and it can be changed any time loose coupling

RESTful Web Services Following an URL on the parts listing, a client issues another GET request to receive detailed information about a certain part http://www.parts-depot.com/parts/00345 <?xml version="1.0"?> <p:partxmlns:p="http://www.parts-depot.com" xmlns:xlink="http://www.w3.org/1999/xlink"> <Part-ID>00345</Part-ID> <Name>Widget-A</Name> <Description>This part is used within the frap assembly</description> <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/> <UnitCost currency="usd">0.10</unitcost> <Quantity>10</Quantity> </p:part> a representation of another resource follows a state transition

RESTful Web Services In addition to HTTP GET, a REST architecture utilizes POST, PUT, and DELETE methods to interface the resources For example, to submit a purchase order on a part, the client creates a PO document that conforms to the PO schema (published in a WSDL document) and then submits as a payload in an HTTP POST

RESTful Web Services Simple and light-weighted compared to SOAP Web Services Like SOA, REST is an architectural style and not an architecture per se Can be implemented in various ways and is totally agnostic to an underlying technology (except the web standards) Requires careful design of a service Limited in capabilities compared to SOAP

WS-BPEL Web Services Business Process Execution Language

Motivation Web Services are built upon open and platformindependent standards that allow loosely coupled interconnections and interoperability between the heterogeneous systems The aim is to support flexibility and business agility Services are highly reusable Services represent business-oriented concepts on a fairly high level of abstraction Services are quick and easy to attach and detach just like the Lego blocks http://www.zapthink.com/2006/12/11/the-legoreg-model-ofsoa/

Motivation However, services are transactionally stateless and (by definition) self-contained WSDL does not consider message sequencing In order to create composite services and business In order to create composite services and business processes based on Web services, an additional layer of abstraction is needed Enter WS-BPEL

Web Services Platform Architecture 2007 IBM Discovery, Negotiation, Agreement BPEL Component Orchestration Protocols State Model Reliable Messaging Composite Interface + Bindings XML Security Transport Atomic Transactions Policy Non-XML Components Quality of Service Description Messaging Transport

0#' '#%'$) #%!#(* '$ +.'#%' "#$% $# %$//#% "%%'$ $', '#%' & -%!' "#$% %$/"$'$ $ #(% # '& #(% %$/ #$/ "#$(& "$#') '#$"# "#$% /$& 0$/"$'$ & $ '#%' &%#"'$! "#$% %$$#&'& ' $ #(%. & $ '$" $ & %$# 12 "%%'$ '#$! /* %$%"' #$/ '#!%'!#& "#$ 2# 3 & 1.45 %$%"' #$$' '#&'$ $+ /$& #//! -%!' "#$% "#$(& /$& '$ ' #' '#"# ""%'$ 0001234546278912

7.89!" #$%&""&' &!"! #:%&"";' ()*+, *, *-./ 01/ 1* (2-34 4 *- 015 6 4 1*5 (<=4 *, >3-4 ).0 (? 44, *3> *-. 4 3, (2>*,@ ).0 >4*++ 4*4A (2-- B* =,3, 0001234546278912

7 * $ $ + &, -++..'% +'$% $ *''' ''' #2 3 *$, "& ''""4 ''"")$'!" /&0& #$ %$ #$ '$(' 1 $! ' &' )$'% $( 5*&,! #6!" $ 0001234546278912

#$%&' ()&*%' +' " '+&&,! " 0001234546278912

$%&! "#" () * +,,-! "#" $%& 0001234546278912

8 9:;,+< -'/,+7+ &''( )!"#$% ++-+ #++ &$.*0 12 923''++ ) = >; 7 7/,+< '/ 4?0 + *++ *.-, *++ '+ *+,-+++ *++.- /-/ "'/+ +* '45+4 *+ ' ++ 6-' * - 7 -+/ *+ -'/, *++ '+*+'?0 +< 6-0 /+ &%+ ++-+ 7, &++- '+-++ *@5444A/0A5.5 B"#$%B++-+B+A 0001234546278912

-8( 48.5/84! 01 2# $! 568 43782/684838529 /29/8784! # $! 301 01 89893+:30!"0; # 01 6583/65/3+ 39) 3766+5?8"0!!2! #@!#" 01!" #$# %&'6(348) +39,38 $!200 $ 01 59893+ :<"03; => $ 3!" 2#!" #"2 " 0 # 234 A! 0!"0 2# #$# 0 A 5)8985B5/38529 78/639547 B2 72/844 594839/84 C1 (345/ +5B8/D/+8 78/639547 2 0"E 2 = "0 "!0 # 0!20 $!0 B35+,8 8/2.8D$!!=## 0 01!" "0 30 /277385(+8-8( 48.5/84 4839)3)4 59 3 /277243(+8 39) 72),+3 73998! 3!"!0 $ 0001234546278912

#$%&' ()&*%' +' " '+&&,! " 0001234546278912

" #$ % % $ $ $! & 0001234546278912

!" # 239 7723 2844 $ %&''' (%&'" ' # '' )*'' )# &0 %0 + (, 1" 1., %&''!!.! "" /&- %!+' - %.& # &%.! "/!.&!'.&!' 2., %!".,.!' & &.51%! 4%%& #0 8858 873 0001234546278912

!" # $ %&'() "." / 0 $ "*#$ $#*# +#, -) 0 #, &'() " 5$#:*." / 0 #, &'() " 5$#:* $!/ )*$ 1"" ' -) #30" *2 239 7723 2844 4$*$*2 5$### $6 8858 7) *$ 1"" 8 87; 59298 0001234546278912

# $ 8)85'8!" 59'2(8!" #% & % & 8)85'8 59'2(8 59'2(8 $% & 0001234546278912

+3,98!" # &' ( )'' ** $ % $ )' +27844 8 % 5 234-59. 0178 % 6 234 +27844 9 0001234546278912

EF 34459 6+-2'.,*/#*45'" (72'. *" 869: &'""*$'" -/ ;<: 6+='&* '5'&'%(">(72'"!+(#,#(#'"1#%20( *%. -0(20( 3'2( #% "+-2'.,*/#*45'"!""#$%&'%( *+(#,#(#'" 1 1 1 8D85@8 &-,'.*(* */-0%. 59@2A8 1 1 1 87BC GHIJ 0001234546278912

!" # %&' ( )%!"& >% /#' 3.!8 '?%)"%# 0 '@! %!# - # ## 1 %) 2;<= > ##%6# 2844 94398 2844 94398 2G8HFEI8 2844 94398 2844 94398 JJ *+,! "' *520 ##%6 3 # )%! 1"0 '!!8 # "& )&67/&&"&6 0&1 &!"-. #!%! "&! 0 -%0 -/) "&#!%&0 #4 0! 0 ## "&#!%&0 # 1"% #!%! #%!"&# % )## 9:. '!" # ' -"& ' "& 2;<= % &%> ' %&' ABCD E84438 F42E8G 0001234546278912

:;20 #$!!"! ' (& & $! %& )*( +%$ " *,$ -./ $ % % % " $ $ 0(% * % *? 858568 596298 8778 035: 8<5: 6375>3:8 34459 8:;20 8=7:8 52=78943:8A5278 8<:894529@5:565:8 1 2 * % *! $ " '!!$& "$ $ *! $ * 4 * %! 3* '!%!%$! " %$! % $ * 4 '!%!%$ "$ % $* %% * 3 $ 0001234546278912

7501 "#" $ %& '!!! (" " " 48238908 -.20 0/5.8-2630/ 878345945. 5-68.48 40278 )$ ( % * &#! %& + &,! *" %! '! *! % *! (" %& % " ( * & " " % " 0001234546278912

#!$% '''(" 838548 )*+,"!" $,.$* ''' " (,.$*" %+- '''(" /$0!" ( #!$% '''(" $ %+- ''' ("!"!""'''(/$0 " ( ()*+," #1*2 '''("!" 48898938 48898938 594278 :520 48898938 838548 594278 8756 34459 0;58 0001234546278912

;353=84 1 1 19283529 7398 59<4 49278 8;89 484 3984 92:78943529 3984 3 8:593529 398 1 1 1 1 1 1 398!" #$%!" & $'!" &$ &!& ( &$#$&$ )%$ &*&*+!,#& -!1*& -!50&$ -!80$&$ -./ #& &$0 #& 2$/ 3$&- $(& 4&$ )$ *&$+ $&*&$ )$& (*&+ 0& &$#$&$ 6$/ $& (& ( 7 2$/ 3$&- ( &0$&$ )4& (*&+ 1 1 1 0001234546278912

!! "" # $% & '$(! ") * ',( " " " "+ (! " #! % "+ -! 885.8 59.218 2844 59.218 59.218 87/0 0001234546278912

Limitations to overcome No standards for graphical notation The underlying XML code is (mostly) the same and processes therefore portable. Eclipse WebSphere Studio

Limitations to overcome Most of the vendors have started using BPMN as a graphical frontend for BPEL

Limitations to overcome The BPMN specification includes a mapping from BPMN to BPEL 2.0 Implemented in several vendor tools In practice, allows to transform business process models executable processes However, there are some fundamental differences between the two It is difficult and some times impossible to generate BPEL code from BPMN models Round-tripping is even more difficult as developers add new tags to the XML as needed

Limitations to overcome BPEL omits certain process constructs Not possible to express all conceivable business processes Therefore, BPEL is often used in conjuction with real programming languages or extended by the scripting languages leads to proprietary process models BPELJ (BPEL for Java) extension adds lower level (finer-grained) programming constructs Inclusion of Java code, enterprise beans etc. C# equivalent of BPELJ is under the works

BPEL extended with Java code

Limitations to overcome Originally, BPEL completely omitted the human activities in business processes Since then, the standard WS- HumanTask was introducted Human interactions and other activities performed by human actors Wrap a human actor inside the WSDL API BPEL4People extension by SAP and IBM in 2005

CRITICISM

The modern technology and standards which enable SOA allow disparate technologies to communicate, regardless of manufacturer, platform or language. Web Services Standards as of Q1 2007, InnoQ That was pretty current on first quarter of last year. In other words, it is totally outdated today. http://www.innoq.com/resources/ws-standards-poster/

Critical Factors Analysis of the SOA Reference Architecture (OASIS) http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf

SOA gets too complicated. Lets use JBOWS architecture instead. As we found in the recent Webservices.org survey, there were, out of 1,000 companies, only 50 that really were well advanced in their deployments, that could be considered true SOA sites. J. McKendrick Not orchestrated, does not have a registry, has no process-based testing, does not reuse services, and has no management tools. J. McKendrick

InformationWeek survey on SOA 21.2.2009 Survey of 270 business technology professional 23% of respondents said their organizations have deployed SOA 7% of resulting systems are available for external use The percentage of overall software reuse within the organizations that have implemented SOA rose 7% So, SOA seems to fail in delivering one of its most basic promises? Forget about developing business-driven, highly abstracted and composable loosely-coupled services if you can t develop reusable software components. * * Not surprising since this requires a strategy change and strong managerial support and commitment. Read more: Sherif K. & N. M. Menon, 2004, Managing Technology and Administration Innovations: Four Case Studies on Software Reuse

Anne Thomas Manes, 5.1.2009: SOA is Dead http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html Once thought to be the savior of IT, SOA instead turned into a great failed experiment at least for most organizations. SOA was supposed to reduce costs and increase agility on a massive scale. Except in rare situations, SOA has failed to deliver its promised benefits. After investing millions, IT systems are no better than before. In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever. Anne Thomas Manes is a Vice President and Research Director of Burton Group. She is also a very influential member of SOA community, voted as one of the 50 most powerful people in networking, among the Power 100 IT Leaders, former CTO at Systinet, etc. Her article about the death of SOA was taken very seriously. Especially among the software vendors.

What will come next? Of course, more hype words SaaS, cloud computing, business clouds, private clouds, situational integration, mash-ups, composite applications Experts are already warning about not to repeat the same mistakes with SaaS and in the clouds Or more comprehensive understanding about the problem domain? CBM/SOMA/SCA (c.f., J. Poutanen s presentation) SOE (and service-orientation in general) SOA backed up by EA? SOA backed up by reasonable governance structures and thoroughly considered alignment perspective. This is the least what one should consider.

On a side note, please read The Raise of Fall of CORBA by Michi Henning, ACM Queue, Vol. 4., Issue 5, June 2006 available at http://portal.acm.org/citation.cfm?id=1142044&coll=portal&dl=acm&cfid=5156 53495&cftoken=515653495 Depending on exactly when one starts counting, CORBA is about 10-15 Depending on exactly when one starts counting, CORBA is about 10-15 years old. During its lifetime, CORBA has moved from being a bleedingedge technology for early adopters, to being a popular middleware, to being a niche technology that exists in relative obscurity. It is instructive to examine why CORBA despite once being heralded as the nextgeneration technology for e-commerce suffered this fate. CORBA s history is one that the computing industry has seen many times, and it seems likely that current middleware efforts, specifically Web services, will reenact a similar history.