1 / 44

Developing Web Services

Developing Web Services. mdthomas@ibiblio.org. Agenda. Quick Review Web Service Architecture Web Services Interoperability Java APIs .NET APIs. The World, Late 80’s-Early 90’s. Organization. Web Apps. Internet. Web App Server. Organization. Web Services. Organization. Web App

mauli
Télécharger la présentation

Developing Web Services

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. Developing Web Services mdthomas@ibiblio.org

  2. Agenda • Quick Review • Web Service Architecture • Web Services Interoperability • Java APIs • .NET APIs

  3. The World, Late 80’s-Early 90’s Organization

  4. Web Apps Internet Web App Server Organization

  5. Web Services Organization Web App Server Organization Web App Server Internet Web App Server Web App Server Organization Organization

  6. Web Service Architecture • Provider Agent Architecture • Requestor Agent Architecture • Provider and Requestor Combined • Asynchronous web services • Web Services And The Rest Of Your Application

  7. Web Services Architecture

  8. Requestor & Provider combined

  9. From Monday: Faults With XML-RPC HTTP/1.1 200 OK Connection: close Content-Length: 426 Content-Type: text/xml Date: Fri, 17 Jul 1998 19:55:02 GMT Server: UserLand Frontier/5.1.2-WinNT <?xml version="1.0"?> <methodResponse> <fault> <value> <struct> <member> <name>faultCode</name> <value><int>4</int></value> </member> <member> <name>faultString</name> <value><string>Too many parameters.</string></value> </member> </struct> </value> </fault> </methodResponse>

  10. From Monday:UDDI, Metatags & the Yahoo/Google Metaphor • Metaphor: “UDDI is to web services like Yahoo or Google is to the traditional web” • Q: “Do you use meta tags for web services like you do with Google and Yahoo?” • A: “No. UDDI is structured data. They aren’t needed. Search engines need them because web pages aren’t structured.” • Better Metaphor: “UDDI is like a phone book. UDDI is somewhat like Yahoo.”

  11. Web Services Interoperability • Web Services is interoperable because it is rooted in text (XML) and is independent of a particular transport (http, smtp, etc.) • However… the different components of web services may have interoperability problems • Similar to the Browser Wars of the mid ’90’s – standards exist, but product-specific implementations and additional features vary

  12. Web Services Interoperability • Web Services World is much more complex than the web • The main point of fragmentation for the Browser Wars was the browser • For Web Services, there are (and will be) many tools – people won’t parse SOAP messages directly • More tools, more points of fragmentation, more interoperability problems • No one makes money selling commodity software • Innovative open source developers will move faster than standards

  13. WS-I • Web Services Interoperability (WS-I) Organization: Industry group that promotes interoperability • WS-I Basic Profile 1.0: • SOAP 1.1 • WSDL 1.1 • Must use HTTP binding, should use HTTP 1.1 • XML Schema Part 1, Part 2 • May use HTTPS • Similar to the J2EE certification program

  14. Interoperability – bottom line • Over time, software will be talking to software more and more over the Internet • Software will have to be more and more interoperable • It’s doubtful that a single web app development platform (i.e., J2EE vs. NET vs. LAMP) will monopolize • The big bosses don’t want to hear about the J2EE vs. .NET vs. LAMP • Over time, web services is best positioned to solve interoperability problems

  15. Developers’ Burden… • It’s the software developers’ burden…. • to ensure interoperability by the tools, patterns and strategies they • Scrutinize tools & middleware from an interoperability perspective

  16. Examples • JAXP • DOM • SAAJ • JAXB • JAX-RPC

  17. Building DOM Document public static Document buildDom() { DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); try { DocumentBuilder builder = factory.newDocumentBuilder(); return builder.newDocument(); } catch (ParserConfigurationException pce) { // Parser with specified options can't be built pce.printStackTrace(); } catch (IOException ioe) { ... } }

  18. Adding Elements document = builder.newDocument(); // Create from whole cloth Element root = (Element) document.createElement("rootElement"); document.appendChild(root); root.appendChild(document.createTextNode(“Text") ); root.setAttribute(“name”,”value”);

  19. Loading DOM Documents DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); try { DocumentBuilder builder = factory.newDocumentBuilder(); document = builder.parse( new File(“doc.xml”) ); } catch (SAXParseException spe) { … }

  20. Reading DOM Documents • Example: jwsdp/jaxp/samples/DOMEcho/DOMEcho.java

  21. Reading SAX Documents • Example: jwsdp/jaxp/sax/samples/Echo4.java

  22. SAAJ • SOAP with Attachments API for Java (SAAJ) • Simple overlay for creating and consuming SOAP messages • On the requestor side, it abstracts the transport interface • Higher level standards (JAX-RPC, JAXM) use it

  23. Web Services Provider MessageFactory messageFactory = MessageFactory.newInstance(); // Create a message SOAPMessage message = messageFactory.createMessage(); // Get the SOAP header from the message and remove it SOAPHeader header = message.getSOAPHeader(); header.detachNode(); // Get the SOAP body from the message SOAPBody body = message.getSOAPBody(); // Add the DOM document to the message body SOAPBodyElement docElement = body.addDocument(doc); message.saveChanges(); message.writeTo(out);

  24. WebServicesRequestor SOAPMessage message = getSOAPMessage(); // The requestor constructs the message SOAPConnectionFactory sCFactory = SOAPConnectionFactory.newInstance(); SOAPConnection conn = sCFactory.createConnection(); SOAPMessage response = conn.call(message,new URL("http://localhost:8080/servlets-examples/servlet/servlets.WebServicesProvider")); response.writeTo(System.out);

  25. Marshalling And Unmarshalling Objects • Often, a requestor serializes an object to XML • The provider generates an object of the same type from the XML • The marshalling & unmarshalling code is pretty mechanical • JAXB provides a mechanism to bind Java objects to XML schemas • Marshalling & unmarshalling is transparent

  26. JAXB Binding Process

  27. Unmarshalling An Object JAXBContext jc = JAXBContext.newInstance( "com.acme.foo:com.acme.bar" ); Unmarshaller u = jc.createUnmarshaller(); FooObject fooObj = (FooObject)u.unmarshal( new URL(“http://mdthomas.org/fooObject.xml“) );

  28. Unmarshalling From SOAP PayrollObject getPayroll(SOAPBody soapBody) { PayrollObject payroll = null; try { JAXBContext jc = JAXBContext.newInstance( "com.acme.foo" ); Unmarshaller u = jc.createUnmarshaller(); Iterator children = soapBody.getChildElements(“Payroll”); payrollNode = (Node) children.next(); PayrollObject payroll = u.unmarshal( payrollNode ); } catch (Exception e) { //handle } return payroll; }

  29. Validation PayrollObject getPayroll(SOAPBody soapBody) { PayrollObject payroll = null; try { JAXBContext jc = JAXBContext.newInstance( "com.acme.foo" ); Unmarshaller u = jc.createUnmarshaller(); u.setValidating(true); Iterator children = soapBody.getChildElements(“Payroll”); payrollNode = (Node) children.next(); PayrollObject payroll = u.unmarshal( payrollNode ); } catch (Exception e) { //handle } return payroll; }

  30. Marshaller public class WebServicesProvider extends HttpServlet { public void service (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { OutputStream out = response.getOutputStream(); JAXBContext jc = JAXBContext.newInstance( "com.acme.foo" ); PayrollObject payroll = goGetThePayrollObject(); Marshaller m = jc.createMarshaller(); m.marshal( payroll, out); out.close(); } }

  31. JAX-RPC • JAX-RPC gives you end-to-end remote procedure calls • Hides the details we’ve been discussing thus far

  32. Writing An Interface package helloservice; import java.rmi.Remote; import java.rmi.RemoteException; public interface HelloIF extends Remote { public String sayHello(String s) throws RemoteException; }

  33. Writing The Implementation package helloservice; public class HelloImpl implements HelloIF { public String message ="Hello"; public String sayHello(String s) { return message + s; } }

  34. jaxrpc-ri.xml file <?xml version="1.0" encoding="UTF-8"?> <webServices xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/dd" version="1.0" targetNamespaceBase="urn:Foo" typeNamespaceBase="urn:Foo" urlPatternBase="/ws"> <endpoint name="MyHello" displayName="HelloWorld Service" description="A simple web service" interface="helloservice.HelloIF" model="/WEB-INF/model.gz" implementation="hello.HelloImpl"/> <endpointMapping endpointName="MyHello" urlPattern="/hello"/> </webServices>

  35. Jaxrpc-ri.xml • Auto-generated • Not part of spec

  36. Generated WSDL • (View online)

  37. A Simple Static Client • The JAX-RPC client invokes the JAX-RPC service from the command line • jwstutorial13/examples/jaxrpc/staticstub/src/

  38. Dynamic Clients • Dynamic Proxy Client – underlying stub class is generated at runtime • /jwstutorial13/examples/jaxrpc/dynamicproxy/ • Dynamic Interface Invocation – signature of remote method isn’t known until runtime • jwstutorial13/examples/jaxrpc/dii/src/

  39. JAX-RPC • Document-style vs. RPC-style generally refers to how a message is encoded • JAX-RPC allows you to do complex types which are based on XML Schema • If an XML element isn’t bound to an object, it shows up as a SOAPElement

  40. JAXM • Like JAX-RPC, JAXM is an API that abstracts away underlying mechanisms of web services • JAXM is more of an API around SOAP (and SAAJ) that • With JAX-RPC, you never have to deal with SOAP if you don’t want to • JAX-RPC is part of J2EE 1.4, JAXM isn’t

  41. Web Service C# <%@ WebService Language="C#" Class="Hello" %> using System.Web.Services; [WebService(Namespace="urn:Hello")] public class Hello { [ WebMethod ] public string sayHello(string name) { return "Hello " + name; } }

  42. Security & Web Services • HTTPS solves wireline security • Authentication is another part of security • If you are bound to HTTP, you can use HTTP security and authentication… • HTTP is only point-to-point, not end-to-end • WS-Security is end-to-end, SOAP based and transport independent • Difficult use cases: federated web services

  43. Transactions & Orchestration • We’ve focused on the idea of one provider, one requestor • How about many requestors and many providers? • The orchestration and transaction efforts are about interoperability between different loosely coupled web services systems • E.g., Doing two-phase commit across loosely coupled web services (WS-Transaction) • Orchestrating true business processes out of loosely coupled web services (BPEL)

  44. Final Thoughts • Focus on interoperability • Remember the Browser Wars: test your code in foreign environments (.NET vs. J2EE) • Be wary of the RPC metaphor • Remote Procedure Calls are slow and are not the same as local calls • RPC for Web Services has been observed to be an order of magnitude slower (SOAP vs. RMI)

More Related