1 / 38

B2B Application Integration Using Web Services

B2B Application Integration Using Web Services. Nagarjuna Nagulapati Under the guidance of Dr. Daniel Andresen (Major Professor) Dr. Torben Amtoft Dr. William J. Hankley. Outline. Problem Statement Solution Application Integration Technologies B2B Application Integration & Web Services

vernon-santiago
Download Presentation

B2B Application Integration Using 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. B2B Application Integration Using Web Services Nagarjuna NagulapatiUnder the guidance of Dr. Daniel Andresen (Major Professor)Dr. Torben AmtoftDr. William J. Hankley

  2. Outline • Problem Statement • Solution • Application Integration Technologies • B2B Application Integration & Web Services • SOAP • SOAP Style & Encoding • Implementation • Performance Evaluation

  3. Problem Statement • Market Globalization • Need to stay ahead of competitors • Solutions from multiple vendors • Unable to share information and isolated functionality

  4. Solution • Application Integration(AI) • Application integration is the real-time controlled sharing of data and business processes among any connected applications and data sources within inter and intra organizations.

  5. Advantages • Increased productivity • Controlled procurement processes • Interoperability with partners • Reuse of existing systems

  6. Types of AI • Enterprise Application Integration • Integrating applications within an enterprise • EDI – based on ANSI standards • Point-to-point integration • B2B Application Integration • Integrating applications across enterprises • Middlewares – facilitate communication between two or more software systems • Point-to-point NOT feasible

  7. Why Web Services? • Java Middleware Technologies • RMI, JMS - Language dependent • Distributed objects • CORBA, DCOM - Platform dependent • Message Brokers • Require sweeping changes in participating applications and hence expensive • Open standards, platform and language independent, loosely-coupled integration

  8. B2B AI and Web Services • Organizations favoring open standard protocols • XML becoming lingua franca for data formatting and interpretation • Web Services are XML-based middleware built on open standards

  9. Web Services • Web services are middleware components that implement business logic via services and expose these services programmatically over the web, which could be invoked by service clients using SOAP over HTTP • Based on open standards like UDDI, WSDL, SOAP, XML, HTTP • Separation of specification from implementation

  10. Web Services Stack • Transport protocol – HTTP, SMTP • Data encoding – XML • Standard Message Structure – SOAP • Service Description – WSDL • Service Discovery - UDDI

  11. Web Services Framework Points to service UDDI WSDL description Describes service Publishes service Finds service Web Service Client SOAP HTTP proxy

  12. SOAP • Simple Object Access Protocol, a lightweight, message-based protocol built on XML and standard Internet protocols, such as HTTP and SMTP for information exchange in a decentralized environment • Defines specification for message structure and data encoding • Facilitates structured and typed messages to be exchanged

  13. SOAP • SOAP message must contain a SOAP envelope, a SOAP body and optional SOAP header • Encoding - serialization of data inside a SOAP message • SOAP encoding is based on XML Schemas and relies on the XML Schema data types, namespace and the type attribute

  14. SOAP <soap:envelope> <soap:header> ………………… </soap:header> <soap:body> <add> <num1 xsi:type="xsd:int">5</num1> <num2 xsi:type="xsd:int">10</num2> </add> </soap:body> </soap:envelope> SOAP header Sequence numbers, authentication credentials SOAP envelope SOAP payload Container to hold the SOAP message Method calls, parameters, Application-specific data

  15. WSDL • Describes Web Service methods to heterogeneous clients in a platform and language independent manner • SOAP toolkits generate proxy classes using WSDL • Service contract which specifies the methods available and type information needed to properly compose SOAP requests

  16. WSDLpublic int add(int num1, int num2) <?xml version="1.0" encoding="utf8" ?> <definitions> <types/> <message name="addSoapIn"> <partname="num1" type="s:int" /> <partname="num2" type="s:int" /> </message> <message name="addSoapOut"> <partname="addResult" type="s:int" /> </message> <portType name="sampleSoap"> <operation name="add"> <inputmessage="tns:addSoapIn" /> <outputmessage="tns:addSoapOut" /> </operation> </portType> <binding name="sampleSoap" type="tns:sampleSoap"> <soap:bindingtransport="http://schemas.xmlsoap.org/soap/http" style="rpc" /> <operation name="add"> <soap:operationsoapAction="http://tempuri.org/add" style="rpc" /> <input> <soap:bodyuse="encoded" namespace="http://tempuri.org/" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> </input> <output> <soap:bodyuse="encoded" namespace="http://tempuri.org/" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> </output> </operation> </binding> <service name=“Sample"> <port name="sampleSoap" binding="tns:sampleSoap"> <soap:addresslocation="http://agena.cis.ksu.edu:8080/axis/services/Sample" /> </port> </service> </definitions> Describes custom or complex Data types Number and type of input and output parameters Methods available along with input and output messages Describes style and encoding of the SOAP messagesfor each operation Describes entry points to web serviceHTTP-POST, HTTP-GET, SOAP

  17. Implementation • Web Services feasibility in integrating heterogeneous applications • B2B application modeling online trading system’s supply chain management • Web Services integrate the business processes of participating applications in a real-time fashion

  18. System Architecture Publisher(.NET) Web Service SOAP OVER HTTP Purchaser(.NET) VENDOR(J2EE) Web Service Web Service

  19. Technologies used • ASP.NET, ADO.NET, C# • ASP.NET WebMethod Framework • J2EE 1.3.1, EJB • AXIS 1.1 Framework • JBOSS 3.2.1 • XDoclet • IIS 5.0 • Microsoft ACT

  20. Message Flow Purchaser Vendor Publisher orderAvailability() Delegates request to EJBwhich processes the request orderAvailabilityResponse confirmRequest() orderInvoice Inserts order into database invoiceConfirmation orderInvoice

  21. Detailed System Architecture Publisher (.NET) IIS Server Database Unmarshalls SOAP message tonative .NET method calls .NET web service JBOSS Application Server IIS Server Business tier J2EE web service SOAP/HTTP Database proxy EJB Purchaser (.NET) Vendor (J2EE) EJB .NET web service Unmarshalls SOAP message to native Java method calls Marshalls native .NET method calls to XML

  22. Class Diagram RPC-Style ~1200 LOC Document-Style ~1350 LOC Publisher Module 2 classes Web Services Purchaser Module12 classes Vendor Module 8 classes

  23. SOAP processing in .NET IIS SERVER ASP.NET Web Service Handler HTTP Handler ASP.NET Engine Service Object SOAP Request XmlSerializer SOAP Response HTTP modules

  24. SOAP processing in AXIS JBOSS APPLICATION SERVER JETTY WEB SERVER SOAP MESSAGE PROCESSOR WS CONTAINER EJB’S HTTP Handler Handlers SERVICE provider SOAP Request SOAP Response Serialization Framework Web service Handlers Axis engine

  25. Demo

  26. SOAP style & encoding • RPC/Encoded • One-to-one mapping between SOAP payload elements and service method • Encoding is based on Section 5, SOAP specification • SOAP framework handles (de)serializing of method calls to/from XML • Application developer deals with native objects

  27. SOAP style & encoding • Document/Literal • No one-to-one mapping between SOAP payload and service method • SOAP payload can contain arbitrary XML • Encoding is based on the XML schema agreed upon by both parties • Application developer deals with raw SOAP payload

  28. RPC (Vs) Document-style • public int add(int num1, int num2) <soapenv:body> <ns:add> <num1 xsi:type=“xsd:int”>10</num1> <num2 xsi:type=“xsd:int”>8</num2> </ns:add> </soapenv:body> --------------------------------------------------------------------------------------- • public Document add(Document operation) <soapenv:body> <ns:operation> <add>10</add> <add>8</add> <multiply>1</multiply> <multiply>2</multiply> </ns:operation> </soapenv:body> Method name parameter parameter Arbitrary XML

  29. Performance Evaluation • SOAP payload (Vs) Processing time ASPWEB Windows Box Dual processor 292 MHz, 512MB Agena Solaris Box 360 MHz, 128MB

  30. Performance Evaluation • SOAP payload (Vs) Requests/Sec

  31. Results analysis • Results • RPC/Encoded solution performed better than Document/Literal solution • Theoretically Document/Literal should perform better • Analysis • Implementation was limited to simple data types in RPC/Encoded • Document/Literal solutions perform better for complex data types • Axis serialization (vs) Custom serialization • SAX (Vs) DOM

  32. Lessons learned • Service-oriented application development in both .NET and J2EE • Better understanding of SOAP protocol, message structure, encoding and SOAP message processing in .NET and Apache AXIS frameworks • Application integration technologies currently being used in enterprises and how they work.

  33. Implementation issues • Insufficient reference resources on the Document-styled Web services • Interoperability between .NET and J2EE technologies still in its nascent stages • Working simultaneously with both .NET based API’s and Java based API’s

  34. Conclusion • SOAP is text-based, Web Service calls may be too slow for applications that require frequent and fast communications • Web Services are not suitable for applications which need to access wide variety of objects and classes

  35. Future work • Security is utmost concern • Authentication credentials in SOAP headers • User/Passwd, Security tokens and SSL • Encoded NOT encrypted • Consortia and organizations working towards the interoperability and security of Web Services : WS-I & WS-Security

  36. References • www.msdn.com • http://ws.apache.org/axis • http://java.sun.com/blueprints/webservices/using/webservbp3.html • http://nagoya.apache.org/wiki/apachewiki.cgi?AxisProjectPages/DotNetInterop • http://www.gotdotnet.com/team/XMLwebservices/gxa_overview.aspx • http://www.aei.on.ca/index.php/aei/notes/edi • http://ecommerce.about.com/cs/b2bresources/a/aa080108a.htm • http://www.topxml.com/b2b/articles/ts4b2b/default.asp • http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/eappint-ch01.asp • http://www.darc.com/software/2ndLevelArt/News/Application_Integration_for_E-Business.pdf • http://www-900.ibm.com/developerWorks/cn/xml/developerConf/ • http://www-106.ibm.com/developerworks/webservices/library/ws-whichwsdl/ • http://www.jboss.org/index.html?module=bb • www.msdn.com/newsgroups

  37. Acknowledgements • Dr. Daniel Andresen • Dr. Torben Amtoft • Dr. William J. Hankley • Sterling Hanenkamp • Travis Bradshaw

  38. Questions?

More Related