Introduction To Tibco EMS JMS supports these messaging models: Point-to-point(Queues) Publish and Subscribe(Topics) Multicast(Topics) Point-to-Point Point-to-point

messaging has one producer and one consumer per message. This style of messaging uses a queue to store messages until they are received. The message producer sends the message to the queue; the message consumer retrieves messages from the queue and sends acknowledgement that the message was received. More than one producer can send messages to the same queue, and more than one consumer can retrieve messages from the same queue. The queue can be configured to be exclusive, if desired. If the queue is exclusive, then all queue messages can only be retrieved by the first consumer specified for the queue. Exclusive queues are useful when you want only one application to receive messages for a specific queue. If the queue is not exclusive, any number of receivers can retrieve messages from the queue. Non-exclusive queues are useful for balancing the load of incoming messages across multiple receivers. Regardless of whether the queue is exclusive or not, only one consumer can ever consume each message that is placed on the queue. Publish and Subscribe In publish and subscribe message system, producers address messages to a topic. In this model, the producer is known as a publisher and the consumer is known as a subscriber. Many publishers can publish to the same topic, and a message from a single publisher can be received by many subscribers. Subscribers subscribe to topics, and all messages published to the topic are received by all subscribers to the topic. This type of message protocol is also known as broadcast messaging because messages are sent over the network and received by all interested subscribers, similar to how radio or television signals are broadcast and received. Multicast Multicast messaging allows one message producer to send a message to multiple-subscribed consumers simultaneously. As in publish and subscribe messaging models, the message producer addresses the message to a topic. Instead of delivering a copy of the message to each individual subscriber over TCP, however, the EMS server broadcasts the message over Pragmatic General Multicast (PGM). A daemon running on the machine with the subscribed EMS client receives the multicast message and delivers it to the message consumer. Multicast is highly scalable because of the reduction in bandwidth used to broadcast messages, and because of reduced EMS server resources used. However, multicast does not guarantee message delivery to all subscribers.

Destinations overview:1. Static: created by EMS administrator. 2. Dynamic: created by Client programs as needed for short-term use. 3. Temporary: Temporary destinations are ideal for limited-scope uses, such as reply subjects. EMS supports messages up to a maximum size of 512MB JMS messages have a standard structure. This structure includes the following sections: Header(required) Properties(optional) Body(optional) JMS message types: Message: This message type has no body. This is useful for simple event notification. Text Message: A Java.Lang.String MapMessages: A set of name/value pairs. Bytes Messages: A stream of uninterrupted bytes. The bytes are not typed; that is, they are not assigned to a primitive data type. StreamMessages: A stream of primitive values in the Java programming language. Each set of values belongs to a primitive data type, and must be read sequentially. ObjectMessage: A serializable object constructed in the Java programming language. Message Delivery Modes The JMSDeliveryMode message header field defines the delivery mode for the message. JMS supports PERSISTENT and NON_PERSISTENT delivery modes for both topic and queue. EMS extends these delivery modes to include a RELIABLE_DELIVERY mode. PERSISTENT when a producer sends a PERSISTENT message, the producer must wait for the server to reply with a confirmation. The message is persisted on disk by the server. This delivery mode ensures delivery of messages to the destination on the server in almost all circumstances. However, the cost is that this delivery mode incurs two-way network traffic for each message or committed transaction of a group of messages NON_PERSISTENT Sending a NON_PERSISTENT message omits the overhead of persisting the message on disk to improve performance. If authorization is disabled on the server, the server does not send a confirmation to the message producer. If authorization is enabled on the server, the default condition is for the producer to wait for the server to reply with a confirmation in the same manner as when using PERSISTENT mode. Regardless of whether authorization is enabled or disabled, you can use thenpsend_check_mode parameter in the tibemsd.conf file to specify the conditions under which the server is to send confirmation of NON_PERSISTENT messages to the producer. Figure 6 Non-Persistent Message Delivery

RELIABLE_DELIVERY When using RELIABLE_DELIVERY mode, the server never sends the producer a receipt confirmation or access denial and the producer does not wait for it. Reliable mode decreases the volume of message traffic, allowing higher message rates, which is useful for messages containing time-dependent data, such as stock price quotations. Message Selectors A message selector is a string that lets a client program specify a set of messages, based on the values of message headers and properties. A selector matches a message if, after substituting header and property values from the message into the selector string, the string evaluates to true. Consumers can request that the server deliver only those messages that match a selector. The syntax of selectors is based on a subset of the SQL92 conditional expressionsyntax. Identifiers Identifiers can refer to the values of message headers and properties, but not to the message body. Identifiers are case-sensitive. Basic Syntax An identifier is a sequence of letters and digits, of any length, that begins with a letter. As in Java, the set of letters includes _ (underscore) and $ (dollar). flowControl The flowControl property specifies the target maximum size the server can use to store pending messages for the destination. Should the number of messages exceed the maximum, the server will slow down the producers to the rate required by the message consumers. This is useful when message producers send messages much more quickly than message consumers can consume them. Unlike the behavior established by theoverflowPolicy property, flowControl never discards messages or generates errors back to producer. You can set flowControl using the form: flowControl=size[KBMBGB] where size is the maximum number of bytes of storage for pending messages of the destination. If you specify the flowControl property without a value, the target maximum is set to 256KB. You can optionally include a KB, MB or GB after the number to specify kilobytes,megabytes, or gigabytes, respectively. For example: flowControl=1000KB Means 1000 kilobytes. The flow_control parameter in tibemsd.conf file must be set to enabled before the value in this property is enforced by the server. See Flow Control for more information about flow control. Connection Factory: A connection factory is either dynamically created by the application or obtained from a data store by means of a naming service, such as a Java Naming and Directory Interface (JNDI) server or a Lightweight Directory Access Protocol (LDAP) server.

Fault Tolerance:

You can arrange TIBCO enterprise message service server fault tolerant operation by configuring pair of servers - one primary and backup. The primary server accepts client connection, and interacts with clients to deliver messages. If primary fails, backup server resumes operation on its place. Shared State A pair of fault tolerant servers must have access to shared state, which consists of client connections and persistent messages. This information is useful for backup server to resume its operation of current connections and messages.

Locking: To prevent the backup server from assuming the role primary server, the shared state is locked by primary server during normal operation. If primary server fails, then lock is released and the backup server can obtain lock.

Configuration Files: When a primary server fails, its backup server assumes as primary server and resume operations. Before becoming new primary server, the backup server re-reads all it configuration files. If configuration files are shared by two servers then administrative changes carry from old primary server to new primary server.

Detection: The backup server detects the failure of primary server in either two ways: 1. Heartbeat failure: the primary server sends heartbeat messages to backup server to indicate that it is still operating. When a network failure stops the servers from communicating each other, the backup server detects the interruption in the steady stream of heartbeat. 2. Connection failure: The backup server detects its failure of TCP connection with primary server. When the primary process terminates unexpectedly, the backup server detects the broken connection. Heartbeat Parameters When the primary server heartbeat stops, the backup server waits for its activation interval (elapsed time since it detected the most recent heartbeat); then the backup server retrieves information from shared storage and assumes the role of primary server. The default heartbeat interval is 3 seconds, and the default activation interval is 10 seconds. The activation interval must be at least twice the heartbeat interval. Both intervals are specified in seconds. You can set these intervals in the server configuration files. Shared State: The primary server and backup server must share same state. The server state includes three

categories of information. 1. Persistent message data 2. Client connection of the primary server 3. Meta data about message delivery Configuring Fault-Tolerant Servers To configure an EMS server as a fault-tolerant backup, set these parameters in its main configuration file (or on the server command line): Server Set this parameter to the same server name in the configuration files of both the primary server and the backup server. ft_active In the configuration file of the primary server, set this parameter to the URL of the backup server. In the configuration file of the backup server, set this parameter to the URL of the primary server

Authorization and Fault-Tolerant Servers EMS authorization interacts with fault tolerance. If authorization is enabled and the two EMS Servers are configured for fault tolerance, then both servers in a fault-tolerant pair must be configured as follows: The tibemsd.conf file for each server must have the same server name and password (the server and password parameters must be the same on each server). The user name and password in the users.conf file for each server must match the values of the server and password parameters in the tibemsd.conf file. If the two EMS servers are not sharing a users.config file, make sure that you create a user with the same name as the EMS server, and set the users password with the value of the Server password.

Configuring Clients for Fault-Tolerant Connections When a backup server assumes the role of the primary server during failover, clients attempt to reconnect to the backup server (that is, the new primary). To enable a client to reconnect, you must specify the URLs of both servers when creating a connection. Specify multiple servers as a comma-separated list of URLs. Both URLs must use the same protocol (either tcp or ssl). The client attempts to connect to each URL in the order listed. If a connection to one URL fails, the client tries the next URL in the list. The client tries the URLs in sequence until all URLs have been tried. If the first failed connection was not the first URL in the list, the attempts wrap to the start of the list (so each URL is tried). If none of the attempts succeed, the connection fails. For example, to identify the first server as tcp: //server0:7222, and the second server as tcp://server1:7344 (if first server is not available), you can specify: serverUrl = tcp://server0:7222, tcp://server1:7344

Routes

Tibco Enterprise message service servers can route messages to other servers 1. Topic message can travel from one hop to multiple hops 2. Queue messages travel from one hop to home queue and to one hop from home queue.

TIBCO Developers Library What is TIBCO Enterprise Message Service? TIBCO Enterprise Message Service In developing large and useful business applications, there is really a need for communication between two or more software components so that they may perform their tasks accordingly. Like for TIBCO consultants, they need to create a way where TIBCO software components can communicate with one another especially in carrying out the required tasks. One way of communication is through direct connection between different systems. However, this kind of approach is not applicable for large number of systems because some software components function differently from others. Also, it will require all the systems to know how to connect to every system in the network. This is one of the reasons why enterprise messaging system was created; so that all these systems can connect to each other through a central messaging server and all they need to know is how to connect to this central messaging server. This enterprise message system is implemented in TIBCO Enterprise Message Service. What is enterprise messaging? Enterprise messaging allows different systems to communicate with each other using a loosely coupled architecture. A loosely coupled architecture means that we can replace components without affecting the other components running in the server. The reason behind this is that the components are less dependent on each other. This also means that the system can continue to work even though some components are not connected to the network or to the server. Furthermore, some components within the system can still continue to send messages without waiting for reply messages. What are the advantages of enterprise messaging? Enterprise messaging can provide a single unifying medium of communication between different systems. It is also good for a network setup that is always changing.

For example, we have ten different systems and we want all of these systems to communicate with each other. If we are not using messaging, then we will need to know and configure the connection to every system. Now, just imagine what would happen if we have 100 computers or more. But, if we are using enterprise messaging, then we will just need to know how to connect the systems to a central messaging server. Another advantage is that there is a movement of real-time data. The messages can be created and received in real-time. Moreover, enterprise messaging has time independence, which means that the client has the option to still receive messages when he reconnects to the server even if the client was down when the message was sent. What is TIBCO EMS? TIBCO EMS stands for Enterprise Message Service and it is TIBCOs implementation of Java Message Service. TIBCO EMS is fully compliant with the JMS specification and it has added some enhancements to the JMS specification. It also has added features like loadbalancing, routing, and fault tolerant configurations, which help improve performance and minimize failures in the server. What is JMS? JMS which stands for Java Message Service is an enterprise messaging specification created by Sun Microsystems. It is also what we call the store-and-forward messaging system. Storeand-forward messaging system means that all messages created by clients pass through the server before it is sent or forwarded to the designated consumers. This also applies to the reply messages created by the consumers. JMS also provides both queue-based and publish-subscribe APIs. Queue-based APIs make use of queue destinations and publish-subscribe APIs make use of topic destinations. What is the JMS Message structure? The JMS Message structure is composed of the headers, properties, and body. The header is required, while the properties and body are both optional. The Header of the message contains predefined fields which are used to route and deliver the message. Some of these predefined fields are the following: o JMSDestination is the destination to which the message is sent. o JMSDeliveryMode determines if the message is persistent or non-persistent o JMSExpiration is the length of time that the message will live before expiration. The Properties (optional) are optional properties that can be added on JMS systems by authorized users such as administrators.

The Body (optional) contains the data you want to send to the consumers. It must be one of these five types: o TextMessage o MapMessage o BytesMessage o StreamMessage o ObjectMessage What is message compression? Message compression ensures that the message will take less memory space when saved on the storage of the server. Nonetheless, we must take note that message compression will only compress the body of a message. The headers and properties can never be compressed. What are the types of queues and topics we can create in EMS? There are three types of queues or topics that we can create in EMS. They can be static, temporary, or dynamic queues/topics. Static queues/topics are specified explicitly in the configuration files. Temporary queues/topics are used for reply messages in request/reply interactions. Dynamic queues/topics are not specified in the configuration files for these are dynamically created by client programs. Moreover, dynamic queues are TIBCO specific, which means that it is an extension added by TIBCO to the JMS specification. What are the advanced features of TIBCO EMS? The advanced features of TIBCO EMS include JMS capability to non-Java programs such as C and C# Client API. It also provides an administrative API which is used for managing and monitoring the EMS server and its components. It can be configured for connection to other EMS servers such as fault-tolerance and routing so that multiple EMS servers can participate in the server operations. It can also be connected to other TIBCO components specifically TIBCO Rendezvous and TIBCO SmartSockets. It offers destination bridging which makes it easier to send the same message from one destination to other destinations. It has JNDI and SSL support to provide security over the EMS server and its components. Also, it can be integrated into third party application servers. How do you configure the TIBCO EMS? There are the three ways to configure TIBCO EMS. The first way is by modifying the configuration files. The main server configuration file is the tibemsd.conf. This is where you can set the names of the other configuration files. It has some basic parameters such as server name and password, listen port and storage location for messages. Its other parameters are for fault-tolerance, and SSL.

Another way to configure TIBCO EMS is through the use of the EMS Administration tool which comes in console mode. This means that you have to type or issue the correct commands to use this tool. The third way to configure TIBCO EMS is the through the use of Administration API. What is fault tolerance and how does it work? Fault tolerance is having a pair of EMS servers configured as the primary and backup servers. The primary server accepts client connections, and interacts with clients to deliver messages. When the primary server fails, the backup server resumes the operation in its place. The backup server will be the primary server, and the other server will be the backup server when it goes online. One important configuration for these fault-tolerant servers is that they should have access to the same shared state which consists of information about client connections and persistent messages. What are destination bridges? Destination bridging is a server-based solution provided by TIBCO EMS. It is an alternative for creating messages multiple times. For example, if we want to send the same message from one destination to other destinations, we dont need to send the same message a number of times. We just bridge the different destinations so that the same message will be sent to all the bridged destinations. How can you improve Client-side processing while using TIBCO EMS? We can improve the client side processing by configuring the Server Settings, Destination Settings and Security Settings. In the server settings, we can use EMS routing between servers within the network so that all servers and systems within the network can communicate with each other. Also, we should use destination bridging so that we dont have to send the same message again and again. For the destination settings, we should only use durable topics if it is really needed. We can enable pre-fetching for small size messages. We can make use of lower JMS reliability modes. For client-load balancing, we can use non-exclusive queues so that more than one consumer can process the message from the queue in a round-robin fashion. In setting up the security for TIBCO EMS, we should just use SSL if there is no available Virtual Private Network. Another way is through disabling authentication if possible so that the servers and clients can easily communicate with each other. These are just some of the important information you need to know about TIBCO EMS and it still has a lot more to offer which you will learn upon using it. This TIBCO component is so easy to use and its functionality is great. So, if you are developing large business applications

and you want your software components to communicate with each other, TIBCO EMS is the right software for you.

Tibco tutorial : Difference between Tibco EMS and Tibco RV Both of them are product from Tibco and used extensively across global investment banks for front end to back end communication or server to server communication. though they have difference in the manner they have designed and the specification they are based upon .

Tibco RV stands for Tibco Rendezvous which is based on proprietary tibco protocol (TRDP/PGM) developed by company. They have provided API in almost all major programming language and this is a preferred choice if you need high speed communication e.g. publishing market data updates etc.

Most of the stock trading application either equities or futures/options they are heavily relied on market data which they receive from various market data publishers e.g. Reuters , Bloom berg or Wombat but sometime format of market data is not something every application can directly consume so they have internal application which receives this stock prices and covert them into a format which every application can understand and here they publish market data in a tibco multicast topic say MARKETDATA.TSE.UPDATE and all application which needs can subscribe to this.

While Tibco EMS stands for Tibco Enterprise Messaging service and is based upon JMS specification which is provided by Sun MicroSystem. though other JMS implementation also available e.g. MQ Series

Tibco EMS is preferred choice for more reliable communication e.g. for sending and receiving Order and Execution data.

Today almost all the stock trading happens electronically and here its most important requirement is not to loose any order or execution received from either client or exchange , so all sell side firm which provides these trading application and infrastructure rely on tibco for such kind of needs. Tibco EMS cater this requirement by providing durable tibco topic which

holds the data until every subscriber consumes it and also guarantees data shouldn't lost during network transmission.

Tibco RV do provide guaranteed communication via Tibco Certified messaging and which is used to send/receive sensitive information e.g. Order , execution or booking related data if you are using Tibco RV infrastructure since in this case you can't afford data loss which is bound to occur in case of Tibco RV.

Important part of Tibco RV infrastructure are

Rendezvous Daemon (RVD): most important part application connects to rvd daemon over TCP protocol which in tern responsible for efficient messaging over the network using TRDP/PGM multicast/broadcast transport with subject based filtering.

Rendezvous Routing Daemon (RVRD): It is used to bridge two regional network say Tokyo and London or London and New york Implements point-to-point (TCP) routing of messages with subject-based filtering across different multicast networks and also handles the RVD functionality on the local network.

to summarize

I could outline following difference between Tibco RV and Tibco EMS based upon my experience : 1) Tibco RV is proffered choice for high speed messaging e..g publish of market data etc while Tibco EMS which is based upon JMS implementation is mostly used for more reliable messaging e.g. Order and trade and mostly work on acknowledgment . 2) Also topic and queue created on Tibco EMS are static in nature and they get created on Tibco EMS Server while Subject of Tibco RV is dynamic in nature.

3) Tibco RV works on Bus model every node connected to bus have RVD running so no single point of failure if one node goes down other can still communicate with each other while in case of Tibco EMS work on Hub and Spoke model where Tibco EMS Server is Single Point of failure because all topics and queues were created on this and publisher and subscriber connects to it , so if it went down all traffic will be stopped , though Tibco EMS Server could have another failover instance which can become primary in case required.

Read more: http://javarevisited.blogspot.com/2011/01/tibco-tutorial-difference-betweentibco.html#ixzz2FrrpoEVf TIBCO Deployment Researched and written by Xmarter TIBCO Consultants Traditional deployment of business integration project requires a lot of configuration effort. The administrator needs to ensure that the configurations for multiple interactions are supported and configuration files are required for different components on different machines. TIBCO ActiveMatrix BusinessWorks, in contrast, provides an interface for creating deployment configuration and then deploying the project. To deploy TIBCO ActiveMatrix BusinessWorks Projects, TIBCO Administrator is used. It is a central administrator server for creating, deploying, managing, and monitoring TIBCO applications and machines within the administration domain. Upon deployment, TIBCO Administrator will create deployment configuration that will be sent to the machines where the projects will be deployed. All TIBCO BusinessWorks Projects undergo same project phase: design, deploy, and run. After designing and testing the process in TIBCO Designer and setting up the required resources, projects will be deployed in TIBCO Administrator to run on its designated machines. There are two ways to deploy the project in the TIBCO Administrator Server: using the TIBCO Administrator GUI or using scripting deployment utilities. TIBCO Administrator GUI is a web-based graphical-user interface where administrators can easily manage and deploy TIBCO BusinessWorks Projects using a web browser while scripting utilities allow TIBCO Administrator functions to be executed from the command-line. In using TIBCO Administrator GUI to deploy projects, an Enterprise Archive (EAR) file needs to be created using TIBCO Designer. The EAR file must contain all the required resources such as adapter configurations and process definitions that need to be deployed. After building the EAR file, it will be uploaded to TIBCO Administrator GUI to create the application and to set deployment configuration. On the other hand, in using command-line utilities for deployment, only the Buildear and AppManage utilities are used. Buildear utility is used to build the EAR file based on an archive defined in a TIBCO Designer project while AppManage utility creates an XML based deployment configuration file then uploads the deployment file and EAR file into TIBCO Administrator.

TIBCO Administrator allows applications to be deployed multiple times. However, only one deployment configuration can run anytime. It has a Configuration Console which provides options for deploying and updating applications and it maintains a deployment configuration history that allows reverting of deployments in the future. Updating of application is very important if new TIBCO software is installed on the machines where the application is deployed. Once an application is deployed, TIBCO Administrator imports all the values defined for global variables from the EAR file. This allows global variables to be changed during deployment. Global variables may vary depending on the environment and these variables might use environment specific values. Thus, setting correct variables during deployment is critical for the application to run. TIBCO Administrator enables administrator to manage deployed processes and services included in the application. Processes deployed in TIBCO Administrator can be assigned and run on any machine that belongs to the same administration domain. The target machine where processes and services are deployed is called container. Services can also be enabled and disabled. Disabled services will not be deployed in the next application deployment unless enabled before deploying. Services process instances execution can be controlled by changing process configuration properties like Max Jobs, Activation Limit and Flow Limit. This is helpful if process instances need to run sequentially due to limited CPU resources and memory. Max Jobs property is used to limit the number of concurrent process instances that can be loaded in memory. Meanwhile, Activation Limit property is selected if process instances that are loaded in memory will stay in memory until completion. However, Flow Limit property sets the maximum number of process instance that can be started before suspending the process starter. Project deployment maybe a simple task but its at least as important as the project design. Deployment needed to include required resources and configurations to have a smooth run in production. Thus, TIBCO ActiveMatrix BusinessWorks allows business integration project deployment to be easily configured and run on any machine in the domain. In another perspective, TIBCO lets you integrate different incompatible applications in a service-oriented architecture (SOA). This can be achieved through ActiveMatrix (AMX) Service Grid and other AMX family of products. In AMX Service Grid, you can create a composite, which contains services, components, and references. You can think of a composite as a circuit board which holds several important electronic modules. Services simply refers to web services, which are standardized methods of communication between two contracting parties, commonly a service provider and a service consumer/client, in a language only both of them can understand. Communication happens through message exchanges either one-way or two-way. In a two-way communication, the consumer sends a request message and expects a response message back. This message comes in a specific format usually SOAP or JMS.

Components are implementations of web services. You can use TIBCO ActiveMatrix BusinessWorks, Java, .NET, or Ruby to create the implementations of web services provided that these applications conform to the specifications that describe your web services. A common model used to describe the specifications of web services is the Web Services Definition Language (WSDL). However, there are circumstances when the service provider or the implementing applications cannot change the structure of the message format they are using, yet the client must conform to their specification. This is where mediation comes in. One of the things mediation does is translating the message into a format which can be understood by the receiving end. References are external web services which provide operations you want to reuse as implementations of your own web services. Alternatively, you can refer to another composite within your AMX SOA project. After creating the composite, you need to be able to run the web service by deploying it to logical and physical servers. Now that you have pieced all the components together in the circuit board, you need to make sure that these components will work harmoniously as a single unit. Deploying web services in AMX Administrator, which supports both graphical and command-line interfaces, is very simple and straightforward and takes less time to achieve. First, you need to create a service assembly. A service assembly is simply a collection of composite, shared resources, connections, metadata, and other necessary files in your AMX SOA project. Think of it as a CPU composed of a motherboard, which is like a composite, together with other essential stuffs, to make the whole system working. The service assembly is compressed into a portable ZIP file which is uploaded to AMX Administrator GUI during deployment. You can create a service assembly by using a utility provided in TIBCO Business Studio, which is the main development tool for creating AMX SOA projects. When you upload the ZIP file, AMX Administrator will automatically determine what components are present and are ready to be deployed in nodes. Nodes are instances of the Java Virtual Machine, which run containers, software that executes the code, and the messaging bus. Nodes are installed on a physical server and they can be started, stopped, and uninstalled anytime, while containers can either be activated or deactivated. You can deploy various components, which become service units during runtime, into multiple nodes for fault tolerance and load balancing. You can map several nodes to one service unit. The environment lets you logically manage the nodes, the messaging bus, which can be one or more instances of the TIBCO Enterprise Message Service, and the connectors, containers, shared resources, and keystores contained in nodes. Shared resources enable services to connect with physical resources such as a JMS or an HTTP server. You can have one or more environments to enable and maintain system scalability and flexibility depending on system requirements. Environments also let you configure logging events for tracing errors easily and manage substitution variables or enterprise level variables which could potentially alter

from one environment to another. Examples of these variables are queue destinations, service URLs, among others. When it meets all the requirements for deployment, the service assembly now becomes deployable. On AMX Administrator, you can just simply click the Deploy button to deploy the service and after it is deployed, you can start the service. When the status changes to Running, your web service is now usable and ready to accept requests from service clients. AMX Administrator GUI comes with monitoring and management tools such as dashboard, infrastructure, service, deployment, and log views which let you track the status, health, and performance of the AMX infrastructure and the services running on that infrastructure. AMX Administrator also provides a utility that gives you an option to deploy services through the command-line interface. All you have to do is write build scripts which are in XML format and specify the deployment options with the target resources you want to execute. Scripting makes it easier and faster to deploy services especially if it requires you to deploy a lot of services into multiple nodes and environments. It also makes deployment possible for operating systems that dont support GUI. TIBCO ActiveMatrix simplifies the life cycle of web services and empowers you truly create SOA applications easily, rapidly and efficiently. With the accelerating adoption of SOA in enterprise applications, you can be assured that your business will realistically benefit in the long run from using this software. With absolutely shorter integration phases and quicker, zero downtime deployments, the TIBCO ActiveMatrix solution strongly brings business advantage and growth together to a much higher level. ---------------------------------------------------------------------------------------------------------------How to find the DateTime Difference from two different Time Zone? How to find the DateTime Difference from two different Time Zone? You can use this simple below function. tib:compare-dateTime((tib:translate-timezone(current-dateTime(), '+05:30')), tib:translatetimezone($Start/root/InputDateTime, '+05:30'))