Difference between RPC and Document Style - WebServices WSDL

RPC and document style in WSDL are the two most widely used terms in reference to Web services and SOAP protocol.

Performance wise there is no difference at all. and   below are the  differences RPC and document style

1. In document style, the SOAP message is sent as a single document whereas in the RPC style, the SOAP body may contain several elements.
2. The document style is loosely coupled whereas the RPC is tightly coupled.
3. In the document style, the client sends the service parameters in simple XML format whereas in the RPC style the parameters are sent as discrete of values.
4. The Document/Literal style loses the operation name in the SOAP message whereas the RPC/literal style keeps the operation name in the SOAP message.
5. In the Document/Literal style, messages can always be validated using any XML validator whereas in the RPC/literal style, the transferred data is difficult to validate by the SOAP message.
6. If we take the concrete WSDL for both of them and import it in the SOAP UI  then we will find the difference below

 Document style

 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sch="http://www.tibco.com/schemas/webservice/Schema.xsd">

   <soapenv:Header/>

   <soapenv:Body>

      <sch:OrderRequest>

         <sch:Name>?</sch:Name>

         <sch:Price>?</sch:Price>

      </sch:OrderRequest>

   </soapenv:Body>

</soapenv:Envelope>

 

RPC Style

 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:inp="http://InputMessageNamespace" xmlns:sch="http://www.tibco.com/schemas/webservice/Schema.xsd">

   <soapenv:Header/>

   <soapenv:Body>

      <inp:BookOrder>

         <sch:OrderRequest>

            <sch:Name>?</sch:Name>

            <sch:Price>?</sch:Price>

         </sch:OrderRequest>

      </inp:BookOrder>

   </soapenv:Body>

</soapenv:Envelope>

 

Here BookOrder is the operation name.  In RPC style as we can see after the Soap body comes the operation name and then the inputs. In document style just after the Soap body comes the inputs.

 

The use attribute also helps to distinguish between RPC and document styles.

The use attribute describes how both the styles are represented in XML. The use attribute describes whether the message parts are encoded or the message follows an XML schema definition.

Based on choices, there are four possible combinations of both RPC and document styles; viz RPC/encoded, RPC literal, Document/Encoded or Document/Literal.

 Not all of the four combinations are in use, and the preference of one combination over the other is more of a personal interest.

The main difference between document and RPC styles is that, in the document style, the client always sends the service parameters to the server in a simple XML document format rather than a discrete set of parameter values. The document style is loosely coupled as compared to the RPC style.

In the Document/Literal style, the message can always be validated using any XML validator. The content within the SOAP body is clearly defined in the schema.

In the RPC/literal style, the transferred data is difficult to validate by the SOAP message.The Document/Literal style loses the operation name in the SOAP message whereas in the RPC/literal style the operation name still exists in the SOAP message.

Out of four different combinations, the styles that are widely used are RPC/literal and Document/Literal.

  

Scenario - web services / Performance Tuning / work load

We have created web service as server (starter activity 'soap event source') process.

How many  number of  incoming HTTP requests (concurrent i.e.occurring at the same time) that can be handled by this web service  ? or  How can we define the workload for this process ?

Answer :

Workload can define by setting the following properties in bwengine.tra file:

bw.plugin.http.server.minProcessors
bw.plugin.http.server.maxProcessors

Setting maxProcessors to 100, means  upto 100 requests can be accepted concurrently.

 Engine.ThreadCount

To improve the ability to execute process instances concurrently, more engine threads are required.

The number of engine threads to be allocated can be set using the property Engine.ThreadCount. The default value is 8.

Engine.StepCount

Set the property, Engine.StepCount, to specify the maximum number of execution steps for a job, unless in a transaction or when the ActivationLimit is set. The default value is 20.

A low value of StepCount results in frequent thread switches. This is an overhead, especially when the number of execution steps for most jobs is high.

bw.plugin.http.client.ResponseThreadPool


To specify the size of the thread pool used by the Request-Reply activity on the web service client side, set the properties: 

bw.plugin.http.client.ResponseThreadPool
bw.plugin.http.client.ResponseThreadPool.type

As the thread pool is created when the engine starts, use a reasonable number to specify the size of the ResponseThreadPool for your system. A high value results in extra resources being allocated which may never be used.

What is SOAPAction ? or What it specifies ?

The SOAP Action HTTP header is defined by the SOAP specification, and it indicates the intent of the SOAP HTTP request.

SOAP Action value is completely arbitrary, and it's intended to tell the HTTP server what the SOAP message wants to do before the HTTP server decodes the XML.

 

XML Namespaces

Name Conflicts: XML Namespaces provide a method to avoid element name conflicts.

In XML, element names are defined by the developer. This often results in a conflict when trying to mix XML documents from different XML applications.

This XML carries HTML Book information (Index details):

<book>
  <index>
    <chapter>second</chapter>
    <page>thirty</page>
  </index>
</book>

This XML carries information about a Book (price details):

<book>
  <author>African Coffee Table</author>
  <price>90</price>
  <publisher>INX</publisher>
</book>

If these XML fragments were added together, there would be a name conflict. Both contain a <book> element, but the elements have different content and meaning.

An XML parser will not know how to handle these differences.

This Name Conflict can Solve by Using a Prefix

Name conflicts in XML can easily be avoided using a name prefix. This XML carries information about an HTML book, and a price details:

<x:book>
  <x:index>
    <x:chapter>second</x:chapter>
    <x:page>thirty</x:page>
  </x:index>
</x:book>

<y:book>
  <y:author>African Coffee Table</y:author>
  <y:price>90</y:price>
  <y:publisher>INX</y:publisher>
</y:book>

In the example above, there will be no conflict because the two <book> elements have different names.

XML Namespaces - The 'xmlns' Attribute

When using prefixes in XML, also-called namespace for the prefix must be defined.The namespace is defined by the xmlns attribute in the start tag of an element.
 

The namespace declaration has the following syntax. xmlns:prefix="URI".
 

<root>

<x:book xmlns:x="http://www.tibco.com/abc/dfg/">
  <x:index>
    <x:chapter>second</x:chapter>
    <x:page>thirty</x:page>
  </x:index>
</x:book>
 <y:book xmlns:y="http://www.tibcoworldin.com/test">
  <y:author>African Coffee Table</y:author>
  <y:price>90</y:price>
  <y:publisher>INX</y:publisher>
</y:book>
</root>

In the example above, the xmlns attribute in the <book> tag give the x: and y: prefixes a qualified namespace.

Default Namespaces

Defining a default namespace for an element saves us from using prefixes in all the child elements.
It has the following syntax:
 

xmlns="namespaceURI"

This XML carries HTML book information:

<book xmlns="http://www.tibco.com/abc/dfg/">
  <index>
    <chapter>second</chapter>
    <page>thirty</page>
  </index>
</book>

This XML carries information about a Book (price details):

<book xmlns ="http://www.tibcoworldin.com/test>
  <author>African Coffee Table</author>
  <price>90</price>
  <publisher>INX</publisher>
</book>

Why Web Services ?

Web Services = XML + Protocol

Web Services take web-applications to the next level. By using Web services, your application can publish its function or message to the rest of the world. By doing this other platforms can also access the web application.

So once this web application available to the rest of world, other platform can also access and also by doing this can interact with the other platforms which are already using that web.

Many of the major platforms can access the web using web browsers.

Web-applications are simply applications that run on the web. These are built around the Web browser standards and can be used by any browser on any platform.

Use of the web services are

1.Interoperability.
2.Reusable application components.
3.Open Standards XML + open Protocol based.

Components of the web services are

SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and Integration)
WSDL (Web Services Description Language)

What is SOAP ?

SOAP is an XML-based protocol to let applications exchange information over HTTP.

SOAP stands for Simple Object Access Protocol.

• SOAP is a communication protocol
• SOAP is a format for sending messages
• SOAP is designed to communicate via Internet
• SOAP is platform independent
• SOAP is language independent
• SOAP is based on XML
• SOAP is simple and extensible
• SOAP allows you to get around firewalls
• SOAP is a W3C standard

What is WSDL?

WSDL is an XML-based language for locating and describing Web services.

• WSDL stands for Web Services Description Language
• WSDL is based on XML
• WSDL is used to describe Web services
• WSDL is used to locate Web services
• WSDL is a W3C standard

What is UDDI ?

UDDI is a directory service where companies can register and search for Web services.

• UDDI stands for Universal Description, Discovery and Integration
• UDDI is a directory for storing information about web services
• UDDI is a directory of web service interfaces described by WSDL
• UDDI communicates via SOAP
• UDDI is built into the Microsoft .NET platform

Principles of SOA

There is a common set of principles most associated with service orientation.

As a result of research the author performed for SOA Systems (during which service orientation, as a design paradigm, was studied within the context of all major vendor platforms and existing frameworks and blueprints) this set of common service-orientation principles has been identified and defined. 

Below are brief descriptions of each. 

Services are autonomous — The logic governed by a service resides within an explicit boundary. The service has control within this boundary, and is not dependent on other services for it to execute its governance. 

Services share a formal contract — In order for services to interact, they need not share anything but a collection of published metadata that describes each service and defines the terms of information exchange. 

Services are loosely coupled — Dependencies between the underlying logic of a service and its consumers are limited to conformance of the service contract. 

Services abstract underlying logic — Underlying logic, beyond what is expressed in the service contract metadata, is invisible to the outside world. 

Services are composable — Services may compose others, allowing logic to be represented at different levels of granularity. This promotes reusability and the creation of service abstraction layers. 

Services are reusable — Regardless of whether immediate reuse opportunities exist, services are designed to support potential reuse. 

Services are stateless — Services should be designed to maximize statelessness even if that means deferring state management elsewhere. 

Services are discoverable — Services should allow their descriptions to be discovered and understood by humans and service requestors that may be able to make use of their logic. 

Of these eight, autonomy, loose coupling, abstraction, and the need for a formal contract can be considered the core principles that form the baseline foundation for SOA, directly supporting the realization of others (as well as each other).

What is SOA - Service Oriented Architecture ?

"Separation of concerns" is an established software engineering theory based on the notion that it is beneficial to break down a large problem into a series of individual concerns. 

This allows the logic required to solve the problem to be decomposed into a collection of smaller, related pieces. Each piece of logic addresses a specific concern.

This theory has been implemented in different ways with different development platforms. Object-oriented programming and component-based programming approaches, for example, achieve a separation of concerns through the use of objects, classes, and components. 

Service orientation can be viewed as a distinct manner in which to realize a separation of concerns. The principles of service orientation provide a means of supporting this theory while achieving a foundation paradigm upon which many contemporary SOA characteristics can be built.

Difference between SOAP over HTTP and SOAP over JMS?

Reason for choosing JMS in most cases is reliability. But there are other things that come in mind whether to choose JMS or HTTP.

Reasons to go with HTTP:

• Firewall friendly (web services exposed over internet)
• Supported on all platforms (easiest connectivity in b2b scenario)
• Clients can be simple and lightweight

Reasons to go with JMS:

• Assured delivery and/or only once delivery
• Asynchronous support
• Publish/subscribe
• Queuing if better for achieving larger scalability and reliability
• Better handles temporary high load
• Large volume of messages (EDA)
• Better support in middleware software
• Transaction boundary

In SOA architecture best practice is to use JMS internally (for clients/providers that can easily connect to ESB) and HTTP for connecting to outside partners (over internet).

Using SOAP over JMS gives  some advantages compared to HTTP, 

specially related to reliability as you may use the persistence and acknowledgment features built in the standard. 

The same applies if you need to establish asynchronous communication or need to use the load balancing features provided by JMS servers.

We can achieve this using http but the implementation would be much more complicated.

If we do SOAP over JMS, in fact we can do load balancing..  where as with SOAP over HTTP requires additional hardware like IP Sprayers.