SOAP

SOAP category
Mirjana's picture

WS - SOAP Response Validation

Submitted by Mirjana on Mon, 09/24/2012 - 01:14

SOAP Response – validation against XML schema

1.    SOAP Response should be:

<bookstore>
          <book>
                    <title>Harry Potter</title>
                    <author>J K. Rowling</author>
                    <year>2005</year>
                    <price>29.99</price>
          </book>
          <book>
                    <title>Learning XML</title>
                    <author>Erik T. Ray</author>
                    <year>2003</year>
                    <price>39.95</price>
          </book>
</bookstore>
  • Here is one similar XML with namespaces:
<m:bookstore xmlns:m="http://www.webservice.pull_fileOut">
          <m:book>
                    <m:title>Harry Potter</m:title>
                    <m:author>J K. Rowling</m:author>
                    <m:year>2005</m:year>
                    <m:price>29.99</m:price>
          </m:book>
          <m:book>
                    <m:title>Learning XML</m:title>
                    <m:author>Erik T. Ray</m:author>
                    <m:year>2003</m:year>
                    <m:price>39.95</m:price>
          </m:book>
</m:bookstore>
 
2.    XML Schema that describes this response is:
 
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:m="http://www.webservice.pull_fileOut" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.webservice.pull_fileOut" elementFormDefault="qualified" attributeFormDefault="unqualified">
          <xs:element name="bookstore">
                    <xs:complexType>
                              <xs:sequence>
                                        <xs:element ref="m:book" maxOccurs="unbounded"/>
                              </xs:sequence>
                    </xs:complexType>
          </xs:element>
          <xs:element name="book">
                    <xs:complexType>
                              <xs:sequence>
                                        <xs:element ref="m:title"/>
                                        <xs:element ref="m:author"/>
                                        <xs:element ref="m:year"/>
                                        <xs:element ref="m:price"/>
                              </xs:sequence>
                    </xs:complexType>
          </xs:element>
          <xs:element name="title">
                    <xs:simpleType>
                              <xs:restriction base="xs:string"/>
                    </xs:simpleType>
          </xs:element>
          <xs:element name="author">
                    <xs:simpleType>
                              <xs:restriction base="xs:string"/>
                    </xs:simpleType>
          </xs:element>
          <xs:element name="year">
                    <xs:simpleType>
                              <xs:restriction base="xs:string"/>
                    </xs:simpleType>
          </xs:element>
          <xs:element name="price">
                    <xs:simpleType>
                              <xs:restriction base="xs:string"/>
                    </xs:simpleType>
          </xs:element>
</xs:schema>

 3.    Namespace added in namespace.properties file

m = http://www.webservice.pull_fileOut

4.    Process Data with response prepared for returning back to client:

.....
.....
<WebservicesResponseNode>
    <m:bookstore xmlns:m="http://www.webservice.pull_fileOut">
      <m:book>
        <m:title>Harry Potter</m:title>
        <m:author>J K. Rowling</m:author>
        <m:year>2005</m:year>
        <m:price>29.99</m:price>
      </m:book>
      <m:book>
        <m:title>Learning XML</m:title>
        <m:author>Erik T. Ray</m:author>
        <m:year>2003</m:year>
        <m:price>39.95</m:price>
      </m:book>
    </m:bookstore>
  </WebservicesResponseNode>
</ProcessData>

5.    SOAP Response

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          <soapenv:Body>
                    <m:bookstore xmlns:m="http://www.webservice.pull_fileOut">
                              <m:book>
                                        <m:title>Harry Potter</m:title>
                                        <m:author>J K. Rowling</m:author>
                                        <m:year>2005</m:year>
                                        <m:price>29.99</m:price>
                              </m:book>
                              <m:book>
                                        <m:title>Learning XML</m:title>
                                        <m:author>Erik T. Ray</m:author>
                                        <m:year>2003</m:year>
                                        <m:price>39.95</m:price>
                              </m:book>
                    </m:bookstore>
          </soapenv:Body>
</soapenv:Envelope>
Mirjana's picture

SOAP message, SOAP request - response

Submitted by Mirjana on Thu, 02/17/2011 - 07:26
SOAP stands for 'Simple Object Access Protocol'. The acronym is sometimes confused with SOA or Service-oriented architecture, however SOAP is quite different from SOA.
 
SOAP is an XML-based messaging protocol. It defines a set of rules for structuring messages that can be used for simple one-way messaging but is particularly useful for performing RPC-style (Remote Procedure Call) request-response dialogues. It is not tied to any particular transport protocol though HTTP is popular. Nor is it tied to any particular operating system or programming language so theoretically the clients and servers in these dialogues can be running on any platform and written in any language as long as they can formulate and understand SOAP messages. As such it is an important building block for developing distributed applications that exploit functionality published as services over an intranet or the internet.
 
Both SMTP and HTTP are valid application layer protocols used as Transport for SOAP, but HTTP has gained wider acceptance as it works well with today's Internet infrastructure; specifically, HTTP works well with network firewalls. SOAP may also be used over HTTPS (which is the same protocol as HTTP at the application level, but uses an encrypted transport protocol underneath) with either simple or mutual authentication, this is the advocated WS-I method to provide web service security as stated in the WS-I Basic Profile.
 
Simple Object Access Protocol provides an XML-based framework for exchanging structured and typed information between peer services. This information, formatted into Header and Body, can theoretically be transmitted over anumber of transport protocols.
 
SOAP is an extensible, text-based framework for enabling communication between diverse parties, in general, objects that have no prior knowledge of each other or of each other's platforms. From the point of view of objects on the net, SOAP is the ultimate blind date.
SOAP is extensible, because SOAP clients, servers and the protocol itself can evolve without breaking existing apps.
 
Network Tiers in Web Services
 
Three network tiers are evident in the evolution of Web services: TCP/IP, HTTP/HTML, and XML. These tiers build successively on top of each other and remain compatible today.
 
  • The first tier, the TCP/IP protocol, is concerned primarily with passing data across the wire in packets. A protocol that guarantees transmission across public networks, TCP/IP emphasizes reliability of data transport and physical connectivity
  • The second tier, HTML over HTTP, is a presentation tier and concerns itself with browser-based search, retrieval and sharing of information. The emphasis here is on GUI-based navigation and the manipulation of presentation formats. In many ways, HTML is more show than go and lacks both extensibility and true programming power. Nonetheless, sharing hypertext-linked documents in a browser-based environment revolutionized the way humans communicate text-based information to one another. Networked desktop environments, burdened with proprietary operating systems and platform dependent software, are slowly but surely giving way to the standards-based, open-systems computing of the Internet.
  •  Leading the charge into this brave new standards-based world is XML, the third and possibly the most compelling tier on the Internet. XML, a strongly-typed data interchange format, provides a new dimension to the HTTP/HTML tier, one in which machine-to-machine communication is made possible through standard interfaces. This layer, variously described as A2A (application to application), B2B (business to business) or C2C (computer to computer), allows programs to exchange data formatted in a platform- and presentation-independent manner. XSLT style sheets may be added as an optional presentation and/or transformational component.
 
 
  • UDDI is used to register and discover Web services
  • Web Services are typically described in WSDL
  • application uses SOAP to request the Web service
  • SOAP messages are actually delivered by HTTP and TCP/IP
 
SOAP Clients and Servers
 
A SOAP client is a program that creates an XML document containing the information needed to invoke remotely a method in a distributed system. SOAP clients need not be traditional, a SOAP client could also be a Web server or a server-based application.
Messages and requests from SOAP clients are typically sent over HTTP. As a result, SOAP documents are able to traverse almost any firewall, enabling the exchange of information across different platforms.
A SOAP server is simply special code that listens for SOAP messages and acts as a distributor and interpreter of SOAP documents. External Web services may interact with application servers based on J2EE technology, which process SOAP requests from a variety of clients.
SOAP servers ensure that documents received over a HTTP connection are converted to a language that the object at the other end understands. Because all communications are made in the form of XML, objects in one language (say, Java) may communicate through SOAP with objects in any other language (C++, for example). It's the job of the SOAP server to make sure the end points understand -- and are happy with -- the SOAP they're being served.
 
SOAP Message Format
 
SOAP does all this in the context of a standardized message format. The primary part of this message has a MIME type of "text/xml" and contains the SOAP envelope. This envelope is an XML document. The envelope contains a header (optional) and a body (mandatory). The body part of the envelope is always intended for the final recipient of the message, while the header entries may target the nodes that perform intermediate processing. Headers, for example, may be used to provide digital signatures for a request contained in the body. In this circumstance, an authentication or authorization server could process the header entry, independent of the body, stripping out information to validate the signature.
Attachments, binary or otherwise, may be appended to the body.
 
 
SOAP Envelope
 
The SOAP envelope is the top element of the XML document that represents the SOAP message. Envelope is represented by an Envelope element. The envelope can contain XML namespaces declarations that are used to disambiguate SOAP identifiers from application specific identifiers. Also envelope can contain other attributes such as encoding style.
 
  • SOAP Header
 
The header is represented by a Header element. As mentioned before, the header is optional. However, if it's included in a SOAP message, it must be the first child of the Envelope element. The header, through attributes, extends the SOAP message.
In other words, it adds information beyond what is in the body of the SOAP message.
SOAP Header also contains part for security.
 
It's important to understand that as a SOAP message travels from an originator (a client application) to a final destination (for example, an application providing a requested service), it potentially passes through a set of intermediate nodes along the path. Each node is an application that can receive and forward SOAP messages. The SOAP header can be used to indicate some additional processing at a node, that is, processing independent of the processing done at the final destination. For example, the header could be used to request that each message be logged at a particular node.
 
  • SOAP Body
 
The body, represented by a Body element, contains the "payload", that is, the information intended for the final destination. The Body element can optionally contain a Fault element that is used to hold error and status information returned by a processing node. The Body element must be an immediate child element of a SOAP Envelope element. If the envelope contains a header, the Body element must immediately follow the Header element.
 
 
SOAP Request as well as SOAP Response have the same structure explained above. Examples follows below.
 
SOAP Request Example
 
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
     
<SOAP-ENV:Header>
            <wsrm:Request>
                  <wsrm:Sequence SOAP-ENV:MustUnderstand="1">
                        <wsrm:Identifier>http://ABC</wsrm:Identifier>
                        <wsrm:MessageNumber>1</wsrm:MessageNumber>
                  </wsrm:Sequence>
            </wsrm:Request>
</SOAP-ENV:Header>
 
<SOAP-ENV:Body>
            <m:info xmlns:m="http://www.sterlingcommerce.com/schema/example/info_webservice">
                  <m:productLabel>eInvoicing_1.0</m:productLabel>
                  <m:temp>String</m:temp>
            </m:info>
            <m:mesaAuth xmlns:m="http://www.sterlingcommerce.com/mesa">
                  <m:principal>admin</m:principal>
                  <m:auth hashType="">password</m:auth>
            </m:mesaAuth>
      </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
 
SOAP Response Example
 
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     
<soapenv:Body>
            <answer>
                  <row>
                        <buildNumber>5000</buildNumber>
                        <licProdVer>5_0</licProdVer>
                        <siInstallDate>2008-11-25 12:00:03.0</siInstallDate>
                        <siComments>GIS installation</siComments>
                  </row>
            </answer>
      </soapenv:Body>
 
</soapenv:Envelope>
 

 

Mirjana's picture

SOAP protocol - Web Services

Submitted by Mirjana on Mon, 02/14/2011 - 05:17

A Web Service is defined by the W3C as "a software system designed to support interoperable machine-to-machine interaction over a network".

Web Services and Web Applications comparison

Web Services are units of code that can be called via HTTP requests in the same way that traditional websites can. The fundamental difference between them is that web services do not normally send HTML in response to a request but instead emit XML. The use of HTTP and XML gives web services advantages of platform and technology independence and allow web services to be set up to work across any intranet or even the internet.

While there are similarities between traditional Web Applications and Web Services the main function of web services is to allow a client to perform remote method calls over the HTTP protocol rather than serve HTML content to a web browser for display. While browser-based Web applications, are loosely coupled and remarkably interoperable, web services are not web based, and as they rely on industry standards, including HTTP, XML, SOAP and WSDL, to expose application functionality on the Internet, they are independent of programming language, platform and device.

While web applications typically are HTML-based, web services are XML-based. Interactive users for B2C (business to consumer) transactions normally access web applications, while web services are employed as building blocks by other web applications for forming B2B (business to business) chains using the so-called SOA model.

Web services use the HTTP transport protocol which is perhaps the most ubiquitous in the world as it is the basis of the internet! Using HTTP means that web services can be hosted within web servers and as such can be available across a company in the same way an intranet sit. But why stop at the company boundary? HTTP is the basis of the internet so why not be available to the world!

This in fact is a key application of web services as it allows Business to Business (B2B) communication

Platform, system and language independence

The HTTP protocol is the main element we have to mention in the story about Web Services, and it is explained above.

The second element of web services is XML. XML in essence is just a well formed text document that can describe data structures using simple tags. Being a text document XML is therefore totally platform and technology independent. Even if you are trying to integrate a .NET application with a Java program, though XML data exchange it becomes easy because both technologies can read text and can understand what is being passed to them from the other program.

So, the 2 key advantages of web services are:

  • Platform/Language independent – Because from the users point of view all that is exchanged is XML which is a text based data format. The machinery that creates this XML behind the scenes can be on any platform using any language. The ubiquity of the HTTP protocol makes it the ideal choice for integration
  • Firewall Friendly – Because they work over HTTP web service traffic travels through port 80 on any PC machine. This means that a System Admin does not have any additional firewall management headaches with extra ports being left open on a machine.

These advantages mean that any machine that has HTTP access to the server and properly technology that can read XML can access the Web Service and access its methods.

Web Service features

Web Services are web-based enterprise applications that:

  • interoperate between different systems
  • interoperate between different software applications
  • can expose any program, functionality, application, class, method, EJB, business object … as a service
  • running on a variety of platforms and/or frameworks
  • simple and extensible
  • use open, XML-based standards and
  • transport protocols (SMTP, HTTP, RMI, JMS, WebSphere MQ …) 

… to exchange data with calling clients running on a variety of platforms and/or frameworks.

Web Services use Extensible Markup Language (XML) messages that follow the Simple Object Access Protocol (SOAP) standard and have been popular with traditional enterprise. In such systems, there is often a machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL).

  • Web Services effectively eliminate the need for maintaining additional hardware and software
  • Web Services are available anywhere in the world an internet connection is present
  • Web Services eliminate the need to learn other organization's IT Infrastructures
  • Web Services can connect new possibilities to any part of an organization, using any language, or any operating system
  • Web Services can be implemented in hours or days compared to months using traditional implementation methods

WS resume: any program, functionality, application, class, method, EJB, any business object … can be exposed as a Web Service and contacted by WS client independently on system, platform and application (e.g. a Web Service deployed on a J2EE server can be invoked using a C++ client).

Syndicate content

Library

Main Menu

User login

Login/Register

Tell a friend

Send an e-Postcard

New forum topics

Recent Posts Recent Posts