Configuring TIBCO EMS: Load Balancing

Configure the Daemon: You can start with one of the existing tibemsd.conf files and you will need to modify the server, store, listen, ft_active, routing and routes elements.

Server is the name of the EMS Server, and it needs to be distinct from other members of the LB group. In this case, we have chosen EMS-SERVER1. Since we will be building everything on a single host with two LB members each in a FT pair, we need to create another FT pair. In this case, we are using ports 7122 and 7124 with server EMS-SERVER1, a new store, and a new routes element (more on routes later).

The configuration approach is the same for building a FT Pair, by swapping listen and ft_active ports. The difference is that this is a new instance of FT and needs a unique name and storage. Routes need to be different as one cannot route to oneself.

The parameters we will be using as follows:
server = EMS-SERVER1
store = datastorelb
listen = tcp://7122
ft_active = tcp://7124
routing = enabled
routes = routes2.conf

Configure the Load-Balanced Factories (incl. FT pairs): In a similar fashion, you can edit the factories.conf file or enter the new factories via the EMS Administration Tool. The difference is the syntax where a vertical bar, or pipe, is used to delimit the two fault-tolerant pairs.

[LBTopicConnectionFactory]
type = topic url = tcp://7222, tcp://7224 tcp://7122, tcp://7124
metric = connections
[LBQueueConnectionFactory]
type = queue url = tcp://7222, tcp://7224 tcp://7122, tcp://7124
metric = connections

These URLs combine FT and LB. With Load-Balancing, you have the element of metric which can be either connections or byte_rate. The client will retrieve the URL based on request of a particular Factory, and if it is a load-balanced URL, it will query each participant for the value of the metric and the client will make the connection appropriate to the metric.

Enable Routing: You MUST route messages between LB servers, and if using FT pairs, you need to specify a FT URL. As you cannot route to yourself, and keeping in mind that Queues can only have one hop, you must configure routes appropriately.
The routes.conf file for EMS-Server will point to EMS-SERVER1 and use the FT URL for that pair, as follows:

[EMS-SERVER1] url = tcp://7122, tcp://7124

zone_name = default_mhop_zone

zone_type = mhop

Since we pointed EMS-SERVER1 to routes2.conf, it will look like this:
[EMS-SERVER]

url = tcp://7222, tcp://7224

zone_name = default_mhop_zone

zone_type = mhop

See the EMS documentation for more information on Zones and Zone-types. For this example, we can take the default. These entries can be created through the EMS Adminstration Tool as well:

create route EMS-SERVER1 url=tcp://7122,tcp//7124

Topics/Queues with Routing

Set Global Attribute: The Global Attribute can be applied to both topics and queues and permits messages to flow between members participating in Load Balancing. You can modify existing topics and queues, or when you create new ones, the syntax is as follows:

tcp://localhost:7222) create topic foo.bar global

Topic 'foo.bar' has been created

tcp://localhost:7222) commit

Configuration has been saved

As Queues can only be “one hop” away, you need to designate a “home”. When you configure a queue on a non-home provider, you point to the home with the following syntax, where you specify the home provider for the queue:

create queue my.queue (Server_Name) global

Read more...

Configuring TIBCO EMS: Fault-Tolerance

We will configure TIBCO Enterprise Message Service from building a set of fault-tolerant pairs to putting those pairs into a load-balanced environment. The solution can be built on a single machine and tested, as shown below. In a real deployment scenario, you would want to have each machine be distinct.

In the diagram above, you see four EMS Server instances with each Fault-Tolerant (FT) pair sharing the same EMS “Server Name”, and you see the client with a complex URL that is constructed such that you have FT pairs separated by a comma and those pairs in a Load-Balanced (LB) arrangement separated by a vertical bar (or pipe symbol).

To make this arrangement work on a single machine, the individual services are on distinct ports. The first FT pair has an active server on port 7222 with a backup server listening on port 7224, for example. The primary is the one that starts first.

Fault Tolerant Configuration
Configure the Daemon
To configure Fault-Tolerance, we will need to configure only two types of files:
tibemsd.conf – configure the daemon process
factories.conf - build FT factories as needed

Since we have a FT pair, we will create two files for the daemon processes so that we can start them with different configurations on the same machine. Given different machines, each machine will only need one of each of the types of files, but for our example, some types of files are shared while others need to be replicated to provide unique features.

Below, you will see the first tibemsd.conf file, renamed tibemsd1.conf to provide a unique identity. Note the bold items for server, store, listen, and ft_active – these are the required entries for FT configuration; the addition of the routing item is included at this time since we will be using this FT pair in an LB environment.

The second configuration will be accomplished by making a copy of the first and renaming it, prior to making some minor modifications. In the example below, we have named the file tibemsd2.conf

Note how the ft_active port is the same as the listen port of the other configuration, and vice versa! This is the only change necessary. This is akin to a “roll-over” cable and permits each server to receive heartbeats from the other. The active server has an exclusive lock on the storage.

Configure a Fault-Tolerant Factory

Edit factories.conf and create two factories, one for queues and one for topics. The standard factories.conf come with these preconfigured as FTTopicConnectionFactory and FTQueueConnectionFactory. The syntax in the file looks like this:

[FTTopicConnectionFactory]

type = topic

url = tcp://localhost:7222,tcp://localhost:7224

[FTQueueConnectionFactory]

type = queue

url = tcp://localhost:7222,tcp://localhost:7224

An alternate method to editing this file is to start up one of these daemons and to access the EMS Administration Tool and enter the command:

create factory FTQ queue url=tcp://localhost:7222,tcp://localhost:7224

This will create a ConnectionFactory for queues that exposes a Fault-Tolerant URL, as shown by the two comma-separated host specific URLs. When a Client requests the FTQ factory object through JNDI, it will have this complex URL associated with these two servers.

Set track_message_ids Parameter
There will be Fault-Tolerant cases where a failure occurs before the Provider can acknowledge the receipt of the message, so to prevent duplicate messages, you set the track_message_ids parameter in the tibemsd.conf file:
track_message_ids = enabled

Starting a Fault-Tolerant Pair

Simply start two instances of the EMS daemon where each instance points to a specific configuration file (shown is from a Windows Batch file):
start tibemsd -config tibemsd1.conf

start tibemsd –config tibemsd2.conf

Monitoring a Fault-Tolerant Pair

The EMS Administration Tool needs to connect to a particular instance, so start the Tool and for the connect string enter:

connect tcp://localhost:7222

Start up another instance, and change the connect string to:
connect tcp://localhost:7224

In this manner you will be able to see a client fail-over by issuing the “show connections” command.

Read more...

Enterprise Service Bus (ESB)

The characteristics of ESB are as follows:

The ESB is not just a transformation engine. While transformation is a core function of an ESB, it is not the only thing it does.

Its biggest value is to match and route messages and services, to convert between transport protocols and to manage and distribute business events. The idea of describing an ESB as a ‘proxy’ might be new to some people, but the message resonates well with customers.

Here the key point is that by having a proxy, you do not need to ‘hard-code’ connectivity logic directly into applications. This makes the application logic much more modular and allows you to swap out other applications according to the requirements.

Read more...

Web Services: WSDL Transmission Primitives

WSDL has four transmission primitives that an endpoint can support:

1. One-way. The endpoint receives a message.
2. Request-response. The endpoint receives a message, and sends a correlated message.
3. Solicit-response. The endpoint sends a message, and receives a correlated message.
4. Notification. The endpoint sends a message.
   

• Although the base WSDL structure supports bindings for these four transmission primitives, WSDL only defines bindings for the One-way and Request-response primitives.

• It is expected that specifications that define the protocols for Solicit-response or Notification would also include WSDL binding extensions that allow use of these primitives.

Read more...

Web Services: SOAP Fault

• SOAP Fault element is used to carry error, status information
• If present it must appear as Body entry and must not appear more than once with in Body element.
• It contains a faultcode, faultstring, faultactor and detail sub-elements. Former two are mandatory.
• The contents of faultcode is a QName from XMLSchema.
• The faultstring's content is a human-readable string.
• The fault actor element is intended to provide information about who caused fault to happen with in the message path
• The detail element is intended for carrying application specific error related to Body element. Its absence indicates fault is not related to processing of Body element.

Read more...

Synchronous Vs Asynchronous Web Services

Synchronous

• Client invoking the service waits for the response suspending its own processing.
• This architecture to be used when the service can process the request in a small amount of time.

Asynchronous

• After sending the request, client goes on with its own processing. When a response comes it resumes whatever processing initiated the service request.
• Can be implemented using message queues (JMS, MQSeries)

Read more...

WebServices: SOAP Message Structure

Envelope: Envelope is the root of the SOAP request. defines the XML document as a SOAP message and it contains the header and body element.

Header: Header contains auxiliary information, as SOAP blocks, such as authentication, routing information, or transaction identifier. The header is optional.

Body: Body contains the main information in one or more SOAP blocks. An example would be a SOAP block for RPC call. The body is mandatory and it must appear after the header.

Fault: Fault is a special block that indicates protocol-level errors. If present, it must appear in the body.

To Invoke a Web Service we should know the following things before going ahead.

1. The endpoint (target address) of the service
2. Exposed methods by the web service
3. Signature of the methods (Expected input-output parameters and types)
4. SOAP libraries which can serialize our invocation to a SOAP request and desterilize the SOAP response to desired return type.

Read more...

THROUGHPUT CONSIDERATIONS: TIBCO BW Engine parameters, HTTP parameters.

Throughput of the BusinessWorks engine is the rate at which the engine can execute and complete processes. The throughput of the engine is determined by factors that can be grouped into:
• Engine parameters
• HTTP parameters

Engine Parameters:

Thread Count: ThreadCount specifies the number of process instances (jobs) that can be executed concurrently by BusinessWorks engine. By default, the thread count is 8.

Step Count: It specifies the number of tasks that are executed successively by a thread before it is released.

HTTP Parameters:

minProcessors: Specifies the number of threads created when the HTTP Server is started. These threads process HTTP requests. The default value of this property is 10.

• Setting a high value for minProcessors can produce a large number of excessive threads and hence block the system resources.

maxProcessors: Specifies the maximum number of threads that can be created by the HTTP Server to process incoming HTTP requests. The default value of this property is 75.

• Setting a low value for maxProcessors results in the following:

1. limiting the number of threads in the system and therefore limiting the number of requests that can be processed simultaneously.
2. reduced memory contention.
3. Less number of context switches.
4. Increased throughput.

• Setting a high value for maxProcessors results in the following:

1. More number of requests can be processed simultaneously.
2. Degraded throughput for all the processes.

acceptCount: Specifies the maximum number of incoming connection requests that can be accepted when all HTTP processors are in use.
• Incoming requests received after the acceptCount limit is reached are rejected.
• The default value for acceptCount is 100.

Enable DNS Lookups: Checking this field enables a Domain Name System (DNS) lookup for HTTP clients so that the IP address is resolved to a DNS name.

Read more...

TIBCO BW Performance Tuning by JVM parameters

Every BusinessWorks engine runs in a Java Virtual Machine. As a result, the settings on the JVM influence the engine performance. Java provides below parameters to tune the memory usage and optimize engine performance.

i. HEAP SIZE:

Following parameter used to set the heap size in bwengine.tra, designer.tra files for the engine:

Example: tibco.env.HEAP_SIZE=256M

These values determine the amount of memory to be used by the engine.

ii. GARBAGE COLLECTION:

• The java object, such as a job, occupies memory from the time it is created to the time it is destroyed. Java provides garbage collection, an automated mechanism to clean up objects that still exist but are no longer used.

• To retrieve the garbage collection metrics for the BusinessWorks engine, specify the -verbose:gc option when starting the JVM used by the engine.

• You can set the Java memory parameters by using the java.extended.properties option in the bwengine.tra file.

For example, specify the following in the bwengine.tra to set the heap size to 512M and retrieve the garbage collection metrics for the engine.

java.extended.properties -Xms512m -Xmx512m -verbose:gc

Read more...

What are the types of grouping or group actions in TIBCO BW?

Grouping Activities - Type of Group Actions in tibco bw.

• None: Used for grouping without looping
• Transaction Groups: Used to group activities that participate in a transaction. Eg. JDBC group activities
• Iterate Loop: Used to iterate a group once for every item in a list
• Repeat Until True Loop: Used to iterate a group until the specified condition is true
• Repeat On Error Until True Loop: Used to iterate a group when an error occurs
• If Groups: To conditionally execute business logic
• While True Groups: Repeats the series of grouped activities as long as the given condition evaluates as true.
• Critical Section: Used to synchronize process instances so that only one process instance executes the grouped activities at any given time.
• Pick First: Allow process execution to wait for one or more events

Read more...

Secure Sockets Layer (SSL) protocol

1. Secure Sockets Layer (SSL) is a protocol that provides secure authentication and transmits encrypted data over the Internet or an internal network.

2. TIBCO Enterprise Message Service supports the Secure Sockets Layer (SSL) protocol.

3. SSL uses public and private keys to encrypt data over a network connection to secure communication between pairs of components:

• between an EMS client and the tibemsd server


• between the tibemsadmin tool and the tibemsd server


• between two routed servers


• between two fault-tolerant servers

4. Digital certificates are data structures that represent identities. EMS uses certificates to verify the identities of servers and clients. A digital certificate is issued either by a trusted third-party certificate authority, or by a security officer within your enterprise.

5. JMS Java clients can use either JSSE (from Sun JavaSoft) or the SSL implementation from Entrust.

Read more...

TIBCO ActiveMatrix BW interview questions

Hi Folks,

To read the topics on TIBCO's product called "TIBCO ActiveMatrix BusinessWorks"(BW) and interview questions Click on TIBCO BW Interview questions.

keep in touch with this blog for daily updates.

Read more...

Administered Objects: JMS Connection Factories

1. JMS clients access the destinations and connection factory objects through interfaces that are portable, so a client application can run with little or no change on more than one implementation of the JMS API.

2. Ordinarily, an administrator configures administered objects in a Java Naming and Directory Interface (JNDI) API namespace, and JMS clients then look them up, using the JNDI API. J2EE applications always use the JNDI API.

Connection Factories:

1. A connection factory is the object a client uses to create a connection with a provider. A pair of connection factories come preconfigured with the J2EE SDK and are accessible as soon as you start the service.

2. Each connection factory is an instance of either the QueueConnectionFactory or the TopicConnectionFactory interface.

3. We can use the default connection factory objects, to create connections.

4. At the beginning of a JMS client program, perform a JNDI API lookup of the connection factory.

Read more...

What is JMS API & when we can use JMS?

1. Messaging is a method of communication between software components or applications.

2. JMS API allows applications to create, send, receive, and read messages.

Messaging could be Synchronous, Asynchronous and Reliable types.

Synchronous: A client that waits for the server to respond to a message.
Asynchronous: A client does not have to request server in order to receive message.
Reliable: Can ensure message is delivered safely once and only once.

Circumstances When We can Use JMS :

1. The provider wants the components not to depend on information about other component's interfaces, so that components can be easily replaced.

2. The provider wants the application to run whether or not all component sare up and running simultaneously.

3. The application business model allows a component to send information to another and to continue to operate without receiving an immediate response.

To know about TIBCO Enterprise Message Service (EMS) which is fully compliant Java Message Service (JMS) Click here.

Read more...

TIBCO EMS interview questions

Hi Folks,

Know about TIBCO EMS and best EMS interview questions here. It updates daily.

Click on TIBCO EMS Interview questions.

Read more...

Persistent Messages Sent to EMS Queues & Topics

Persistent Messages Sent to Queues

Persistent messages sent to a queue are always written to disk. Should the server fail before sending persistent messages to consumers, the server can be restarted and the persistent messages will be sent to the consumers when they reconnect to the server.

Persistent Messages Sent to Topics

Persistent messages published to a topic are written to disk ONLY IF that topic has at least one durable subscriber or one subscriber with a fault-tolerant connection to the EMS server.

Non-durable subscribers that re-connect after a server failure are considered newly created subscribers and are not entitled to receive any messages created prior to the time they are created.

Read more...

What is the use of Message Selectors in Tibco EMS

1. A message selector is a string that lets a client program specify a set of messages, based on the values of jms message headers and properties.

2. A selector matches a message if, after substituting header and property values from the message into the selector string, the string evaluates to true.

3. Consumers can request that the server deliver only those messages that match a selector.

For more EMS FAQs and topics Click here.

Read more...

Setting Exclusive property to Tibco ems queue

1. What is the use of exclusive property?

When exclusive is set for the queue, the server sends all the messages on that queue to one consumer. No other consumer can receive messages from the queue.

Instead, these additional consumers act in a standby role; if the primary consumer fails, the server selects one of the standby consumers as the new primary and begins delivering messages to it.

2. Can we set this property to Topics?

No, This property available only for queues.

3. How to set exclusive property to ems queue?

Set the exclusive property using addprop or setprop in tibemsadmin tool.

Read more...

TIBCO EMS: When would you use EXPLICIT_CLIENT_ACKNOWLEDGE ?

EXPLICIT_CLIENT_ACKNOWLEDGE is like CLIENT_ACKNOWLEDGE except it acknowledges only the individual message, rather than all messages received so far on the session.

When EXPLICIT_CLIENT_ACKNOWLEDGE would be used ?

When we receive the messages and put their information in a database and if the database insert operation is slow, you may want to use multiple application threads all doing simultaneous inserts.

As each thread finishes its insert, it can use this mode to acknowledge only the message that it is currently working on.

For EMS message delivery modes Click here.

Read more...

TIBCO JMS Message Compression

What is message Compression...?

• TIBCO Enterprise Message Service allows a client to compress the body of a message before sending the message to the server.
• Compression option only compresses the BODY content. Headers and properties are NEVER compressed.
• Compression is specific for individual messages. Not on a per-queue or per-topic basis.
• EMS supports message compression/decompression across client types (Java, C and C#). For example, a Java producer may compress a message and a C consumer may decompress the message.
• Message compression is supported in .NET clients when using the install package for Visual C++ 8 / .NET 2.0 or above.

What is the advantage of Message Compression...?

• Less memory storage for PERSISTENT queue messages or DURABLE topic subscribers.

How to add compression property to message...?

• set JMS_TIBCO_COMPRESS to TRUE

When messages are not stored, compression is not a good option. Why?

• Because, Compression takes TIME…!

Read more...

Configuring Generate Error activity and its usage

Usage: If you would like to catch and raise your own error conditions, you can use this activity. This activity generates an error and causes an immediate transition to any error transitions. If there are no error transitions, the process instance halts execution.

Steps to configuring Generate Error activity to raise your own exception

• Create Error Schema under Error Schema tab in your END activity (each process definition consists START and END activity), then check under generate error activity you will see the schema which you created.


• Map the process data to this schema or write conditions to evaluate to true so that exception will rise as expected.

Read more...

Steps to configure Fault Tolerance mode in TIbco Admin GUI

1. Create an EAR file using Tibco Designer.
2. Using Application Management, click New Application to Browse and upload the ear file into Tibco administrator GUI.
3. Go to Configuration(Application's) and click on process archive.
4. Click on 'Add to Additional Machines' in General tab to select the machine name. when you add, the FT section (Run Fault Tolerant) will be enabled in FT Group Settings.
5. Specify the weights to the process instance in FT Weight and time intervals in FT Group Settings.
6. Using Monitoring tab, we can add Rulebases and Events if needed.
7. Save and Deploy.
8. In Service Instances, we observe that one instance gets started in active mode and another would be in Standby mode by starting the application

Read more...

General steps to develop inter-process communication

To know what is Inter-process communication or use of Wait & Notify activities Click here

1. Define the data that must be passed between the processes by creating a Notify Configuration shared configuration resource.


2. Determine the key that correlates processes with Notify activities with the corresponding processes with Receive Notification process starters or Wait activities.


3. Create process definitions that use the Receive Notification, Wait, and Notify activities. These activities are located in the General Activities palette.


4. If your process engines are on different machines, a database must be used to store process instance information. Wait/Notify information is stored in a database so that process engines on different machines can share information.

Read more...

How process instances can communicate? What is the use of Wait & Notify activities? What is inter-process communication?

TIBCO BusinessWorks allows two executing process instances to communicate. You may need process instances to communicate if you wish to synchronize process execution or if your processes must execute in a specific order.

TIBCO BusinessWorks provides the Wait and Notify activities and the Receive Notification process starter to handle inter-process communication. A process containing a Wait activity waits for another process to execute a corresponding Notify activity. Alternatively, the Receive Notification process starter creates a new process instance when another process executes the corresponding Notify activity.

The data sent between the activities is defined by a Notify Configuration shared configuration resource. The Notify activity only sends information to the Receive Notification process starter or Wait activity that specifies the same Notify Configuration resource.

If you wish only to signal the waiting process to continue but not exchange data, the Notify Configuration schema used by the Notify/Receive Notification/Wait activities can be empty.

To know the steps to develop Inter-process communication click here

Read more...

Steps to Configure Service activity as Web Server in Web Service Implementation

Before creating a Service resource, you will need to create the following resources:

• A WSDL file that contains an abstract interface description. The interface can include one or more operations.
• Process definitions will provide the implementation for each operation in the service’s interface. You can specify the same process definition for more than one operation.
• Either an HTTP Connection or JMS Connection shared configuration resource that specifies the transport used by clients of the service.

To configure a Service resource, follow these general steps:

1. Provide an abstract WSDL(Input, OutPut & type of operation) file that describes the interface to the service.
2. For each operation in the interface, specify a process definition that implements the operation.
3. Specify one or more endpoint bindings to expose the service to potential clients.
4. For each endpoint binding, specify a transport configuration (either HTTP Connection or JMS Connection).
5. Specify any transport-specific information, such as endpoint URL for HTTP transports or JMS Destination Name for JMS transports.
6. Specify any SOAP details, such as SOAP Version or encoding for each operation.
7. Specify attachments, headers, or context information for input and output messages, if necessary.

Read more...

Difference between JMS Queue Receiver & Get JMS Queue Message activities

JMS Queue Receiver:

1. It is a process starter activity. It continues to poll destination queue to start the execution of process definition.
2. After BusinessEngine started, a new process instance will be created for every single message it received.
3. It has only static selector option to configure. That means we can filter all the messages with one selector value only. If you wish to filter messages with different selector values you would need to create more process definitions with JMSQueue reciver.

Get JMS Queue Message:

1. It is NOT a process Starter activity. We could place this activity between starter and end activity of process definition. This activity executes only when its triggered.
2. It executes all the queue messages in a single process instance and retrives one message at a time even more messages on the queue.
3. It has both dynamic and static selectors. With a dynamic selector, one would be able to change the selector value for every message in the queue.

Read more...

TIBCO BusinessWorks log4j File

The standard log4j logging service is available for components of TIBCO BusinessWorks. The log4j is the logging infrastructure developed by the Apache group, and is separate from the standard TIBCO logging infrastructure. For more information, please see http://logging.apache.org/log4j/docs/index.html

Custom java code (BusinessWorks JavaCode or JavaMethod activity) can send log message to the TIBCO BusinessWorks log file by using the log4j logger "bw.logger" that is specified in log4j property file and its located at (BW_HOME\5.x\lib\log4j.properties).

For example, TIBCO BusinessWorks JavaCode activity may use the following code to log warning message to the BusinessWorks log file:

org.apache.log4j.Logger logger = org.apache.log4j.Logger.getLogger("bw.logger"); logger.warn("This is a warning message from BW JavaCode activity");

If you use your own logger class, you can configure the TIBCO BusinessWorks log4j properties file to include your logger. This involves adding log4j.logger and log4j.appender properties to the properties file.

Do not move this file from its current location (BW//lib), as this is where BW expects to find this file. If you would like to use a different file in a different location please see the BW documentation.

Read more...

Graphical user interface utility for EMS- GEMS 3.2 & Software

Gems is a graphical user interface utility for TIBCO Enterprise Message Service (EMS). It can be used by JMS developers as a general purpose test debugging tool and by administrative support staff as a management and monitorig tool.

Gems provides the following main features:

• Server Monitoring- Server state and main statistics are automtically updated, warning and error limits may be configured. Server generated events are also captured.
• Server Management- Including, general server configuration, JMS destinations, JNDI factories, users/groups, permissions, bridges, routes etc.
• JMS support- Messages may be sent/received, queues may be browsed and message contents inspected. Selectors and filters may be specified.
• JMS Message Monitoring- Messages may be monitored (snooped) as they pass trough the server. Request and reply messages can be correlated to provide service response times.
• JMS Message Management- Eg; purging messages, copy messages from a queue to another queue on a different server.
• Charting- Server statistics may be charted in real time, data may be saved to CSV files for export to other tools such as Excel.
• Logging- Server statistics may be logged automatically when warning or error limits are breached.
• Security- SSL connectivity, view only mode.

To get GEMS software click Here.

Read more...

TIBCO ActiveMatrix Service Grid- Key Features

• Provides a unified design-time and runtime service framework. Eliminates the need for technology-dependent “wrapper code” for services enablement.
• Enables companies to dynamically deploy services across machines or co-locate them within an OS process, move services to different machines, and add distributed load balancing and fault tolerance.
• The distribution and number of service instances in the grid can be scaled dynamically based on the real-time load and service level agreement using TIBCO ActiveMatrix® Service Performance Manager.
• Embeds TIBCO ActiveMatrix® Service Bus – a lightweight enterprise service bus that helps organizations bridge the mediation gap within their SOA infrastructure, reducing complexity and increasing flexibility.
• Provides a common Eclipse-based environment for service development, assembly, composition, and testing, and a common web-based console for monitoring and management. It reduces operational cost with built-in governance.

Read more...

TIBCO ActiveMatrix Service Grid- Overview

TIBCO ActiveMatrix® Service Grid simplifies heterogeneous SOA by enabling IT organizations to turn their business logic into services and graphically assemble, deploy, host, manage, and monitor these services together as composite applications on a unified runtime foundation.

• Allows developers to focus on the business logic by replacing 20 to 40 percent of the technical code in a service with centralized configuration.
• Reduces architectural complexity by providing a grid- and standards-based, technology-neutral platform with service containers for .NET/C#/VB/WCF, C++, Java, Ruby, and other service technologies.
• Leverages open standards like SCA, with an Eclipse-based environment for service development, composition and assembly, and OSGi-based runtime.
• Provides built-in governance support, allowing you to add governance without impacting existing work.

Read more...