1 / 40

Web Services & SOAP

Web Services & SOAP. Web Services Defined. Web services are a new breed of Web application. They are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web.

jensen
Télécharger la présentation

Web Services & SOAP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Services & SOAP

  2. Web Services Defined Web services are a new breed of Web application. They are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. Web services perform functions, which can be anything from simple requests to complicated business processes. ...Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service. -IBM’s tutorial on Web Services

  3. object-oriented WSDL UDDI SOAP or XML-RPC The Six Key Components • IBM’s definition identifies six key components of a web service: • self-contained • self-describing • modular applications • published • located • invoked across the web

  4. Architectural Perspective • A web service is essentially a standards-based façade, or wrapper for accessing non-standardized middleware components Web Server XML Request Web Service Business Service Listener middleware XML Response

  5. Web Services Compared • Why not use existing distributed, middleware solutions like RMI, CORBA, or DCOM? • DCOM is proprietary, thus negating the goal of standards-based interoperability • RMI is Java-based, and thus does not easily play well with other languages • CORBA comes closer. It is standards-based, vendor-neutral, and language-agnostic. It is limited however by its inability to utilize the power and flexibility of the Internet • Web Services are standards-based, vendor-neutral, language-agnostic, and they have been designed to leverage the service-centric, asynchronous nature of the Internet

  6. Architectural Details Web Server SOAP or XML-RPC • SOAP and XML-RPC have become accepted standards for XML-based messaging. -- wire format • HTTP is the defacto protocol for the Internet. – protocol • The Web Service will parse the request and either fulfill the request directly, or invoke one or more business services via some middleware API. HTTP CORBA, RMI, RMI/IIOP, JMS, Web Service Listener middleware SOAP or XML-RPC Jini, DCOM, vendor-specific API, etc. HTTP

  7. SOAP or XML-RPC Implementing Web Services • Web Services enable new kinds of applications, but they do not constitute these applications, nor do they build these applications • It is still necessary to use a programming language to design the client and server pieces of the communication • Java, C/C++, ASP, Perl, Ruby, etc. • Web services merely serve as the glue between the client and server applications Server App Web Service Client App

  8. SOAP request SOAP response SOAP processor UDDI registry service UDDI database Invoking a Web Service • Invocation process • Client queries a UDDI registry node • Server returns a list of records matching request • Client identifies a specific service of interest • Server binds client to the service so client can invoke service methods Web server Client application UDDI registry node

  9. Java and Web Services • Web Services are built on industry specifications with the following goals: • language and vendor independent • facilitate collaboration between applications as well as information exchange • The Java platform is also built on industry specifications and has similar goals: • platform independency (“Write Once Run Anywhere”™) • vendor neutrality • extensibility, integration, and simplified connectivity • As a vendor-neutral, platform-independent language, Java is perfect for implementing web service applications

  10. Sun’s JAX Pack • JAXP – Java API for XML Processing • a standard API for parsing XML documents that is parser-neutral (similar to JDBC) • JAXB – Java API for XML Binding • maps XML elements to Java classes • JAXM – Java API for XML Messaging • provides an API to allow Java components to send SOAP messages via HTTP • JAXR – Java API for XML Registries • provides a standard way to access business registries and share information • JAX-RPC – Java API for XML-based RPC • sends SOAP method calls to remote parties over the Internet and receives the results

  11. The JAX Pack • JAXP – Processing • plug in any compliant parser • supports both SAX and DOM processing • supports XSL and XSLT • it is the foundation of any XML processing application • JAXB – Binding • provides a means of mapping XML documents to Java objects • the JAXB complier generates Java classes based upon a schema (or DTD) • these classes contain all the code necessary to parse and manipulate XML documents that conform to the schema

  12. The JAX Pack • JAXM – Messaging • a standard, XML-centric, means of sending messages over the Internet from the Java platform • based on SOAP 1.1 and SOAP with attachments specs • requires a messaging provider implement the API • JAXR – Registries • provides a uniform way of accessing business registries over the Internet from the Java platform • the API abstracts Java developers from the low-level details of UDDI or ebXML’s registry service • JAX-RPC – XML-based RPC • allows Java developers to write pure Java code devoid of XML and still access XML-based web services

  13. SOAP • Simple Object Access Protocol • protocol is the key word • Based on XML-RPC (JAX-RPC) • XML format for encoding data • Request/Response architecture • Transport is normally HTTP • can be anything (SMTP, SNMP, etc)

  14. SOAP In One Slide SOAP1.1 Message Structure • XML based protocol for exchange of information • Encoding rules for datatype instances • Convention for representing RPC invocations • Designed for loosely-coupled distributed computing • No remote references • Used with XML Schema • Transport independent • SOAP with Attachments allow arbitrary data to be packaged. SOAP Envelope Header Entries [Header Element] Body Element [Fault Element]

  15. A Simple SOAP Request POST /calendar-request HTTP/1.1 Host: uche.ogbuji.net Content-Type: text/plain; charset="utf-8" Content-Length: 507 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" > <SOAP-ENV:Body> <c:AddListing xmlns:c="http://uche.ogbuji.net/soap-example/calendar"> <c:when> <c:Date> <day>21</day> <month>6</month> <year>2001</year> </c:Date> </c:when> <c:what>A total eclipse will be visible across Central Africa.</c:what> </c:AddListing> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

  16. The SOAP Response HTTP/1.1 200 OK Server: PythonSimpleHTTP/2.0 Date: Tue, 28 Nov 2000 04:23:03 GMT Content-type: text/xml; charset="utf-8" Content-length: 296 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" > <SOAP-ENV:Body> <c:AddListingResponse xmlns:c="http://uche.ogbuji.net/soap-example/calendar"/> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

  17. SOAP Envelope • Simple wrapper for message payload • May specify encoding for message • Specification defines one encoding, • http://schemas.xmlsoap.org/soap/encoding • Also known as “RPC encoding”, this handles basic primitive types and arrays, composites of these types • Other encodings may be used, including user-defined encodings

  18. SOAP Header • Can optionally add information to message: • Authentication information • Session management • Transaction management, etc. • Very flexible, but standards needed • Only a pair of attributes defined, not widely used • .NET extends with its own set

  19. SOAP Body • Message payload container • Three commonly-used formats: • RPC encoded -- encoding defined by SOAP specification • Document literal -- XML message with format determined by schema (WXS) • Wrapped -- document literal variation, with call parameters as children of root element • Service defines the format to use (WSDL)

  20. SOAP Attachments • SOAP Body content issues: • Character set restricted in XML (only whitespace allowed below 0x20) • XML must be well formed - single root element, all tags closed, etc. • Binary data must be encoded with heavy overhead • Attachments use MIME multipart message format • Any type of data to accompany SOAP • Avoids XML encoding issues

  21. WSDL • Web Services Description Language (WSDL) • 1.1 draft specification released March 15, 2001 by Ariba, IBM, and Microsoft • an XML-formatted language that defines the ways you can contact a web service and describes the message formats you should use • WSDL is essentially the IDL of web services • makes a neutral declaration of the existence of one or more services • describes the way a client can interact with those services

  22. WSDL in One Slide WSDL1.1 Document Structure • A WSDL document describes • What the service can do • Where it resides • How to invoke it • WSDL are like IDL but lot more flexible and extensible • Defines binding for SOAP1.1, HTTP GET/POST and MIME • WSDL descriptions can be made available from an UDDI registry WSDL Document [Types] {Messages} {Port Types} {Bindings} {Services}

  23. WSDL Example <?xml version="1.0" encoding="UTF-8"?> <definitions name="FlightService" targetNamespace=...> <message name="getFlightArrival"> <part name="String_1" type="xsd:string"/> <part name="int_2" type="xsd:int"/> </message> <message name="getFlightArrivalResponse"> <part name="result" type="xsd:dateTime"/> </message> <portType name="FlightRemote"> <operation name="getFlightArrival"> <input message="tns:getFlightArrival"/> <output message="tns:getFlightArrivalResponse"/> </operation> </portType>

  24. WSDL Sample (cont.) <binding name="FlightRemoteBinding" type="tns:FlightRemote"> <operation name="getFlightArrival"> <input><soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="encoded" namespace="http://allflighttracking.com/wsdl"/> </input> <output><soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="encoded" namespace="http://allflighttracking.com/wsdl"/> </output> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/> </binding> <service name="Flight"> <port name="FlightRemotePort" binding="tns:FlightRemoteBinding"> <soap:address location="http://localhost:8080/axis/..."/> </port> </service> </definitions>

  25. SOAP/WSDL Applications • Automatic proxy generation • “Web page equivalent” services: • Information retrieval (quotes, weather, prices, etc.) • Calculations (interest payments, currency and unit conversions, etc.) • Simple actions (messaging, registration, etc.) • Developing applications: • Connecting distributed program components (cross platform and cross programming language) • Intrasystem software component communications

  26. Web Services Applications • Wrapper for other components • Web-enable legacy applications • Standard wrapper for any enterprise application • Intranet architectural standard to reduce costs and improve development time and reliability • Integrate middleware components, back-end resources, and legacy applications via a common, vendor-neutral, language-agnostic API • B2B facilitator • Faster time to market for integrating new partners into a supply chain or partner intranet • Extranet portal enabler

  27. Software Architecture Today • Tightly-coupled • Significant system changes (data model, web server, database, etc.) are difficult • Changes to software architecture require unrelated components to be modified • Long Development Cycles • Slower time to market due to poor component reuse • Additional time spent dealing with proprietary APIs • Expensive • High maintenance and integration costs due to a lack of standards and poor design

  28. Web Services in a Nutshell • Loosely Coupled • Agreement on two things • wire format (HTML, XML, WML, etc.)–standardized • protocol (HTTP, SMTP, TCP/IP, etc.) • Implementation details are hidden • Coarse-Grained • Cross-network communication must maximize efficiency by reducing network round-trips • Service exposes a façade that may hide many smaller services used to fulfill the client’s request • Asynchronous (yet conversational) • Service-oriented requests cannot always be immediately performed (e.g. processing, approval, shipping, etc.) • Ability to keep track of a “conversation”

  29. Problem Solvency

  30. Web Services Industry • Microsoft .NET • The “.NET experience”, aimed at the consumer market • “Imagine you wanted to turn up the heat in your house while you were away from home. You could use a .NET experience that controls your household utilities through a smart device. The device you use could be your desktop computer…smart phone…or a kiosk.” • IBM Dynamic E-Business • “It is the dynamic adaptation of e-business processes and associated systems to support changing business strategies and tactics.” • “For the first time, large companies can be as flexible and agile as start-ups in finding better ways to be more competitive.”

  31. Web Services Industry • Sun ONE • “Smart Web Services” – contextual • Integrateable platform as opposed to .NET being integrated and proprietary • MindElectric Glue • A free SOAP framework designed to speed time to market for developing web service components • Instantly publish any Java object as a web service • Apache Group Axis, SOAP • Open source SOAP implementations • Cooperation with Microsoft to ensure interoperability with Microsoft SOAP

  32. Industry Projections • IBM • “Web Services will be bigger than Java or XML” – Rod Smith, VP of Emerging Technology, IBM • Forrester Research • By 2003, the market for software components used to build services will represent a $14.5 billion industry. • Gartner Group • Within the next 4 years, 60% of all new business applications will utilize a service-oriented architecture • By 2004, 40% of financial services transactions and 35% of online government services will be web service-based

  33. Web Services and JBoss • JBoss comes with axis web service • jboss-net.sar ---- put in your deploy directory • Web services may be deployed 2 ways • Create a .jws file • Any java class - combined with a web services deployment descriptor

  34. .jws files • Automatic Web Services • Any java class - javaclassname • File name must be javaclassname.jws • Access the jws file • http://localhost:8080/TestApps/HelloWorldJWS.jws?wsdl • Wsdl and deployment descriptor is generated automatically • Must make mapping changes in web.xml

  35. web.xml <servlet> <servlet-name>AxisServlet</servlet-name> <display-name>Apache-Axis Servlet</display-name> <servlet-class> org.apache.axis.transport.http.AxisServlet </servlet-class> </servlet> …… <!-- The axis mappings --> <servlet-mapping> <servlet-name>AxisServlet</servlet-name> <url-pattern>/servlet/AxisServlet</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>AxisServlet</servlet-name> <url-pattern>*.jws</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>AxisServlet</servlet-name> <url-pattern>/services/*</url-pattern> </servlet-mapping>

  36. The Java client import localhost.TestApps.AddFunctionJWS_jws.*; public class AddFunctionClient { public static void main(String [] args) { try { AddFunctionJWSService afs = new AddFunctionJWSServiceLocator(); AddFunctionJWS af = afs.getAddFunctionJWS(); System.out.print("addInt(" + args[0] + "," + args[1] + ") = "); System.out.println( af.addInt(Integer.valueOf(args[0]).intValue(), Integer.valueOf(args[1]).intValue()) ); } catch (Exception e) { System.err.println("Execution failed. Exception: " + e); } } }

  37. Getting it all going • WSDL2Java • java org.apache.axis.wsdl.WSDL2Java http://localhost:8080/TestApps/AddFunctionJWS.jws?wsdl • Compile it • Classpath must include • . -- current directory • All the axis jars found in jboss-net.sar • Run it • java AddFunctionClient 4 5

  38. Exposing Other Classes • Any java class can be exposed with SOAP • Must be in classpath • Must identify in web services deployment descriptor (web-services.xml) • Goes in a .wsr file in the META-INF directory • Most often, this is only thing in .wsr file • Very useful for exposing EJBs

  39. web-services.xml <?xml version="1.0" encoding="UTF-8"?> <deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <service name="HelloWorldService" provider="java:RPC"> <parameter name="className" value="myservice.HelloWorldService"/> <parameter name="allowedMethods" value="*"/> </service> <service name="ExampleEntityBean" provider="Handler"> <parameter name="handlerClass" value="org.jboss.net.axis.server.EJBProvider"/> <parameter name="beanJndiName" value="MyExampleEntityBean"/> <parameter name="homeInterfaceName" value="ExampleEntityBeanHome"/> <parameter name="allowedMethods" value="*"/> <requestFlow name="ExampleEntityBeanRequest"> <handler name ="TransactionRequestHandler" type="java:org.jboss.net.axis.server.TransactionRequestHandler"/> </requestFlow> <responseFlow name="ExampleEntityBeanResponse"> <handler name="SerialisationResponseHandler" type="java:org.jboss.net.axis.server.SerialisationResponseHandler"/> <handler name="TransactionResponseHandler" type="java:org.jboss.net.axis.server.TransactionResponseHandler"/> </responseFlow> </service> </deployment>

  40. Calling a bean method via SOAP public String MakeExampleEntityBeanServiceCall() { try { String endpoint = "http://localhost:8080/jboss-net/services/ExampleEntityBean"; String methodName = "EntityHello"; String arg = "Quinn"; Service service = new Service(); Call call = (Call) service.createCall(); call.setTargetEndpointAddress( new java.net.URL(endpoint) ); call.setOperationName(methodName); // Call to addParameter/setReturnType as described in user-guide.html call.addParameter("name", org.apache.axis.Constants.XSD_STRING, ParameterMode.IN); call.setReturnType(org.apache.axis.Constants.XSD_STRING); String ret = (String) call.invoke( new Object[] { arg } ); return ret; } catch (Exception e) { return("ExampleEntityBeanService error: " + e.toString()); } }

More Related