1	Leveraging Web Services Web Services Simplified Ben@RemoteSite.com
2	Agenda What are Web Services What is the Evolution of Web Services What are Service Oriented Architectures
3	What is a Web Service W3C Definition: A Web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols
4	Simplified Definition Encapsulated, loosely coupled, contracted functions offered remotely via standard protocols
5	Evolution of Web Services Evolved from needs Simply Distributed Computing Comply to Open Standards Built Upon RPC (Remote Procedure Calls) CORBA/IIOP EJB/RMI
6	Buzz Word Stack
7	Web Service Composition WSDL – Discovery/Description UDDI – Publish WSDL and SOAP – Bind
8	SOAP Defines a unit of communication (header,envelope, body) Defines error handling through Soap fault Defines extensibility usually through custom headers Defines mechanism for representing abstract data including binary data, arrays, and complex data Defines RPC – common format for distributed computation Defines Document- Centric approach to information exchange (i.e. B2B)
9	SOAP <?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAPSDK1:getTemperature xmlns:SOAPSDK1="capeconnect:AirportWeather:com.capeclear.weatherstation.Station"> <arg0>KDCA</arg0> </SOAPSDK1:getTemperature> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
10	SOAP- response <?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <cc1:getTemperatureResponse xmlns:cc1="capeconnect:AirportWeather:com.capeclear.weatherstation.Station"> <return xsi:type="xsd:string">The Temperature at null is null</return></cc1:getTemperatureResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
11	WSDL http://www.w3.org/TR/wsdl WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings described in this document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.
12	WSDL in layman's speak Defines what a service does – methods and operations How a service is accessed – details of data formats and protocols necessary to services operations Where a service is located – details of the protocol-specific network address, such as a URI/URL
13	WSDL in Specific portType- abstract interface definition like a java interface definition Message- Defines the set of parameters referred to by method sigs or operations Types – Data type def’s Binding – contains details on how abstract interface is converted to literal representation (I.e. SOAP over HTTP) Port – specifies actual service node endpoint (I.e. your http url) Service – bad name. Actual a series or list of ports which you can think of as a collection of web services that model a complex business process
14	Data Mappings
15	WSDL – what we care about http://localhost:8500/xml/webservice/square.cfc?wsdl <wsdl:message name="squareResponse"> <wsdl:part name="return" type="SOAP-ENC:string" /> </wsdl:message> <wsdl:message name="squareRequest"> <wsdl:part name="num1" type="SOAP-ENC:string" /> </wsdl:message>
16	UDDI Universal Description, Discovery and Integration Registry of Web Services across a network Public Private Part of a Web Services Network to support the publishing and consumption
17	Consuming Web Services Read the WSDL file Create Client Stub Get Parameters and figure data types Use a invocation method that generates SOAP message
18	Leveraging Web Services Individually exposed and consumed Application Specific need Through a Web Service Network Set of services that handle the discovery and securing of a Web Service Through an Application Design Discipline Application Design that fits the entire model
19	How SOA’s relate to Web Services service-oriented architectures are loosely coupled pieces of application functionality published consumed can be combined with other applications over a network. Web Services stack of emerging standards define protocols create a loosely coupled framework for programmatic communication among disparate systems
20	WS/SOA’s Benefits Frankly it’s the best application architecture approach for large and distributed architectures. More flexibility and more generic Interoperability is predefined and key which leads to greater ROI, longer life cycles, greater usability Makes more sense to “real people” J Creates new opportunities for business, revenue, creativity, and over all usefulness
21	Web Services Stack Evolution
22	SOA’s SOA’s are not so much a radical and disruptive technology paradigm shift like procedural to OO but a natural evolution of best practices.
23	SOA • Loosely Coupled. Senders and receivers (producers and consumers) are abstractly decoupled from each other. Senders construct self-contained messages (including but not restricted to XML documents) and send them using a standards-based communication backbone without knowing the actual location of the receiver. The communication mechanism is responsible for the abstraction between the sender and the receiver. • Coarse Grained. Traditional object-based languages like Java expose their interfaces on a fine-grained, method basis. These fine-grained interfaces need to be aggregated into larger, coarse-grained services that closely resemble real business processes. Service technologies are designed to support the ability to assemble services into larger, more business suitable processes. • Asynchronous. Asynchronous communication is essential for distributed architectures. Senders and receivers cannot always depend on the availability of each other to do their work. Through a system of intermediaries, messages are exchanged in real-time with high performance. Yet, when receivers are unavailable, the messages can be persisted for later
24	SOA STANDARS BASED: The connections are based upon vendor-independent standards. The development of generally open and accepted standards is a key strength of the coalitions that have been building web services infrastructure. Most previous efforts at distributed computing (e.g., CORBA, DCOM, RMI, and others) were very difficult to implement, because they were dependent upon a particular vendor’s product offering, highly specified, or programmatically complex—usually all of the above. PROCESS CENTRIC: Systems are conceived from a process-centric perspective. By intent, services are designed with a task-orientation; they function as discrete steps in a larger workflow or business process. A well designed service describes its inputs and outputs in a way that other software can determine what it does, how to invoke its functionality, and what result to expect in return.
25	Why SOA’s Frankly it’s the best application architecture approach for large and distributed architectures. More flexibility and more generic Interoperability is predefined and key which leads to greater ROI, longer life cycles, greater usability Makes more sense to “real people” J Creates new opportunities for business, revenue, creativity, and over all usefulness
26	Distributed Process
27	Break Down of Process
28	Change the way you think! SOA’s require you stop thinking about units of functionality, components, technology but force you to focus on what's important! Figuring out what you need to do and how to model it!
29	Implementations Today Re-Use and Syndication. Software re-use has always been a key part of component-based software models, but it rarely has been practical to implement. Web services may be different. Some early adopters envision syndicating existing software systems (e.g., an investment bank’s derivatives calculator or other complex algorithms) to partners and customers. Other re-use ideas include leveraging the standards-based interoperability to deliver data to a variety of formats and devices(e.g., web browsers, mobile devices, and interactive television). Automation and Productivity. Disparate systems still result in a remarkable amount of manual integration processes. As a result, web services’ interoperability promise to yield tremendous opportunities for productivity improvements through automation of business processes and employee productivity. Example projects might include exposing order status tracking and past purchase history to customers. Automation initiatives could yield results similar to the so-called “ATM Effect,” which has helped significantly simplify the cost structure and increase the profitability of retail banking.
30	More Implementations Visibility into Operations. Businesses consistently seek to improve the accuracy of their inventory and revenue forecasts but are constrained by a lack of clear visibility into operating data. Web services based “digital dashboards” are one way adopters hope to address this challenge. Several specific categories of information that are hot-button issues include demand forecasting throughout the supply-chain, real-time cash flow and operating capital, and production and inventory availability.Bottom-line, better visibility will yield a dramatic impact on a company’s cost structure. Exploring New Business Models. Most companies evaluating web services today are focused squarely on efficiencies and tend to put new web services-based revenue opportunities into a“sometime in the future” bucket. A few early adopters are exploring new subscription or pay-peruse business models, however. Further down the road, companies may spin off non-strategic (but potentially valuable) web service competencies, just as many tangible assets were “unlocked” at an increased value as stand-alone entities over the past ten years.
31	The Future Support for new protocols Greater interoperability Support for complex data types Support for emerging standards Exposure of the engine Orchestration
32	Summary Super easy to consume and deploy Supports emerging standards Has issues with complex data, different encoding, as well as protocols You have lots of options Web Services and SOA’s are moving targets and paradigms and we will see change and growth in this space for several years
33	Resources W3c.org www.macromedia.com Alphaworks.ibm.com www.xml.com www.webservices.org www.xmethods.net Uddi.org