TIBCO Admin -Transport options local / rv / http

When TIBCO Administrator deploys an application, it creates an application repository which contains information about the application configuration.

We can view and change certain aspects of the application repository.
 

TIBCO Admin -Transport  options local / rv / http

In TIBCO Admin , browse new ear file and  go to the path "Edit Application Configuration > Advanced tab"

There are two sections

Global Variables
TIBCO BusinessWorks and Adapters Deployment Repository Instance    

under the section "TIBCO BusinessWorks and Adapters Deployment Repository Instance" there is Transport drop down box having the options local ,rv and http

This transport is that the administration server uses to communicate with the client application.

•  local

By default, the transport is set to local. This means that the application repository will be sent to the target machine. This allows the application to run independently of the administration server.

If you change the transport from local to another value, the application repository will not be pushed to the target machine, and the application will communicate with the administration server at runtime.
 

The local choice is supported only if the target machines have installed TIBCO Runtime Agent 5.3 or later.

•   rv

If rv selected, the client application will use TIBCO Rendezvous to communicate with the administration server.
 

• http

If selected, the client application will use HTTP to communicate with the administration server.

If administration domain is not initially enabled for HTTPS, and there are deployed applications in the domain that use HTTP to connect to the application repository, the service instances will not restart after they are shut down. In this case, you must redeploy each service instance after changing the transport to HTTPS.
 

The parameter  HTTP URL, HTTPS URL  is the URL on which the client attempts to connect to the server. What displays depends on whether you configured the server for HTTPS

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.