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.

  

Perform upgrade of TIBCO components / Migration from TIBCO BW 5.X to 5.Y

These are the example steps for migrating from domain "OLD" to domain "NEW".

1.We have a writable directory to export the applications to. Let's call it $BATCHDIR.

2.We should know the actual username and password for the old and new domains.

3.Make sure both domains are running.

4.cd to $TRA_HOME/tra/<ver>/bin/ , lets say /utils/tibco/tra/5.3/bin/

5.Use this command to create a batch file and export .ear files and configuration files: "AppManage -batchExport -domain OLD -user tibco -pw tibco -dir $BATCHDIR "

6.To import all of the applications without starting them, use this command: "AppManage -batchDeploy -domain NEW -user tibco -pw tibco -dir $BATCHDIR -nostart"

If we want to automatically start the applications after deploying, leave off the -nostart parameter. If we don't want to deploy all the applications, modify the $BATCHDIR/AppManage.batch file by commenting or deleting the applications we don't want to deploy.

Typically after we do the batch deploy, we manually stop all of the engines in the old domain, then manually start the engines in the new domain, then stop the old domain itself. This leaves the old domain intact in case something went wrong with the deployments, but it no longer uses any resources.

Business needs may require us to have an engine running at all times, so we could start the new engines before stopping the old engines, but we should make sure they will not conflict with each other first.

Improvements to the AppManage utility in TRA version 5.3 give even more control over working with multiple engines.

Pain points which needs to put light in migration

Is all the Services are scripted deployed or not, in OLD domain?
If few of them manual deployment How to go about it?
How to convert everything to Scripted deployment going forward to ease further enhancements?
Memory Issues (Physical as well as RAM), System requirements due to migration?
Get to know the Basic difference of versions (old and new), e.g. Kind of repository used?
What causes engine startup error due to migration?
How to automate these entire process?
Can be divided into sections Export, Process & Import ?
Is services falls under LB as well as FT?
What are all adapters involved?
Carefully diagonize the difference this is where you end up more processing ?






 

Difference between Inter Process Communication and main process & sub process Communication (using called and calling)

When you excute a "Call Process" task, you just execute another process in the same engine and thread, and wait for its completion. It is like calling a method/function in a standard language.

If in this task, you select the "Spawn" option, the other process will be executed in parallel, in the same engine, but in another thread. The task will complete without waiting for the process completion. This can be used if you want to start a separate process running in parallel.

Now you will use the "Notify" task to send a notification from a process (A) to another one (B) running separately in parallel in different threads. The other process (B) uses the "Wait Notify" task to wait for a notification from another process (A).

In order to work, both A and B notification tasks require a shared configuration object: a "Notify" configuration object. This one can define an XML schema, so processes using this configuration can pass data (from A to B).

The "Notify" configuration object, by default, works for processes running in the same TIBCO BusinessWorks engine. A BW engine is a Operating System process running its own Java Virtual Machine and running a set of BW processes, started by events. Each engine is a separate process at the OS level.

If you want to pass data from one engine to another process in another separate engine, you will select the "Multi-Engine" option of the "Notify" configuration object. In this case, both engines need to access the same database, where TIBCO BusinessWorks stores the data passed from one engine to another one. This mode of communication is slow and requires a database.

Generally, to communicate between separate engines in an efficient and flexible way, you are better consider proper SOA and EAI communication transports and formats, such as SOAP over HTTP/HTTPS/JMS, XML over HTTP/HTTPS/JMS/Rendezvous, etc...

The notification between separate engines is something to consider as last possibility and to be used only for synchronization: for example, execute something only when something else is finished somewhere else.

syntax error near unexpected token `newline' or `$'\r''

Common errors in running an unix shell scripts are 

line 34: syntax error near unexpected token `newline'
line 30: syntax error near unexpected token `$'\r'' 

Solution:

Unix script file name example.sh then the below is the command to fire on machine.

dos2unix example.sh example.sh

So that it removes the hidden Windows Characters from Files.

While editing files on a machine running some form of Windows and uploading them to a Linux server is convenient, it can cause unforeseen complications. 

Windows-based text editors put special characters at the end of lines to denote a line return or newline. 

Normally harmless, some applications on a Linux server cannot understand these characters and can cause the service to not respond correctly. 

There is a simple way to correct this problem: dos2unix.

What do the hidden characters look like?

Below is an example from the example.sh file showing what the hidden characters look like:

;;;;;;;;;;;;;;;;;;;^M
; Resource Limits ;^M
;;;;;;;;;;;;;;;;;;;^M
;^M
max_execution_time = 30^M
max_input_time = 60^M
memory_limit = 32M^M

As said before, these characters will not appear in most Windows text editors, but will appears in Linux command line utilities like cat or vi. Removing them is rather painless. Just run the command dos2unix.

root@host [~]# dos2unix example.sh example.sh

In the above example of the example.sh, it will look something like this:

root@host [~]# dos2unix example.sh example.sh
dos2unix: converting file example.sh to UNIX format ...

That’s it. If the command has worked correctly, the file in question shouldn’t have any of the hidden characters in it, like the follow:

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;
;
max_execution_time = 30
max_input_time = 60
memory_limit = 32M

The dos2unix command is a simple way to make sure that files that have been edited and uploaded from a Windows machine to a Linux machine work and behave correctly.

How can create custom process starters in TIBCO AMBW ?

 Custom process starters can also be created.

 The Java Event Source process starter allows to create a custom process starter based on Java code.

 Java Event Source provides the features (such as Sequencing key) of other process starters without the need to write extra code.

 Java Event Source provides an abstract class to extend to create a process starter. The abstract class describes the methods that interact with the process engine. 

Custom code must provide implementation for the methods,

 init(). Called when the process engine starts. Can initialize any resource connections. Specify a Java Global instance on the Advanced tab that initializes resource connections. Java Global instances are loaded and initialized during process engine start up. this.getJavaGlobalInstance() can be executed to obtain the Java Global Instance resource in process starter code.

 onStart(). Called by the process engine to activate the process starter. This method must activate any event notifier or resource observer code. The notifier or observer code can then call the onEvent() method to start a process instance.

 onStop(). Called by the process engine to deactivate the process starter. This method must deactivate any event notifier or resource observer code.

onShutdown(). Called by the process engine when the engine shuts down. The method should release any resources and resource connections and perform any required clean up operations.

Methods already implemented.

onEvent(Object object). Called when a listener or resource observer catches a new event. Input to this is a Java object containing the event data.

getGlobalInstance(). Returns an object reference to the Java Global resource specified on the Advanced tab of the process starter. Useful when initialization code is placed in a Java Global Resource instead of the init() method.

onError(). Throws the exception specified in the input parameter. Used to propagate an error to the TIBCO ActiveMatrix BusinessWorks process instance when a listener or resource observer fails to generate an event.