1 / 26

Understanding SOAP Web Services: Protocols and Applications

SOAP (Simple Object Access Protocol) is a powerful protocol designed for remote object calls, developed by major companies like Microsoft and IBM. It standardizes communication through XML encoding and utilizes HTTP for transferability across firewalls, making it particularly useful for internet applications. SOAP supports both synchronous and asynchronous calls and integrates security mechanisms like XML Encryption. It operates independently of programming languages, facilitating its use in diverse environments. This overview covers its architecture, key elements, and practical examples, highlighting its significance in web services.

quasar
Télécharger la présentation

Understanding SOAP Web Services: Protocols and Applications

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. WebServices, Application Servers and further concepts

  2. SOAP (Simple Object Access Protocol) • Protocol for remote object calls • Developed by Microsoft, IBM, Lotus and other partners; Standardization through IETF (Internet Engineering Task Force) • Encoding of calls and parameters via XML (eXtensible Markup Language) • Realization with HTTP, therefore transferable via Firewalls; especially useful for Internet (in Intranet there is no Firewall-Problem !) • new security mechanisms are also usable, based on XML (XML Encryption; XML Signature)

  3. SOAP • independence of special programming languages, however usable with mappings of Java, C++ etc. • Because of embedding in HTTP, SOAP is less efficient than direct communication with RMI / IIOP / .NET • no reference parameters, no automatic garbage collection (goal: limitation to a minimal functionality) • Usable for synchronous calls to objects, but also asynchronous interactions are supported (e.g. Message Passing)

  4. SOAP: example (method call) • POST /BankServer HTTP/ • Host: www.bank.com • Content-Type: text/xml • Content-Length: nnnn • SOAPMethodNeme: Some-Namespace-URI#getBalance • <SOAP: Envelope xmlns: SOAP=“urn:schemas-xmlsoap-org:soap“> • <SOAP: Header> • <t: Transaction xmlns: t=“some-URI“ SOAP: mustUnderstand=“1“> • 328 • </t: Transaction> • </SOAP:Header> • <SOAP: Body> • <m: getBalance “xmlns: m=“Some-Namespace-URI“> • <AccountIdentification> • <AccountNumber>3044005</AccountNumber> • <pin>****</pin> • <name>John Smith</name> • </AccountIdentification> • </m: getBalance> • </SOAP: Body> • </SOAP: Envelope>

  5. SOAP: example (answer of server) • HTTP 200 ok • Connection: close • Content-Type: text/xml • Content-Length: nnnn • <SOAP: Envelope xmlns: SOAP= “urn: schemas-xmlsoap-org: soap“> • <SOAP: Body> • <m:getBalance xmlns: m= “Some-Namespace-URI/ “> • <return> -1350.50 </return> • </m: getBalance> • </SOAP: Body> • </SOAP: Envelope>

  6. SOAP: encoding structure • embedding in HTTP POST Requests and accompanying responses • Envelope: definition of logical names and possible specification of own encoding rules for parameter types • Header: transfer of implicit control parameters (remark: „transaction“ in this context means only request/response-interaction) • Body: real encoding of call and parameters

  7. SOAP: data type definition (example) • <element name= “AccountIdentification“> • <complexType> • <element name= “accountNumber“ type=“xsd:int“/> • <element name= “pin“ type=“xsd:int“/> • <element name= “name“ type=“xsd:string“/> • </complexType> • </element> • also all other essential data types specifiable (e.g. (variable) arrays, enumerations etc.) • Possibility of representation of data types of common programming languages

  8. WebServices • manufacturer-independent initiative for Web-based services • base: standardized protocols (e.g. SOAP / XML) and middleware-platforms (Application Server) • definition: „encapsulated, loosely coupled functions, which are accessible over standard protocols“ • Interface description using WSDL (WebServices Description Language) • binding of services over UDDI (Universal Description, Discovery and Integration); comparable with Directory Service;http://www.uddi.org

  9. WebServices • security architecture WS (WebServices)-Security: in addition to SOAP for digital signatures (PKI – Public Key Infrastructure) and encoding • also extension of firewalls for functions of checking authentication and authorization of SOAP-communication via „http“ („Port 80“) • altogether: framework for description of network-wide services , which is specialized by manufacturers by system solutions, among others IBM, Microsoft, Sun, BEA Systems etc. • standardization through W3C andWeb Services Interoperability Organization

  10. WebServices Business Application (e.g. on the base of EJB, further distributed internally) UDDI Registry WSDL Description Discovery Web Services Container / Runtime Web Services Client SOAP Firewall

  11. WSDL (WebServices Description Language) • example (shortened): • <binding name=“BankServer“ type=“tns:BankServerPortType“> • <soap:binding style = “rpc“ transport = “http://... “/> • <operation name = “getBalance“> • <soap:operation soapAction = “urn:xmethodsBankServer“/> • <input> ... </input> • <output> ... </output> • </operation> • </binding> • Call modes: oneway ; request-response (Client/Server) • notification ; solicit-response (Server/Client)

  12. WebServices: possible use phases • Closed application fields : e.g. automation of office processes incl. legacy-integration • “Selective Outsourcing”: access to services of external partners • with close contractual relationship • “Dynamic Business-Web”: Interaction of many loosely coupled systems; e.g. between manufacturers and suppliers • “Agile company”: comprehensive integration, also with customer - and partner enterprises

  13. WebServices: Summary • comfortable, web-based call mechanism • also applicable via firewalls using SOAP / HTTP • possibility of automatic generation of interface descriptions from design representations through tools • but: no replacement of EJB or .NET, but access technology from client to server, especially over Internet

  14. Message Oriented Middleware • Products : IBM MQ Series, BEA MessageQ, Tibco etc. • Base: Messages, Queues with Queue Manager • Dynamic coupling between application and local Queues based on logon / logout • Use of Queues for sending or receiving; also mixed use is possible • Coupling of distributed Queue Managers via Message Channels • C++-and Java-Support (conformant to JMS) • use of XML (eXtensible Markup Language) for description of transferred contents • support of essential OS-platforms

  15. Example scenario PC A PC B Queue Manager Queue Manager MQPUT MQGET Appli-cation 1 Queue Manager Queue Manager appli-cation 2 MessageChannel MQPUT MQGET • decoupling of applications through Queue Manager: • Message forwarding is possible even if application isn’t running

  16. N:M - communication Load balancing (selective delivery) or Parallel processing (replicated delivery) Access to Servervia multiple Clients C A D B Queue, with optional support of message priorities E

  17. Message Queuing: Assessment • Advantages • + simple manageability • + robust message delivery • + flexible application fields (for instance load balancing, parallelization, batch-transmission of branch data etc.) • + relevant for easy coupling of programs, for instance via Internet, or for Mobile Computing • Disadvantages • - limited communication semantics • - interaction model is different than with procedures/method invocations • - limited accessibility of higher services • - only several proprietary solutions up to now, only step-by-step standardization

  18. Application Servers • interface-server between Web/Java-Client and services of enterprise data processing („middle-tier“) • Tasks: • data- and call adaptation • legacy-integration; transactions • access control • load sharing

  19. Architecture Web-Server HTML-Dokumente HTML-Dokumente HTML-Documents HTML-Dokumente HTML-Dokumente CGI-Scripts (optional) Java RMI, Internet Inter-ORB Protocol, SOAP Application-Server Transaction-Monitors proprietaryProtocols HTTP Java- Client Businesssoftware proprietaryProtocols Inner Firewall outer Firewall Mainframe-applications proprietaryProtocols HTML-Client HTTP Stateful-connection Data bases Stateless-connection

  20. Development cycle Generation Instantiation requests CORBA, EJB Container, .NET CORBA / EJB / .NET UML (Unified Modeling Language) component development Installation / Deployment user layout / modeling runtime/ component use

  21. Modeling and Generation UML layout / modeling <?xml version="... "? <component name="Bank"> <interface name="Bank"> Generation Component description • XML (eXtensible Markup Language) as intermediate representation: • Standardization, Portability • Formalization (DTD - Document Type Definition or XML schema) • tool support CORBA / EJB / .NET component development

  22. Interface description in XML („XMI“) • <interface name="Bank"> • <superclass> General </superclass> • <operation name="TransferRequest"> • <visibility> public </visibility> • <returnType> long </returnType> • <oneway> false </oneway> • </operation> • <attribute name="Description"> • <type> string </type> • <visibility> public </visibility> • <isReadonly> true </isReadonly> • </attribute> • </interface>

  23. Application Servers • Essential functionality: • Development and distribution of Java applications (“Three-Tier”) • scalability (>100 Server, >10000 Clients): Multithreading, connection reuse etc. • Component model (Enterprise JavaBeans, .NET etc.) • Support of transactions • Access to distributed data bases (Oracle, MS SQL Server, Sybase, DB2) • security (Authentication, access control) • Support of actual Java APIs (JDBC, JNDI, JMS etc.) • Replication and load sharing • Integration of development environment (e.g. IBM Websphere Studio, Borland JBuilder, BEA Weblogic Workshop, MS Visual J++ / J#, C#, Rational Rose, Arcstyler etc.) • Support of WWW-services (e.g. installation of HTML, Servlets etc.)

  24. Enterprise Application Integration (EAI) • Goal: • Integration of different applications (Backend) • examples:- Enterprise Resource Planning (ERP)- Customer Relationship Management (CRM)- Supply Chain Management (SCM) • Technological Base: • Middleware and Application Servers (e.g. of IBM, BEA, Forte etc.) • Additional product specific adapters • Integration approaches: • Data integration • Interface based integration (API-Integration) • Workflow- / Process-oriented integration (complex processes with more than 5 applications)

  25. Enterprise Application Integration • Products: • - BEA Systems eLink - adapter for SAP R/3 Integration • - Delta Software Technology, Vienna: SCORE/ Integration Suite • - WRQ VeraStream EAI Suite: SAP R/3 Integration • - Sybase Integration Services: SAP, Peoplesoft, Oracle (ERP) Siebel, Vantive (CRM)

  26. Application Servers: Product examples • BEA Weblogic • IBM Websphere • Borland Application Server • IONA Orbix • Oracle Application Server / .Now • Sybase Enterprise Application Server • Sun: Open Net Environment (One) / iPlanet • Software AG EntireX • Microsoft .NET • Open Source, among others: • Enhydra • Jonas • Jboss • Zope etc.

More Related