Difference between 'JMS Queue Message' activity and 'Wait for JMS Queue Message' activity

Wait for JMS Queue Message activity starts listening for messages from the time the BusinessWorks engine starts.
Get JMS Queue Message activity starts listening for incoming messages on the specified queue from the time the activity is triggered.

This can test by developing two simple example processes.i.e

First create a queue and place some pending messages in queue.

build a process_defention1 with one Wait for JMS Queue Message activity and configure it with queue name.
build a process_defention2 with one Get JMS Queue Message activity and configure it with queue name.

If we just start process_defention1 ,then the pending message count = 0. (No need to trigger Wait for JMS Queue Message activity)
If we just start process_defention2 ,then the pending messages count = not zero. it becomes zero when the Get JMS Queue Message activity triggered.

● Get JMS Queue Message activity can receive only one message from the specified queue at a time, when the Message Selector is not used.
● Get JMS Queue Message activity once triggered, then this  can either gets a message from the specified destination queue name before timeout and proceeds or it throws a timeout error and exits.

Wait for JMS Queue Message activity is non starter activity which behaves like queue reciever (starter activity) 

HTTP Methods

HTTP defines nine methods indicating the desired action to be performed on the identified resource.The list has mentioned below are the methods available for HTTP.

HEAD

Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.

GET

Requests a representation of the specified resource. Requests using GET (and a few other HTTP methods) "SHOULD NOT have the significance of taking an action other than retrieval".

POST
Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both.

PUT
Uploads a representation of the specified resource.

DELETE
Deletes the specified resource.

TRACE

Echoes back the received request, so that a client can see what (if any) changes or additions have been made by intermediate servers.

OPTIONS

Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.

CONNECT

Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.

PATCH

Is used to apply partial modifications to a resource.
 

HTTP servers are required to implement at least the GET and HEAD methods and, whenever possible, also the OPTIONS method.

BW supports the METHOD= DELETE, POST, OPTIONS, HEAD, GET, PUT and  For other methods throughs the error code  "BW-HTTP-100000" "statusCode =405"

Enterprise Messaging System

TIBCO Enterprise Messaging Offering the EMS which extended the features of JMS

EMS is Enterprise Messaging System offering the fallowing list

• Message MODELS
• Delivery modes
• Message STRUCTURE
• Message DELIVERY MODES
• STORE
• Message ACKNOWLEDGEMENT
• Message SELECTORS
• Destinations
• TIBCO EMS Server -tibemsd
• Destination PROPERTIES
• Destination BRIDGES
• ROUTING
• Zones

EMS  have the three types of messagig models i.e.Point-to-Point (Queues),Publish Subscribe (Topics)
Multicast (Topics),

JMS provides 2 delivery modes for messages PERSISTENT,NON_PERSISTENT,EMS adds the 3rd delivery mode RELIABLE_DELIVERY

TIBCO BW Administration

TIBCO BW Administration is for User Management,Resource Management and Application Management

User Management -Managing authentication, roles, and users.
Resource Management -Managing machines, applications, and deployments.
Application Management -Creation, configuration, deployment, and monitoring of applications.

Roles and Responsibilities

 Various roles are recommended during a BW development project i.e.Domain Administrator,Project Administrator,Building of actual BW solution
 

Domain Administrator will Configures domains and grants access to different projects and runtime components.
 

Project Administrator  responsible for maintaining a specific server-based project and  maintains project templates, common services, global variables, shared resources, and shared schemas.
 

Developer  Builds the actual BW solution.Release / Test / Deployment Engineers optional roles responsible for testing, building EAR files, and deploying EAR files.


TIBCO Administration Domain

A collection of users, machines, and services managed by a TIBCO Administration Server and secondary servers may be added.Here cannot run a master and secondary on the same machine.
 

Multiple administration domains may exist on one server.Each domain must have an associated master server.Stores user and group information in the domain data store.This can also sync with LDAP for users and groups and supported LDAP servers include SunONE Directory Server, NovelleDirectory, and MS Active Directory.
 

By default, all machines that belong to a domain are expected to be on the
same network subnet.This can use RVRD if access across subnets is required.

Administrator Users and Roles

Maintain ACL’s by specifying users, roles, passwords, and authorization
levels.Administrator access is given on a per-UI element basis.i.e. Read, write, and administer access.
 

If using LDAP, you cannot create/rename users or change passwords in the
Administrator GUI.
– Performed through the corporate LDAP.
– Exception: May change the password for the original admin user.
Changing the original admin password also involves using the Domain Utility
on every machine in the domain.
– Ensure that the Administration Server is running!
Members of a child role are automatically members of each parent role.

TIBCO Deployment

Have two deployment methods i.e One-Click deployment and Scripting deployment

These are the general steps in process.

1. Create Project.
2. Build EAR from project.
3. Save EAR to Disk.
4. Upload EAR via HTTP.

• Domain Configuration
• Application Runtime RepoInstance

5. Configure Application
6. Deploy Application
7. Contact TSM for Deploy with Hawk
8. Execute Deployment Plugin
9. Save .tra file to disk (substituting from template .tra)
10. Contact TSM for Starting Engines with Hawk
11. Launch Engine
12. BW/Adapter reads configuration with RV or HTTP(s).
13. Monitor Application.
14. Gather stats with Hawk
15. Return runtime stats.


steps 5-11 are “One-Click Deployment” 

Command-Line Deployment

This is Full command-line deployment (scripting deployment) and available in Add-on pack on top of BW 5.x. and also Redeployment of an existing application is supported via command line.

However, with BW 5.x, can manually generate scripts to create an automated deployment process and can use  prepareDeployment.exe, redeploy.exe and deployment.xml, tibco.xml (global variables)


Redeployment

When a new archive is loaded, a diff of the new archive with the existing
archive is performed.New services are added, services not present in the new archive are removed.
 

If the shared configuration in the application archive or application level deployment descriptors are changed, all deployed service instances will be stopped (whether they are affected by the new archive or not), the repo instance is updated, and the client side .tra files are regenerated.
 

If the binary content of the service archive or the service level deployment descriptors are changed, then ONLY the affected service instances are stopped, and the client side .tra files for those affected service instances are regenerated.

The following configuration items must be performed in the Administrator:
– Binding services to machines.
– Hawk rulebase uploading.
– Service instance configuration (e.g. JVM properties).
– Fault-Tolerance.