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

When you excute a "Call Process" task, you just perform another process in the same engine and thread, and wait for its completion. It is like calling a method/function in a normal 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 conclusion. 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 alone 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 BusinessWorks engine is a Operating System process running its own Java Virtual Machine and running a set of BusinessWorks processes, started by events. Each engine is a split 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.