The Land Of Tibco

Configuring TIBCO EMS: Load Balancing

2011-12-18T03:22:00.000-08:00

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

Configuring TIBCO EMS: Fault-Tolerance

2011-12-04T04:08:00.000-08:00

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.

Enterprise Service Bus (ESB)

2011-11-26T08:34:00.000-08:00

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.

Web Services: WSDL Transmission Primitives

2011-08-21T04:15:00.000-07:00

WSDL has four transmission primitives that an endpoint can support:

One-way. The endpoint receives a message.
Request-response. The endpoint receives a message, and sends a correlated message.
Solicit-response. The endpoint sends a message, and receives a correlated message.
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.

Web Services: SOAP Fault

2011-08-07T05:12:00.000-07:00

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.

Synchronous Vs Asynchronous Web Services

2011-07-31T03:24:00.000-07:00

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)

WebServices: SOAP Message Structure

2011-07-24T06:16:00.000-07:00

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.

THROUGHPUT CONSIDERATIONS: TIBCO BW Engine parameters, HTTP parameters.

2011-07-10T07:02:00.000-07:00

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.

TIBCO BW Performance Tuning by JVM parameters

2011-06-26T09:13:00.000-07:00

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

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

2011-06-12T09:21:00.000-07:00

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

Secure Sockets Layer (SSL) protocol

2011-05-22T03:27:00.000-07:00

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.

TIBCO ActiveMatrix BW interview questions

2011-05-22T03:03:00.000-07:00

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.

Administered Objects: JMS Connection Factories

2011-05-15T04:20:00.000-07:00

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.

What is JMS API & when we can use JMS?

2011-05-07T21:54:00.000-07:00

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.

TIBCO EMS interview questions

2011-05-07T04:15:00.000-07:00

Hi Folks,

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

Click on TIBCO EMS Interview questions.

Persistent Messages Sent to EMS Queues & Topics

2011-04-24T06:42:00.000-07:00

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.

What is the use of Message Selectors in Tibco EMS

2011-04-17T05:07:00.000-07:00

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.

Setting Exclusive property to Tibco ems queue

2011-04-10T05:33:00.000-07:00

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.

TIBCO EMS: When would you use EXPLICIT_CLIENT_ACKNOWLEDGE ?

2011-03-27T01:42:00.000-07:00

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.

TIBCO JMS Message Compression

2011-03-20T05:41:00.000-07:00

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…!

Configuring Generate Error activity and its usage

2011-03-13T05:09:00.000-07:00

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.

Steps to configure Fault Tolerance mode in TIbco Admin GUI

2011-03-06T09:10:00.000-08:00

Create an EAR file using Tibco Designer.
Using Application Management, click New Application to Browse and upload the ear file into Tibco administrator GUI.
Go to Configuration(Application's) and click on process archive.
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.
Specify the weights to the process instance in FT Weight and time intervals in FT Group Settings.
Using Monitoring tab, we can add Rulebases and Events if needed.
Save and Deploy.
In Service Instances, we observe that one instance gets started in active mode and another would be in Standby mode by starting the application

General steps to develop inter-process communication

2011-02-26T09:23:00.000-08:00

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

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

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

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

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.

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

2011-02-20T02:22:00.000-08:00

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

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

2011-02-13T09:29:00.000-08:00

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:

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

Difference between JMS Queue Receiver & Get JMS Queue Message activities

2011-02-05T22:09:00.000-08:00

JMS Queue Receiver:

It is a process starter activity. It continues to poll destination queue to start the execution of process definition.
After BusinessEngine started, a new process instance will be created for every single message it received.
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:

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.
It executes all the queue messages in a single process instance and retrives one message at a time even more messages on the queue.
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.

TIBCO BusinessWorks log4j File

2011-01-30T03:23:00.000-08:00

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.

Graphical user interface utility for EMS- GEMS 3.2 & Software

2011-01-23T01:52:00.000-08:00

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 on Tibcommunity.

TIBCO ActiveMatrix Service Grid- Key Features

2011-01-16T04:07:00.000-08:00

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.

TIBCO ActiveMatrix Service Grid- Overview

2011-01-09T02:01:00.000-08:00

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.

Web Service Wizards-2: Creating Process Definition Stubs From a WSDL File

2010-12-18T20:49:00.000-08:00

When we use this Web Service wizard...? To know click here

To create a service resource and process definition stubs from a WSDL file, perform the following procedure:

Place the WSDL file in your project directory.
If your project is not open, open your project in TIBCO Designer. If your project is already open in TIBCO Designer, choose Resources > Refresh from the menu
Create a transport shared configuration resource (either HTTP Connection or JMS Connection) to use as the transport for the web service.
Select and right-click on the name of the WSDL file in the project tree.
Choose Tools or Multi-User > Generate Web Service > From WSDL from the pop-up menu. The WSDL to Process dialog appears.
Review the values for the fields in the WSDL to Process dialog. The default values may be sufficient for your purposes, or you may wish to change the values.
Click Generate to create a Service resource and process definition stubs for the operations in this WSDL file. The Service resource is named (interfaceName)-service and the process definition stubs are named (portType)(operationName). The service and process definition stubs are placed in the location specified in the WSDL to Process dialog.
Click the (interfaceName)-service resource in the project tree to display the service. Ensure the endpoint bindings are specified correctly. For HTTP transports, you may need to specify the Endpoint URI. For JMS transports,you must specify the destination name and other JMS configuration information.
Click on each process definition stub and provide the implementation for each operation by completing the process definition for the operation.

Web Service Wizards-1: Creating Web Services From Process Definitions

2010-12-12T04:19:00.000-08:00

When we use this Web Service wizard...? To know click here

Procedure To create a service resource and WSDL file from one or more process definitions

Open a project in TIBCO Designer and create one or more process definitions that implement operations you wish to expose as web services. The input,output, and error schemas for each process definition must be specified as WSDL messages.
Create a transport shared configuration resource (either HTTP Connection or JMS Connection) to use as the transport for the web service.
Select and right-click on the name of one of the process definitions in the project tree.
Choose Tools or Multi-User > Generate Web Service > From Process from the pop-up menu.The Generate Web Service dialog appears.
Review the values for the fields in the Generate Web Service dialog. The default values may be sufficient for your purposes, or you may wish to change the values.
Click Generate to create a Service resource and WSDL file for the selected process definitions.The Service resource is named intf(processDefinitionName)-service and the WSDL file is named intf(processDefinitionName).
Click the intf(processDefinitionName)-service resource in the project tree to display the service. Ensure the endpoint bindings are specified correctly. For HTTP transports, you may need to specify the Endpoint URI. For JMStransports, you must specify the destination name and other JMS configuration information.

Web Service Wizards

2010-12-05T07:59:00.000-08:00

TIBCO BusinessWorks provides two wizards for easily creating web services. The two wizards are useful in the following situations:

you wish to expose one or more process definitions as web services.
you have a WSDL file describing the interface to a web service and you wish to quickly create the process definition stubs that will implement the operations in the interface

Wizard 1: Creating Web Services From Process Definitions

Wizard 2: Creating Process Definition Stubs From a WSDL File

Will describe about these wizards in the next posts.

General procedure to create Web service in TIBCO

2010-11-20T09:20:00.000-08:00

Create XSDs to define the input, output, and fault messages for the web service.
Create a WSDL File resource that defines the interface to the web service.
Create a process definition that performs the work of the web service. Use the SOAP Event Source process starter for this process definition. Use the SOAP Send Reply activity to return a reply or the SOAP Send Fault activity to return a fault to the client.
Create a process definition that retrieves the concrete WSDL file and sends it to web service clients. Use the HTTP Receiver process starter and the Retrieve Resources activity for this process definition.

Redeploying an Application: Changes Made to EAR and Deployment Files

2010-11-14T01:42:00.000-08:00

If you change both the TIBCO Designer project and the deployment configuration file, you must upload both when redeploying. For example, you may want to make the following changes:

add new services or delete existing services (adapter, process or form flow archives)
add or remove deployment level or service level variables (including Adapter SDK properties)
change checkpoint storage from File to JDBC or JDBC to JDBC, where the new JDBC Shared Resource was not part of the Shared Archive in the original EAR file

If you have changed both the TIBCO Designer project and the deployment configuration file, complete the following steps to redeploy the changed application:

Build an EAR file using the buildear utility. For example:buildear -s -ear /filenotify.archive
Generate a new deployment configuration file using the EAR file created in the previous step, the deployment configuration file used when previously deploying the application and specify a new deployment configuration file.
After you have made the changes to your deployment configuration file, you are ready to deploy the application.

Starting & Stopping Applications in Batch Mode

2010-10-31T03:30:00.000-07:00

The following command starts all applications specified in the AppManage.batch file that is located in the directory specified for the -dir option. The directory must have been created earlier using the -batchExport option.

AppManage -batchstart -domain mydomain -user admin -pw admin -dir c:\adminbatch\mybatch\

The following command stops all applications specified in the AppManage.batch file that is located in the directory specified for the -dir option.

AppManage -batchstop -domain mydomain -user admin -pw admin -dir c:\adminbatch\mybatch\

AppManage in Batch Mode

2010-10-16T11:26:00.000-07:00

To use the AppManage utility in batch mode you must first create an AppManage.batch file. The file lists the applications and their corresponding EAR and XML files. You can create the file manually, but the files listed in the AppManage.batch file must be specified using relative file paths. The base of those relative paths is the directory specified by the –dir option that is given on the AppManage command line.

The easiest way is to generate the file using the -batchExport option. In addition to creating the AppManage.batch file, the option creates an enterprise archive file and XML file for each application in the given domain.

After creating the AppManage.batch file, you can use the AppManage utility to do the following operations in batch mode:

Deploy applications
Undeploy applications
Start or stop applications
Delete applications
Kill applications
Change the transport

How to start the AppManage and buildear utilities

2010-10-10T03:33:00.000-07:00

To start the AppManage utility, change directory to TIBCO_TRA_HOME\bin and type AppManage -action where options include -export, -upload, -config, -deploy, and -undeploy etc.

The AppManage utility must be run on a machine that is part of the administration domain you are updating.

Starting Buildear:

To start the buildear utility, change directory to TIBCO_TRA_HOME\bin and type

buildear -options.

You should verify your project by loading it into TIBCO Designer before you use the project with the buildear utility. If the project doesn't load correctly in TIBCO Designer, the buildear utility doesn't support it.

AppManage utility Log Files

2010-10-03T00:58:00.000-07:00

The AppManage utility writes information to a log file. The log file location depends on whether you are accessing an administration domain or not.

If you are not accessing an administration domain, the log is written to the TIBCO_TRA_HOME\logs\ApplicationManagement.log file.
If you are accessing an administration domain, the log is written to the TIBCO_TRA_DOMAIN_HOME\domain-name\logs\ApplicationManagement.log file.

A comparison log file is generated if you export from an EAR file without specifying an administration domain. This information can help you decide whether you need to change the deployment configuration file after an EAR filechanges.

For example, using the following command line, the AppManage utility compare sthe oldconfiguration.xml file with the given EAR file. If any service, global variables, or both have been added, removed, or updated, a log file is created in the same directory where the oldconfiguration.xml file resides, using the file name, oldconfiguration.xml.log.

AppManage -export -ear c:\ears\timer_wait.ear -deployConfig oldconfiguration.xml -outnewconfiguration.xml

Uses of AppManage utility in Scripting Deployment

2010-09-11T06:09:00.000-07:00

The AppManage utility creates an XML based deployment configuration file in which deployment options can be defined.
The utility also uploads the deployment file and EAR file into a TIBCO Administrator administration domain.
Create a deployment configuration file based on information in an EAR file, or from an application already configured in the TIBCO Administrator GUI.
Upload an EAR file to an administration domain without specifying deployment configuration options. After the file is imported, it is ready to be configured with deployment options and deployed using the TIBCO Administrator GUI.
Upload an EAR file and a deployment configuration file and deploy the application in one operation. Using this method, you can quickly deploy your applications in multiple domains.
Export all application archives and deployment configuration files within adomain, so they can be batch deleted, started, stopped, undeployed, or deployed in another domain. For TIBCO Rendezvous administration domains, you can change the transport set for application to administration server communication, from rv (Rendezvous) to local, or the reverse.
Undeploy a deployed application.
Delete an application from an administration domain.
Start a service instance of an application.
Stop a successfully deployed service instance of an application.

About AppManage Utility- Script deployment

2010-08-15T05:48:00.000-07:00

The scripting tools allow you to build an EAR file for an application configured in TIBCO Designer, then load the application into one or more TIBCO Administrator administration domains. Deployment options can be specified in a deployment configuration file that is created using the AppManage utility.

If your application is not complex and needs only machine bindings defined for each domain, you can use the AppManage utility to create the deployment configuration file from information in the EAR file, then edit the configuration file with the machine names where the applications will be deployed. In this scenario, the TIBCO Administrator GUI is not used.
If your application is complex and needs more than machine bindings defined, you can import an EAR file into the TIBCO Administrator GUI and specify deployment configuration options for the application. This method is preferred if your application includes complex mappings, such as fault tolerance, runtime variables, alerts and so on.

In this scenario, the TIBCO Administrator GUI is used to initially set the application’s deployment configuration options. After the options are set, the TIBCO Administrator GUI is no longer used. The AppManage utility updates the deployment configuration file from the application configured in the TIBCO Administrator GUI. The file is edited for each administration domain by changing machine bindings and so on, then deployed into each administration domain.

About Tibco Silver

2010-08-01T06:29:00.000-07:00

TIBCO Silver is the industry's first cloud application delivery platform for the enterprise.It enables organizations to quickly and cost effectively deliver business applications in a secure, well-governed and reliable environment that exploits the elasticity of the cloud.

The Independent Platform for Cloud Applications

TIBCO Silver was designed from the ground up to support cloud application delivery for Global 2000 enterprises. What this means to you is TIBCO Silver addresses all your reliability, scalability, and security challenges of cloud computing for the enterprise regardless of the underlying infrastructure.

Scaling to Meet Business SLAs
TIBCO Silver leverages TIBCO's event-driven middleware to sense and respond to changes in application usage.

Bridging the Security Gap
TIBCO Silver provides an agile infrastructure that delivers governance where and when you want it. This means you are in control and it never gets in the way.

What Is tibbr?

2010-07-25T11:07:00.000-07:00

tibbr™ is the first communication tool specifically built for the workplace that allows the right information to find you.

Unlike social networking applications that focus on the concept of “following people,” tibbr is the first to take an entirely new approach to social computing by allowing you to follow subjects too.

This subject-based approach allows a greater degree of flexibility in what information a user needs and wants to receive at precisely the right time.

TIBCO HAWK: About Alert messages

2010-07-18T08:01:00.000-07:00

Alert messages originate from a rulebase that implements the monitoring policy or logic. When a specified condition occurs, the agent publishes an alert message to the TIBCO Hawk Display and presents it by colors to show the severity of the alert.

It uses colors such as red for high alert, orange for medium alert, yellow for low alert, cyan if it’s recovering, green if it’s ok and purple for no heartbeat. These colors are default to the Hawk Display but it also allows you to change them based on your own preference.

You can also suspend an alert message that will be temporarily neutralized to prevent it from interfering with other monitoring tasks. If ever a condition ceases, these alerts will be cleared or removed in the Display.

TIBCO HAWK: Rulebase scheduling

2010-07-11T06:56:00.000-07:00

Rulebase scheduling allows you to create a schedule that defines when a rulebase, rule, test or action is active or not. These schedules can be imposed on the rulebase to control the monitoring activity and performing corrective tasks.

You can define and assign a schedule using the TIBCO Hawk Display, which must be saved on a file so that it can be assigned later on to one or more agents and can be applied to any rulebase objects.In creating a schedule, you can also specify inclusion and exclusion periods. For example, you can set a rulebase to be activated only during office hours and be deactivated during holidays.

About hawk rulebases

2010-07-04T05:55:00.000-07:00

Rulebase refers to a collection of rules that controls the monitoring conducted by the agents, which can be created or modified using the rulebase editor in the TIBCO HAWK Display.
It uses a microagent method as a data source to create one or more tests.
These tests use If/else construct to check the conditions and includes action if the condition evaluates to true.
An action, can be sending an alert or notification messages, execute an OS command, creating post condition, or invoking another microgent method.

Application Management Interface

2010-06-27T08:43:00.000-07:00

Application Management Interface (AMI) is a gateway between the external applications and Hawk System that uses RV Messaging to communicate. It is used as a protocol in instrumenting an application with a management interface that allows the application to be monitored and controlled by exposing internal application methods to the TIBCO Hawk system.

Difference between the Hawk Microagent and Application Microagents

2010-06-20T09:27:00.000-07:00

Hawk Microagents are default microagents residing on your local machine to monitor system’s health and statistics. Hawk Microagents can be a platform-specific or platform-independent microagent. It means that every platform has its own specific microagent or it has microagents that are default to any platform.

The Application Microagents, on the other hand, are microagents that are specifically created or coded to monitor the application statistics. Only those applications that use AMI are dynamically discovered by the Hawk System and represented by microagents that enables those applications to be managed and monitored.

How does TIBCO Hawk agent operates?

2010-06-13T08:08:00.000-07:00

The Hawk agent uses microagents as an object to represent and interact with the managed object in your local machine. Then, the agent loads the rulebases as monitoring policies to monitor your system or your applications.

It uses RV Messaging to communicate with the microagents, and uses EMS or RV messaging to communicate with other agents, Event Service and Hawk Display. It also communicates using instances of TIBCO Hawk Display but it works independently with the Display and other agents.

Features of TIBCO Hawk Event Service

2010-06-06T09:57:00.000-07:00

The TIBCO Hawk Event Service does not only record the activity of TIBCO Hawk agents but it also logs and subscribes to all TIBCO Hawk system events such as agent activation and expiration, microagent and rulebase changes, alerts and clears.

The external applications must be saved on a data file in order for them to access the logs. If ever there is an expired or non-communicating agent in the network, the Event Service provides the use of a user-supplied script to notify the system administrator.

About TIBCO Hawk Display

2010-05-30T10:29:00.000-07:00

The TIBCO Hawk Display is a local window for all the activities in the network, which provides a graphical user interface used for viewing active agents in the network. It displays container icons that are created for each agent and arranged in clusters. These agent icons are, by default, clustered according to subnets. It also allows you to customize container icons and to convey added information that can be useful for your monitoring. Menus and dialogs are provided for you to create, modify and distribute rulebases to any agent present in the network. You can also invoke a microagent method that allows you to view the results immediately.

TIBCO Hawk system architecture

2010-05-23T08:48:00.000-07:00

There are two major components that make up the TIBCO Hawk System: Agents and Console Applications.

Agents reside on each computer in the network and perform monitoring and managing duties. It uses rulebases as a monitoring policy and microagents to extract monitoring information and to carry-out specified tasks.

The Console Applications, on the other hand, can be further divided into three subcomponents: the TIBCO Hawk Display that provides the interface to monitor and manage agent behavior in your network, the Event Service that records and logs all the activities of the agent, and the bridges to other management systems.

About TIBCO HAWK

2010-05-16T10:42:00.000-07:00

TIBCO Hawk is a network monitoring and management software for distributed systems and applications in the enterprise. It is designed using the concept of an independent smart agent that runs on each node in the network to monitor local conditions, so there is no need for a centralized monitoring console or frequent pooling across the network that can consume more bandwidth or cause network traffic.

One of the advantages of using TIBCO Hawk is that it uses less bandwidth while monitoring every machine in the network. It is because TIBCO Hawk distributes the monitoring load to each machine that has locally installed Hawk agents in order to conserve system resources and network bandwidth. The system administrator has now the capability to monitor the operating system, the application parameters and behaviors of each machine in the network using only less bandwidth. Another great advantage of TIBCO Hawk is that, in case of network failure, the Hawk agents will continue to perform local tasks because each agent operates independently from the other.

One of the benefits of using TIBCO Hawk is that it reduces sudden or unexpected system outages and slowdowns. TIBCO Hawk has this capability to automatically repair failures and slowdowns within seconds of detection and it also allows problems to be found and fixed before any slowdowns and failures can occur.

Business Process Management( BPM) and its activities

2010-05-08T10:47:00.000-07:00

Business Process Management(BPM) is simply the management of your business processes. It is a simple yet a powerful concept that helps you increase the efficiency of your business processes. It is a combination of processes and technology. It improves the execution and monitoring of processes. These processes may involve the tasks between two persons, a person and an application or between two applications.

Activities of BPM:

First is the modeling of business processes. This is where you create a flow of your process. You analyze the sequence and model it based on your working environment. Next is the deployment of your created model. The business process model that you create will be deployed so that it will be ready for execution. After that is, the execution where the process is already being used. The process is in action and users can already interact with the application. The last one is the monitoring and maintenance of the application. Monitoring the output and maintaining the processes are essential to every application.

Advantages of iProcess Suite

2010-05-02T02:48:00.000-07:00

It can accept any type of business process flow.
Simplifies complex business processes.
Offers full visibility of business flow across the entire enterprise.
It reduces the time consumed in managing the processes.
It increases the speed of execution of each process.

Another advantage of using this software is that humans and system tasks work hand in hand. For example, if a certain company orders a large amount of items that costs a large amount of money to an iProcess user company, it is a bit inappropriate for the system to comply with that order automatically, so an authentication of the manager or supervisor is needed first before the compliance of the order. It offers excellent flexibility to business changes. Rules and regulations of a business firm can change anytime. IProcess Suite can easily adjust to these new rules with ease.

TIBCO iProcess Conductor

2010-04-25T09:49:00.001-07:00

Business processes are prone to unavoidable circumstances that might change how a business process will flow. Because of this complexity, TIBCO iProcess™ Conductoris created. Business applications that are already deployed in the iProcess Engine can dynamically be modified using this tool. There might be inevitable changes that would happen during the runtime of the processes, which need to be taken into account immediately. In that case, this tool is the best choice to do the job.

TIBCO iProcess Decisions and TIBCO iProcess Engine

2010-04-18T08:00:00.000-07:00

TIBCO iProcess™ Decisions:

Every business is accompanied by business rules. These rules are important and should always be followed. At a certain time, rules in businesses can change. For the management to easily adapt to these new rules, TIBCO iProcess™ Decisions provides us with a spreadsheet user interface that handles these rules. This tool has a user friendly environment that even non-technical personnel can use to modify, test and analyze business rules. It has an excellent flexibility to respond to fast changing business rules.

TIBCO iProcess™ Engine:

TIBCO iProcess™ Engine is responsible for the execution of the business processes. All business models are deployed in this engine. It is the one that makes sure that the processes are running. Users and Administrators are connected to this engine. This engine is also responsible for the cases, tasks and instances created by the users and the administrators.

Experience increase in productivity, save cost and achieve efficient business flow. TIBCO iProcess Suite is a powerful business process management tool that will definitely benefit you and your company.

About TIBCO iProcess Client

2010-03-27T06:34:00.000-07:00

The TIBCO iProcess Client is the single focal point for defining and managing procedures.

The TIBCO iProcess Client consists of:

The Work Queue Manager
The Procedure Manager

The Work Queue Manager displays user's queues and work items and the Procedure Manager displays all of the procedures currently available.

From the Procedure Manager, you can:

create and edit procedures. The TIBCO iProcess Modeler is started from theTIBCO iProcess Client.
organize and manage your procedures as a hierarchical structure of procedure libraries, in the same way as, for example, you manage files and directories.

Integrate your own custom functions with TIBCO BusinessEvents

2010-03-21T04:34:00.000-07:00

TIBCO BusinessEvents allows you to write your own custom functions in Javaand add them to the function registry, making them available from within thefunction registry along with the prepackaged functions in the rule editor.The steps below summarize the tasks required to integrate your own customfunctions with TIBCO BusinessEvents:

Write your custom static function in Java and compile it.
Create functions.catalog, an XML file that makes it possible to access yourcustom functions from the functions registry within the rule editor. The XMLcan also include information for a tool tip for each function.
Create a .jar file that includes your .class file and functions.catalog.
Add the location of the .jar file to the class path for the BusinessEventsServer and Workbench. Also add locations for any dependent classes.

BusinessEvents: Validating a Decision Table

2010-03-13T03:55:00.000-08:00

Validate the decision table before testing or committing it to RMS. To validate,from Table menu, select Validate. If there are any access control violations orsyntax errors in the tables, they are shown in the Problems View tab at the bottomof the application. Take corrective actions and then validate the table again untilall errors are resolved.

NullPointerExceptions are silently ignored when a condition throws such anexception because you passed a null String to a function that does not check fornull, or because you accessed a property of a null contained concept(parent.child.property and child is null).

If a condition table cell is empty, it is skipped and thus considered to be evaluatedas true.

While working on the decision project, you can create multiple virtual rulefunction implementations by creating multiple decision tables. However, before committing the decision project to RMS, you should only commit one decisiontable per virtual rule function. During testing you can have multiple tables so youcan decide which ones to deploy to the engine and test. However, if you commitall implementations, only the last one will take effect if all of them are deployed.

BusinessEvents:Importing a Decision Table from a Microsoft Excel File

2010-03-06T09:33:00.000-08:00

You can import data from a Microsoft Excel file to create a decision table. For some examples see BE_HOME/DecisionManager/examples/ExcelFiles.

To import data:

Open the Decision Project.
From File menu, select Import. A browse window is displayed.
Click Browse to select the Microsoft Excel file to import, and name your decision table.
Select the virtual rule function you want to implement with your decision table, and click OK.The data imported from the Microsoft Excel file is saved to the decision table and you can continue modifying the data or add new data.

For custom conditions, and custom actions to be imported from Excel, mark the header names as "CustomCondition" and "CustomAction" respectively.

BusinessEvents: Working with Decision Tables

2010-02-28T02:50:00.000-08:00

Click Add to add rows. Enter the data in the new cells or drag and drop the properties form Argument Explorer.
Click Fit Content to resize the columns so they fit around the text.
You can search for certain values by entering text in the Search field.
Click Show Text button to see the contents of the cell, instead of just the values you are comparing with for the attributes you have dragged to the condition and action areas.
Drag and drop the catalog functions you see collapsed by default on the right side of the application. Drag and drop them to the function area (marked by the ) or to the cell you are editing. For example, if you want to compare some attribute that is of type integer against the rounded value of "39.99", you could say in one of your conditions "< Math.round(39.99)" by dragging and dropping the Math round function from the Standard Functions
window and then entering the arguments of that function.
Right-click on the condition area on the properties you dragged there to take a few actions relating to the column you have clicked on. For example, you can move the column, remove it, or change other field settings.
Click on the drop-down menu on the properties dragged to either the condition or the action area to filter out which rows to show based on the values. For example, if you want to see just the Account.AccountType where AccountType is "current" and you want to filter out all the other rows that do not have this value, select the "current" value from the drop-down list that will show you all the values you have entered so far in that column.
Click Remove to delete rows. If you add more rows after this operation, the row IDs are not reused.
Right-click on column headers and choose Remove to delete any conditions or actions from the table. You cannot remove the last condition column because a minimum of one condition column must exist if you have any action columns. When you remove columns, certain rows may also get merged if they now share the same values in their condition cells. If this happens, if you have non-custom actions and the rows have the same priority, the last row to be merged will have its actions be merged and the others deleted.
Select Table > Show Property, to see meta-data of the entire decision table. You can only modify the effective date and the expiration date.

BusinessEvents: Creating a Decision Table

2010-02-14T10:02:00.000-08:00

After successfully logging in to the application, some menu options are enabled depending on the roles that your account belongs to User Roles.

When a business user logs in to the Decision Manager application, the following menu options are enabled:

Project > Checkout/Update/Commit/Show Status
File > New/Open/Logout/Exit
Edit > Select All
Access menu if you also have the RULE_ADMINISTATOR role

As a business user, you can use Decision Manager to create Decision Tables.To Create a Decision Table

Open a decision project.
From File menu, select New > Decision Table Rule Function, and choose a name for the Decision Table.
Select a Virtual Rule Function that you want to implement from the Project Explorer.
Click OK.The arguments of the virtual rule function you are implementing are shown in theArgument Explorer view. Expand the Entities (concepts and events) to see theirproperties from Argument Explorer.
Decide on which properties you want to use to make a decision table. Drag and drop those properties onto the Condition or Action area.For example, if the arguments are two concepts called BankUser and Application,you can decide to accept the Application based on a users's age and credit score.In this case, drag and drop BankUser's "age" and BankUser's "creditScore"attributes from the Argument Explorer view to the condition area of the decisiontable. Then, you drag and drop the Application's "status" attribute to the Actionarea.
When you are done creating the decision table, click File > Save.

If two rows end up with the same conditions after you make modifications, they will get merged into one row. All actions will also be merged.
It is invalid to provide a string property value that starts with an integer (such as "12hello" unless you specifically wrap the value around double quotes.
Blank cells, or cells that have a * in them, as well as disabled cells are all ignored and automatically treated as true.

TIBCO BusinessEvents Resources

2010-02-06T05:19:00.000-08:00

Access control is enforced for the TIBCO BusinessEvents resources. There are twotypes of access control modes:

BusinessEvents Resource: This mode is used for populating the Project Explorer view in Decision Manager. BusinessEvents Resource mode is the default mode.

Domain Model: This model is used for enforcing the Access Control in domain model editor.

The following allows you to create a new domain model entry for any resource which matches the ID AllP.

BusinessEvents: Access Control System Overview

2010-02-02T08:46:00.000-08:00

The Access Control System manages the permissions to the users based on their roles. Using the access control system, the IT Administrator can restrict business users from accessing or modifying certain resources of a Decision Project.

Access control is role based. Thus, the users belonging to same role will have same access permissions. One user can play different roles in an organization, so the user's permissions are a unification of the permissions that each role the user belongs to gets.

By default, all permissions are denied. Each of the permissions must be grantedexplicitly. Permissions do not have hierarchies. The order in which permissionsare specified is irrelevant.

A role can have zero or more permissions. Each role is represented by a name.A Permission can have one Action and a resource for which the action applies. For example, an action could be Read, Write, or Send. A resource or entity could be arule, attribute, and so on. For example, you could specify Read permission for allattributes of a particular concept.

All of these ACL settings are specified in the

%rms.proejct.location%/%rms.project.name%/config/%rms.project.name

%.acl file as specified in the be-rms.tra file.

TIBCO BusinessEvents: Workflow

2010-01-24T09:09:00.000-08:00

User in your enterprise creates a TIBCO Designer project, creates an ontology, and writes rules that makes use of virtual rule functions to be implemented later by a business user using decision tables.
IT Administrator takes the Designer project and sets up the RMS.
IT Administrator starts the TIBCO BusinessEvents Rules Management Server.
Business user logs in with valid credentials and requests decision project by checking it out and saving it to the disk.
Depending on the permissions given by the Rule Administrator, business user creates a decision table.
The business user saves the modified decision project locally.
The business user tests the decision tables locally with a locally running BusinessEvents engine started by Decision Manager automatically.
The business user submits the modified or the new decision table for approval once done with the project.
Rule Administrator receives the request and approves or rejects the project.10.Rule Administrator takes the deployed class files generated automatically and deploys them to a production BusinessEvents engine.

BusinessEvents: User Roles of Decision Manager

2010-01-17T09:29:00.000-08:00

Explaining about different user roles of Decision Manager, and various tasks that they can undertake.

Decision Manager has the following End Users:

Business User: In this role, you use the client application to update the existing projects by creating decision tables in a decision project, modifying the tables, checking-in and checking-out the decision projects and submitting the projects for approval to the Approver.
Rule Administrator: In this role, you setup RMS, create and set up the projects, and ensure proper deployment. You decide what the business user can do using Decision Manager. You could fulfill the roles of the Approver and Deployer as well.
Approver: In this role, you use the client application to approve or deny decision projects committed by the business users.
Deployer: In this role, you use the client application to select approved entities and deploy or undeploy them.
Developer: This user customizes the client and or uses it as a User Interface (UI) component library. This user can perform the following:

Configuring the business user’s user interface
Writing the new UI components
Creating project structure model—Authoring rules
Authoring rules
Creating and validating deployment process
Verifying the entire system before releasing it to the rest of the organization

BusinessEvents: About Rules Management Server

2010-01-10T08:52:00.000-08:00

The lightweight Rules Management Server (RMS), a product of TIBCOBusinessEvents family, serves as a rules management repository. RMS is builtusing TIBCO BusinessEvents itself. Decision Manager communicates with this server to retrieve rules and other artifacts, get updates, commit them, approve orreject those rules, and deploy them to a production system. Only one decision project can be made available to the users per RMS instance. RMS allows you to:

Authenticate against an LDAP or file-based system
Access to certain parts of a project depending on your user role
Checkout a project
Get updates to that project
Commit your project
See the status of your project

If you have logged in to RMS as a Rule Administrator, it allows you to:

Set up projects with domain models and test data pre-defined, as well as set project security policies
Approve or reject committed projects and give feedback to the business users
Check on the status of all projects committed and keep track of all project versions
Deploy approved rules to a running TIBCO BusinessEvents engine of your choice

The RMS is implemented using TIBCO BusinessEvents. It contains a statemachine, rules, events, and catalog functions. The TIBCO Designer source code to this implementation is provided in the distribution in the BE_HOME/rms/projectdirectory. If you wish to customize the default behavior, you modify this project.

TIBCO BusinessEvents: About Decision Manager

2010-01-03T09:05:00.000-08:00

Decision Manager, a component in the BusinessEvents family, is an Eclipse-based Rich Client Platform (RCP) application. Its friendly user interface allows business personnel with little or no technical background to author, test, and deploy rules to the BusinessEvents engine. It simplifies complex rules by breaking them into multiple simple rules. Each simple rule is represented by a row in a decision table. It also provides IT personnel an easy, secure, and scripted deployment lifecycle by exposing an extensible Rules Management System.

Different users can use this application differently. Users include:

Business User
Developer
Rule Administrator

The business user uses this application to write, test, and maintain decisions without having to know the underlying technical details or writing code. The business user can drag and drop the properties of entities (concepts and events) to create decision logic and simulate the rules, without understanding the rule language. Developers use this application to define, modify, and deploy the configuration of a rule system, with minimal supervision and minimal implementation overhead.

In the Decision Manager application, Decision Table is an interface with rows and columns for a business user to capture threshold values and business rules in a tabular format.

The Decision Manager application enables business users to easily create simple BusinessEvents rules using the decision table feature. A decision table is a user interface with rows and columns.

Decision Tables are used to provide an implementation to Virtual Rule Functions created in TIBCO Designer. In TIBCO Designer, you cannot set the Output Argument or Return type of Virtual Rule Function. The virtual rule functions by definition have no implementation and if invoked from a rule without one will throw an exception. Thus, a decision table can be used to provide implementations to such virtual rule functions.

TIB/Adapter Applications and TIB/MessageBroker

2009-12-13T09:46:00.000-08:00

custom adapter has to work together with an application-independent transformation engine to provide full adapter functionality.

The adapter's primary functionality is to retrieve data from and export data to a source or target application such as an ERP (Enterprise Resource Planning) application.
Transformation and routing functions are performed by a message transformation engine like TIB/MessageBroker or other transformation product.

A custom adapter created with the TIB/Adapter SDK changes the format of the data so it can be understood by a variety of other applications. Although a source application's data model can be complex, the adapter retains much of the source information and makes it easy to access.

However, a custom adapter does not change the content of the data, so two applications might still not be compatible. For example, the name and address of a customer might be stored in five fields in one ERP application and in six fields in another. This kind of content conversion must be performed by a tool like TIB/MessageBroker or a third-party, message transformation system enabled for TIB/Rendezvous.

TIB/MessageBroker transforms data and provides a graphic interface for creating and modifying data transformation rules. The adapter pushes data out of a third party application (for example SAP R/3). TIB/MessageBroker can then transform the data to formats understood by other adapters (for example TIB/Adapter for Clarify, TIB/Adapter for PeopleSoft, or custom adapters).

TIB/Adapter SDK Advantage

2009-12-06T08:37:00.000-08:00

The TIB/Adapter SDK promotes rapid development and ensures that adapters built using it have the same external interface and that they plug into the overall ActiveEnterprise product suite in a consistent manner.

Using the TIB/Adapter SDK to create a custom adapter has the following advantages:

A set of reusable components that aids in rapid development of your custom adapter, with few constraints placed on the development process.
Consistent external interface to adapters and applications built using the SDK:

Consistent configuration data and metadata representation through the SDK TIB/Adapter Administrator tool. The tool is explained in TIB/AdapterAdministrator User's Guide.
Common mechanisms for reporting (MTrace and MSink classes and MAdvisoryDocument and MBusinessDocument classes.)
Standard application and session (transport) management (MApp and MRvSession)

Common means of configuring, transforming, and routing data (import and export)

Compatibility with other applications in the TIBCO ActiveEnterprise product suite.
Integration with TIB/Hawk (SDK 2.x is compatible with TIB/Hawk 2.x; SDK 3.x is compatible with both TIB/Hawk 2.x and TIB/Hawk 3.x).

What are adapters? About TIB/Adapter SDK

2009-11-29T09:17:00.000-08:00

They are components that enable application integration. They integrate applications with TIB. Their functions include:

Data representation mapper
Establish connectivity
Support for common communications paradigms
API hiding

Adapters and the TIB/Adapter SDK

A TIB/Adapter integrates an application in an event-driven, decoupled manner with the rest of the enterprise. Specifically, the adapter integrates third-party software with TIBCO ActiveEnterprise applications.

TIBCO Software Inc. has already released a number of adapter products such as TIB/Adapter for R/3, TIB/Adapter for Clarify, and TIB/Adapter for PeopleSoft. You can buy these products to integrate the respective application with TIB/Rendezvous and ultimately with your event-driven enterprise. You can also use the TIB/Adapter SDK to build a custom adapter for the application you need to integrate.

The TIB/Adapter SDK

All TIBCO adapter products are built on top of the TIB/Adapter SDK, and you can use the SDK to build an adapter of your choice.

The SDK is a class library that allows developers to implement an adapter for their source or target application with minimal effort. The SDK itself encapsulates much of the required behavior; developers implement certain methods and subclasses and specify configuration and metadata information as appropriate.

Configuring Rendezvous to Use a Different Port: Starting rvd Manually & Creating a Shell Script

2009-10-26T10:05:00.000-07:00

Use the -listen option when launching rvd to specify the port to be used. This can either be done manually (at the command line), or by setting up a shell script that automates the process.

Starting rvd Manually

Start rvd from the command line as follows:

rvd -listen tcp:PORT_NUMBER

In this command line, PORT_NUMBER is the port on which you wish rvd to listen. This port should match the port specified for the Netcool/Precision IP processes.

Creating a Shell Script
To create a shell script to automate the process for each time you use rvd:

Move the rvd binary to a new location, for example, rvd.exe.
Create a shell script with the filename rvd and execute permissions for the user that will run Netcool/Precision IP. Use a command that contains the following lines:

#!/bin/shrvd.exe -listen tcp:PORT_NUMBER

In this command PORT_NUMBER is the port number to be used. This port number must match the port specified for the Netcool/Precision IP processes. Every subsequent call to rvd is now a call to this shell script.

NOTE:
The shell script must be started manually due to checking features that are built into rvd itself. Consequently, if you are configuring ncp_ctrl to launch rvd, you must specify the executable itself (which is now rvd.exe if you have followed the above steps), and use the -listen argument, as specified above, rather than specifying this shell script.

Connecting to the Rendezvous Daemon Running on Another Machine

2009-10-21T10:11:00.000-07:00

In this case there is no need to install Rendezvous. Edit the NCHOME/etc/precision/Precision.rvd.cfg configuration file to ensure that it contains the following statements:

rendezvous session for host 'LOCAL_HOST_NAME' =
{ 'service' = 'PORT_NUMBER' 'network' = 'INTERFACE_NAME/IP_ADDRESS' 'daemon' = 'tcp:LOCAL_IP_ADDRESS:PORT_NUMBER'
}

Where PORT_NUMBER is the number of the port to be used (for example, the default rvd port number 7500), INTERFACE_NAME/IP_ADDRESS is the name or IP address of a non-loopback network interface (for example, 10.10.10.10), and LOCAL_IP_ADDRESS is the IP address of the local machine.

Configuring Rendezvous for Distributed Components

2009-10-14T09:46:00.000-07:00

By default, Rendezvous uses the loopback interface, that is, it does not broadcast traffic over the subnet. If you want Netcool/Precision IP components on one machine to communicate with components on another machine, you must configure Rendezvous to use the network interface.

To configure Rendezvous to use the network interface, edit the NCHOME/etc/precision/Precision.rvd.cfg configuration file to ensure that it contains the following statements:

rendezvous session ={

'service' = 'PORT_NUMBER'

'network' = 'INTERFACE_NAME/IP_ADDRESS'

'daemon' = 'tcp:LOCAL_IP_ADDRESS:PORT_NUMBER'

}

Where PORT_NUMBER is the number of the port to be used, INTERFACE_NAME/IP_ADDRESS is the name or IP address of a non-loopback network interface (for example, 10.10.10.10), and LOCAL_IP_ADDRESS is the IP address of the local machine.

Monitoring System Resources

2009-10-04T04:12:00.000-07:00

Two useful system metrics for monitoring system resources are CPU utilizationand free memory. If either of these metrics is compromised, the system is probably not running optimally and requires attention.

To monitor CPU utilization:

Microsoft Windows: Use the Performance microagent and the System method, and check the %Total Processor Time result field.
UNIX: Use the System microagent and the getCpuInfo method, and check the % System Time or % User Time result field. You could also check the %Time Idle field for low values.

To monitor overall memory usage:

Microsoft Windows: Use the Performance microagent and the Memorymethod, and check the Committed Bytes or % Committed Bytes in Use result field. To check swap file usage, use the Performance:Paging File()method and check the % Usage and % Usage Peak result fields.
UNIX: Use the System:getSwapInfo

Controlling Execution of TIBCO BW services

2009-09-29T10:49:00.000-07:00

Process instances typically remain in memory as long as they are executing an activity. If the process instance is waiting for an incoming event (for example, a Wait for Adapter Message activity), the process instance can be paged out to disk and resumed later after the event arrives.
New process instances are paged out to disk until there is available memory and resources to accommodate them.
Use TIBCO admin to control execution of TIBCO BW process instances. Useful if system has limited resources & memory or to restrict process instances to run sequentially.

Go to --> Application Mgmt --> Application configuration --> click proccess service -> Advanced Tab

Max Jobs : Specifies the maximum number of process instances that can concurrently be loaded into memory. Any process instances created once the maximum is reached must be paged out to disk.
Activation Limit : Specifies that once a process instance is loaded, it must remain in memory until it completes. useful if you wish to specify sequential processing of incoming events, or if you want to enforce limited concurrent execution of process instances.
Max Jobs (FLow Limit) : Specifies the maximum number of currently running process instance to start before suspending the process starter. Max Jobs (Flow Limit) field limits the number of process instances created by a process starter. This allows you to control the flow of processing so that incoming events are no longer accepted when the limit is reached. This is useful in protocols like TIBCO RVCM, JMS Durables TOpic, JMS Queue, Recceive Mail etc.

Main Responsibilities of TIBCO Admin Server

2009-09-23T09:34:00.000-07:00

Manage Storage for the domain -- Storage can be file based repository or in a database repository.
Enforce Security for the domain -- User authentication & authorization
Provide Load balancing -- each domain can be configured with one primary & multiple secondary servers. Primary server allows read & write operations while secondary servers only supports read operations.
Provide Failure recovery -- When primary server is down, secondary server continue serving.

Elements of TIBCO Admin domain

2009-09-21T02:54:00.000-07:00

Administration Server - Manages admin domain.Each administration server manages only one domain. Multiple secondary servers are allowed. Server can be accessed with web browser based TIBCO Administrator.
Machines - By default all machines in an admin domain are expected to be in same subnet. However TIBCO RVRD can be used to communicate to the machines on different subnet.
User & Acces Information - stored in domain repository. Also syncronize with LDAP server for users & groups
Runtime Application - Start, stop & monitor individual process engines & service instances.
TIBCO Hawk Agent -- Monitors local resources & conditions. Hawk Agent is an autonomous process & uses collection of locally loaded rules organized into rulebases to apply monitoring logic.

Overview of TIBCO Administrator

2009-09-17T09:59:00.000-07:00

Functions of TIBCO Administrator:

User Management -- creates users & roles, assign them access rights to TIBCO Admin console, application & application repository
Resource Management -- manage TIBCO software installed on other machines in domain & monitors machines in domain
Application Management -- upload, deploy & monitor applications

TIBCO Administrator Architecture includes:

Tomcat web server -- manage basic communiaction & makes TIBCO Admin available
Administrator Server -- Manage domain & application repositories
User Management
Resource Management
Application Management

Using Stylesheets in XML- CSS & XSLT

2009-09-09T09:13:00.000-07:00

XML is a means of exchanging data between applications. It allows the developers to describe and structure their data in their own formats. As the XML gave more emphasis on data rather than formatting, the data in the XML document can be formatted in two ways:

USING CSS
USING XSL

Cascade Style Sheet( CSS):

Initially, Cascading Style sheets (CSS) were used for formatting the data in the XML documents. It allows the Web Developers to define a formatting for the elements in XML and the same can be applied to as many documents you like. The advantages are:

It has a Precise control over presentation
It is Resolution Independent
It downloads Faster
It is easy to maintain

Though it has a lot of advantages it also has following disadvantages.

The order of elements for display cannot be changed
An element cannot be processed more than once
Generated text cannot be added to the presentation

Extensible Stylesheet Language (XSL):

The difficulties that were encountered with CSS were removed by making use of XSL. XSL is an application of XML It allows you to create high performance XML based systems by integrating Server side XML processing’s. The need for transforming data from one format to the other results in splitting XSL into two groups:

XSLT – It describes how to transform XML. Document into other formats.
XSL-FO- It describes formatting details of each element in the XML document.

XSLT:

The XML Style sheet Language Transformation (XSLT) is a mechanism of transforming one form of XML documents to the other form. It is a set of templates based on Xpath expressions that tells how to fetch a particular node from the XML documents. It is a part of XSL, which is a style sheet language for XML. XSLT is widely used in Websites Content Management to convert XML into HTML pages. It uses Xpath to define parts that match one or more templates. Xpath is an query language that allows you to identify the nodes. It can select nodes in any direction. An XSLT processor is used to perform transformations of XML document in to other formats based on the given XSLT document.

XSL_FO:

XSL-FO means Extensible Formatting Objects. There are two different ways in which the XML document can be formatted. They are:

Layout Based formatting
Content Based formatting

In a layout based formatting, the limitations of the target may constrain the content or appearance on the page, whereas in a Content Based Formatting, the target medium is generated to accommodate the information being formatted. The XSL FO allows you to make formatting and styling options to your document.

Is XML a Database?

2009-09-06T05:41:00.000-07:00

XML document is a collection of data. In other words it doesn’t make much difference between the other files that store data. A XML in a database format is a self describing, portable, and can describe data in tree or graph structure. XML is a sort of Database Management System (DBMS).

XML provides storage, schemas, query languages, programming interfaces and so on .It lacks in triggers, queries, multi-user access that a real database constitutes. The main advantage of XML is that the data is portable and it allows you to have nested entries.

XML allows you to preserve physical document structure, supports document level transactions and execute queries in an XML query language.

Mapping the XML document schema to the database schema does the transfer of data between XML documents and a database. Mappings between document schemas and database schemas are performed on attributes and text. There are 2 mappings that are generally used to map on XML document schema to the database schema:

TABLE BASED MAPPING
OBJECT RELATIONAL MAPPING

Native XML databases are designed especially to store XML documents .It is always possible to store data in XML documents in a native XML database. This is done so, when your data is semi-structured. Although, this kind of data can be stored in object oriented and hierarchical databases, it is always better to store it in a native XML database. It enables us to retrieve data much faster than a relational database. One more reason is to store data in a native XML database is to exploit XML specification capabilities, such as executing XML queries.

What is XML and What Good is XML?

2009-08-31T09:50:00.002-07:00

What is XML?

XML stands for eXtensible Markup Language and is a descendant of Standard Generalized Markup Language (SGML), just as HTML is. The most noticeable difference between XML and HTML is the fact that you can define your own tags in XML. That is why XML is considered an extensible language. Because of the freedom of the tags, however, the way in which XML must be written is very strict. Every tag must have a closing tag and all nodes must be ordered properly. If any of these rules are broken, an XML document will simply fail to function. HTML, as many have found, will work even if the document only vaguely looks like an HTML document.

What good is XML?

XML is all about structure. The markup in XML defines what the data represents (i.e. The Catcher in the Rye). HTML, on the other hand, is made for publications. Hence, in HTML, it makes sense to order information by where and how it will appear on the screen. In XML, however, the structure of the information is what's most important. The order of the information is unimportant - it can be displayed in whatever order you want. The important thing is that each piece of data is contained in markup that describes what that data really represents. The structure can be maintained much more easily in XML because of the fact that you can create your own tags.

Think of a book you've read recently. The chapter titles were most likely in bold print. We come to rely on these sorts of conventions to give us a sense of the structure of the document. When you're dealing with a web page, you have to make the structure evident to the reader to help them deal with the information. By using XML, you can easily keep track of information like chapter titles because they will all be contained in markup designating what they are (i.e. Ch. 1 - The Beginning). You can then choose to display that information in whatever way will make it easiest for your reader.

That's what XML is all about: structure.

Basic Principles of Service Orientation Architecture (SOA)

2009-08-26T10:27:00.000-07:00

To build an SOA solution based on Web services, you need to follow the service-orientation principles when pulling the services together into an application. Here are some of the key principles of service-orientation you need to keep in mind when designing SOA solutions:

Loose coupling: It represents a relationship that allows the underlying logic of a service to change with minimal or no impact on the other services utilized within the same SOA. Loose coupling is the key principle of service orientation. Implementing services as loosely coupled pieces of software allows you to keep up with the other key principles of service orientation, such as service reusability, service autonomy, and service statelessness.
Service contract: It represents service descriptions and other documents describing how a service can be programmatically accessed. In the Binding with WSDL section earlier in this article, you saw an example of a WSDL service description document that describes a service, defining the contract for that service.
Abstraction of underlying logic: It means that a service publicly exposes only logic described in the service contract, hiding the implementation details from service consumers.
Autonomy: It means that services control only the logic they encapsulate. Dividing application logic into a set of autonomous services allows you to build flexible SOA solutions, achieving loose coupling, reusability, and composability.
Reusability: Reusability in service-orientation is achieved by distributing application logic among services so that each service can be potentially used by more than one service requestor. Building reusable services supports the principle of composability.
Composability: Composability represents the ability of services to be grouped into composite services that coordinate an exchange of data between services being aggregated. For example, using an orchestration language, such as WS-BPEL, allows you to compose fine-grained services into more coarse-grained ones.
Statelessness: It means that services don't maintain their state specific to an activity. Building stateless services encourage loose coupling, reusability, and composability.
Interoperability: Interoperability between services is easily achieved as long as the services interact with each other through interfaces that are platform- and implementation-independent.
Discoverability: Discoverability refers to standard mechanisms that make it possible for service descriptions describing services to be discovered by service requestors. Universal Description, Discovery, and Integration (UDDI) specification provides such a mechanism, which allows for publishing service descriptions documents in an XML-based registry, thus making them available for public use.

As you can see, most of these principles are tightly related. For example, if you bear the autonomy principle in mind when dividing application logic into services to be utilized within an SOA, you will have reusable, composable, and loosely coupled pieces of software that can be reused in future projects.

On the other hand, ignoring at least one principle of service-orientation makes it very hard to keep up with the others. For example, if you ignore the principle of statelessness when designing services, you will end up with less reusable and less composable building blocks for your SOA solutions.

Introduction to Service-Oriented Architecture

2009-08-24T09:34:00.000-07:00

While using Web services allows you to achieve interoperability across applications built on different platforms with different languages, applying service-oriented concepts and principles when building applications based on using Web services can help you create robust, standards-based, interoperable SOA solutions.

It is interesting to note that Service-Oriented Architecture, while providing architectural foundation for building service-oriented solutions, is not tied to a concrete technology or technology set. In contrast, it may be implemented with various technologies, such as DCOM, CORBA, or Web Services. However, only the Web Services technology set is currentlythe primary way to put SOA into practice.

What is WSDL and Its Benefits

2009-08-20T09:51:00.000-07:00

WSDL is an XML document used to describe web services and WSDL stands for Web Services Description Language.

A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding.

Types– a container for data type definitions using some type system (such as XSD).
Message– an abstract, typed definition of the data being communicated.
Operation– an abstract description of an action supported by the service.
Port Type–an abstract set of operations supported by one or more endpoints.
Binding– a concrete protocol and data format specification for a particular port type.
Port– a single endpoint defined as a combination of a binding and a network address.
Service– a collection of related endpoints.

The primary benefit of the WebService behavior is that it provides a simple way for you to call methods that are exposed by Web Services using the SOAP protocol. The WebService behavior enables you to call a remote method using a few, straightforward, client-side scripting methods exposed by the behavior. Navigating to another URL is unnecessary when using the WebService behavior to deliver data to a page because DHTML is used to update the page's content. This approach enhances the browsing experience significantly, compared to traditional browsing approaches that require a full page refresh.

TIBCO BusinessConnect Remote Overview

2009-08-17T09:23:00.000-07:00

TIBCO BusinessConnect Remote is a light-weight software application designed to exchange business documents exclusively with a BusinessConnect server overthe Internet using the AS2 transport. It allows large enterprises to enable their small partners to start performing E-commerce transactions rapidly, with minimal setup, and relatively at low cost.

TIBCO BusinessConnect Remote client service is a protocol that enables the BusinessConnect Remote client to download the configuration data from a BusinessConnect server in preparation for a secure document exchanges upon startup. The configuration data includes exchange of certificate credentials forencryption and digital authentication between the BusinessConnect Remote client service and the BusinessConnect server as well as the AS2 transport parameters.

The audit log viewer for the BusinessConnect Remote client service captures the audit trail of the startup request initiated by each BusinessConnect Remote client.For more information about the audit log, see TIBCO BusinessConnect TradingPartner Administration Guide, Appendix C, BusinessConnect Remote Client.

For the complete information about this application, see TIBCO BusinessConnect™Remote User’s Guide.

Data Stores in BusinessConnect

2009-08-12T09:50:00.000-07:00

BusinessConnect uses two types of data stores:

Runtime data store
Configuration store

By default, the data stores use the default database connection. You can assign adifferent database to the data stores using the window System Settings > JDBCConnections.

1. Runtime Data Store

The runtime data store tracks the information flowing through the engine,recording the same information that can be recorded in audit andnon-repudiation logs plus information about hibernation, database locking,resend, and alert messages.

This information, however, is for use by the BusinessConnect engine itself,serving as a memory of what tasks it has already performed. BusinessConnectcannot function without a valid runtime database.

2. Configuration Store

The configuration store records all the information that you provide toBusinessConnect. For example, it stores information about business partners,configuration parameters, and transport settings.

BusinessConnect Server Components

2009-08-10T09:14:00.000-07:00

TIBCO BusinessConnect server is internally divided in two components:

1. DMZ (De-Militarized Zone)

This component sits in the de-militarized zone and can have several restrictions on the networks it can access.

The DMZ component receives B2B communications directly from the Internet and performs SSL validation. By placing a firewall between the DMZ and the rest of your system, you can protect against the threat of malicious communications.

2. Interior Engine

This component performs the following tasks:

(i) Handles all messaging level activities such as encryption, decryption, and digital signatures.

(ii) Takes care of business level logic to be executed by an individual protocol, such as document schema validation.

Any deployment configuration change should trigger redeployment of both server components.

BusinessConnect product Overview and Major Features

2009-08-06T10:44:00.000-07:00

BusinessConnect is a B2B (business-to-business) gateway that allows your company to engage in electronic commerce with your partners. It enables secure transmission of documents and messages between partners using disparate internal business systems.

BusinessConnect supports multiple protocols (also called standards) for electronic commerce, such as EDI, RosettaNet, and SOAP.

BusinessConnect includes these major features:

BusinessConnect Server engine, which handles transport, messaging, and business message content
Trading partner management system and certificate store
Non-repudiation database
Audit log database
Two deployment options: Single Server and Dual Firewall DMZ mode
BusinessConnect Palette for TIBCO BusinessWorksTM

BusinessConnect uses TIBCO AdministratorTM as its graphical user interface, making it especially familiar and easy-to-use for existing TIBCO customers.

Business agreements, an essential component of any B2B implementation, can be easily constructed with BusinessConnect. A business agreement defines the protocol (or protocols) you will use to exchange documents with your partner.

It defines the transport method (for example, HTTPS or email), and the operations that each partner will be allowed to transact. When you set up operations at the system level for use with multiple partners, BusinessConnect gives you the flexibility to override individual aspects of an operation as needed for specific partners.

Using the configuration Files in EMS

2009-07-31T09:43:00.000-07:00

The configuration files contain information about the various EMS objects like queues, topics, users, bridges etc. These files are located in TIBCO_HOME/ems/bin directory.

These files can be edited either directly using a textpad or using the command line based administration tool. The administration tool will eventually read/write to/from these configuration files.

Following are the key configuration files that are available in EMS server:

tibemsd.conf - This is the main configuration file. It has properties that are concerned with the EMS server.

queues.conf - Queue configuration file.

topics.conf - Topics configuration file.

users.conf - All users configuration file.

acl.conf - Permission settings for users on destinations.

routes.conf - Routes configuration file.

bridges.conf - Bridges configuration file.

factories.conf - Connection Factories configuration file.

Wildcards in Topics and Queues

2009-07-29T09:38:00.000-07:00

The wildcard * means that any token can be in the place of *.

For example: foo.* matches all two-part destination names beginning with foo. including foo.bar and foo.boo, but not foo.bar.boo.

The wildcard > matches one or more trailing elements. For example, foo.> matches foo.bar and foo.bar.boo

Wildcards in Topics:

You can subscribe to wildcard topics.

You cannot publish to wildcard topics.

If foo.bar is not in the configuration file, then you can publish to foo.bar if foo.* or foo.> exists in the configuration file.

Wildcards in Queues:

You can not send or receive to wildcard queue names. However, you can use wildcard queue names in the configuration files.

For example, if the queue configuration file includes a line:

foo.* then users can create queues foo.bar, foo.bob, and so forth, but not foo.bar.bob.

Key Interfaces in EMS - MessageProducer, MessageConsumer and MessageListner

2009-07-27T08:49:00.000-07:00

MessageProducer:

A MessageProducer object is created by a Session object and is used for sending messages to destinations. For example, using the mySession object created in Session , the following creates a MessageProducer that sends messages to a queue named myQueue:

MessageProducer myQueueSender = mySession.createProducer(myQueue);

Once you have created a MessageProducer, you can use it to send messages. For example, the following sends a message using the queueSender created above:

myQueueSender.send(message);

You can create MessageProducers that do not identify a destination. When the sender or publisher does not specify a destination, you must specify the destination when you send or publish a message as the first parameter of the send() or publish() method.

MessageConsumer:

A MessageConsumer object is created by a Session object and is used for receiving messages sent to destinations. For example, using the mySession object, the following creates a MessageConsumer that retrieves messages from a queue named myQueue:

MessageConsumer myQueueReceiver =
mySession.createConsumer(myQueue);

For queues, messages remain on the queue until they are consumed by a MessageConsumer, the message expiration time has been reached, or the maximum size of the queue is reached.

a) Durable Subscribers for Topics: Only MessageConsumers whose client applications are running receive messages published on a topic. Optionally, Sessions can create durable subscribers to ensure that messages are received, even if the application is not currently running.

(b) Synchronous or Asynchronous Messages: The API allows for synchronous or asynchronous message consumption. For synchronous consumption, the MessageConsumer explicitly calls the receive() method on the topic or queue. For asynchronous consumption, the client registers a MessageListener for the topic or queue. When a message arrives at the destination, the TIBCO Enterprise Message Service server delivers the message by calling the listener’s onMessage() method.

MessageListner:

A MessageListener object acts as an asynchronous event handler for messages. This object implements the MessageListener interface and has one method, onMessage().The onMessage() method is called by the TIBCO Enterprise Message Service server when a message arrives on a destination. You implement the onMessage() method in your MessageListener class to perform the desired actions when a message arrives. Your implementation should handle all exceptions, and it should not throw any exceptions.

Once you create a MessageListener object, you must register it with a specific MessageConsumer. The following creates a queueListener (an implementation of the MessageListener interface) and registers it with the QueueReceiver object:

MessageListener queueListener = new MessageListener();
myQueueReceiver.setMessageListener(queueListener);

You should register the MessageListener with the MessageConsumer before calling the Connection’s start () method to begin receiving messages.

Key Interfaces in EMS - ConnectionFactory, Connection and Session

2009-07-25T08:33:00.000-07:00

ConnectionFactory:

The ConnectionFactory object encapsulates a set of connection configuration parameters. When a client starts, it typically performs a Java Naming and Directory Interface (JNDI) lookup for the ConnectionFactories that it needs. For example, the following code retrieves the InitialContext using the JNDI properties specified by env, then looks up a ConnectionFactory named myConnectionFactory.

Context ctx = new InitialContext(env);
ConnectionFactory myConnectionFactory =
(ConnectionFactory) ctx.lookup("myConnectionFactory");

Connection:

A Connection object encapsulates a virtual connection with the server.
ConnectionFactory objects create Connection objects. You use a Connection to create one or more Session objects. For example, the following creates a Connection:

Connection myConnection =
myConnectionFactory.createConnection()

When a client application completes, all open connections must be closed. Unused open connections are eventually closed, but they do consume resources that could be used for other applications. Closing a connection also closes any Sessions created by the Connection. To close a connection, use the close() method. For example:

myConnection.close();

Session:
A Session is a single-threaded context for producing or consuming messages. You create MessageProducers or MessageConsumers using Session objects. For example, using the myConnection object created in Connection above, the following creates a Session:

Session mySession =

myConnection.createSession(false, Session.AUTO_ACKNOWLEDGE);

The first parameter to the CreateSession() method determines whether the Session is transactional or not. The second parameter specifies the acknowledge mode of messages received by the session.

The remaining Key Interfaces will be explained in tomorrow's posting.

Destination Bridges, Routes and Flow Control

2009-07-24T09:16:00.000-07:00

Destination bridges and flow control

Please read Bridges before reading this topic

Flow control can be specified on destinations that are bridged to other destinations. If you wish the flow of messages sent by way of the bridge to slow down when receivers on the bridged-to destination cannot process the messages quickly enough, you must set the flowControl property on both destinations on either side of the bridge.

Routes and flow Control

For global topics where messages are routed between servers, flow control can be specified for a topic on either the server where messages are produced or the server where messages are received.

If the flowControl property is set on the topic on the server receiving the messages, when the pending message size limit is reached, messages are not forwarded by way of the route until the topic subscriber receives enough messages to lower the pending message size below the specified limit.

If the flowControl property is set on the topic on the server sending the messages, the server may block any topic publishers when sending new messages if messages cannot be sent quickly enough by way of the route. This could be due to network latency between the routed servers or it could be because flow control on the other server is preventing new messages from being sent.

Control access to the EMS Server:Authentication and Permissions

2009-07-23T10:15:00.000-07:00

TIBCO Enterprise Message Service allows you to control access to the server by creating users and assigning passwords, creating groups, setting permissions etc. The server can also authenticate users defined in an external directory (such as an LDAP server)

Permissions for all users and groups must be defined in the access control list for the TIBCO Enterprise Message Service server. There are also administrator permissions that allow administrators to control which actions users can perform on the server such as create destinations, modify users, and view routes. Administrator permissions can apply globally, or they can be granted on specific destinations.

Enabling Access Control
There are two levels where authorization is set.

Server: The authorization property in the main configuration file enables or disables the checking of permissions for all destinations managed by the server. The authorization property also enables or disables verification of user names and passwords.

To enable authorization, edit the tibemsd.conf file:
authorization = enabled

From the command line admin utility:

set server authorization = enabled

If this is not set, then the server allows any client connection and no permissions are checked on any destination. Enabling authorization immediately applies to existing client connections (except route connections). The server begins checking permissions.

Destination: The secure property of the destinations is used to allow the server to check permissions of a client connection for that particular destination when a user attempts to perform any operation on that destination

Setting Permissions
Permissions are stored in the access control list and determine the actions a user can perform on a destination. Permissions can only be granted by users that have the appropriate administrator permissions.

Please go through the corresponding chapter in the JMS documentation for further detailed information

Failover in EMS

2009-07-21T08:55:00.000-07:00

Step 1

A backup server detects a failure of the primary in either of two ways:

Heartbeat Failure—the primary server sends heartbeat messages to the backup server to indicate that it is still operating. When a network failure stops the servers from communicating with each other, the backup server detects the interruption in the steady stream of heartbeats.
Connection Failure—the backup server can detect the failure of its TCP connection with the primary server. When the primary process terminates unexpectedly, the backup server detects the broken connection.

Step2
When a backup server (B) detects the failure of the primary server (A), then B attempts to assume the role of primary server. First, B obtains the lock on the current shared state. When B can access this information, it becomes the new primary server.

If B cannot obtain the lock immediately, it alternates between attempting to obtain the lock (and become the primary server), and attempting to reconnect to A (and resume as a backup server)—until one of these attempts succeeds.
When server A comes back again, it becomes a backup server and server B continues to be the primary.
Clients of A that are configured to failover to backup server B automatically transfer to B when it becomes the new primary server.

Step 3:

After a failure, message redelivery is attempted based on the type of messages and destination configuration.

Persistent: When a failure occurs, messages with delivery mode PERSISTENT, that were not successfully acknowledged before the failure, are redelivered.
Failsafe: EMS guarantees that a message with PERSISTENT delivery mode and a failsafe destination will not be lost during a failure.
Any messages that have been successfully acknowledged or committed are not redelivered, in compliance with the JMS 1.1 specification.
All topic subscribers continue normal operation after a failover.
Queues: For queue receivers, any messages that have been sent to receivers, but have not been acknowledged before the failover, may be sent to other receivers immediately after the failover. A receiver trying to acknowledge a message after a failover may receive the javax.jms.IllegalStateException. This exception signifies that the attempted acknowledgement is for a message that has already been sent to another queue receiver.
After a failover, attempting to commit the active transaction results in a javax.jms.TransactionRolledBackException. Clients that use transactions must handle this exception, and resend any messages sent during the transaction.

Configuring the Fault Tolerant Servers

2009-07-20T09:14:00.000-07:00

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 thebackup server, set this parameter to the URL of the primary server.

When the backup server starts, it attempts to connect to the primary server. If it establishes a connection to the primary, then the backup server enters standby mode. If it cannot establish a connection to the primary, then the backup server assumes the role of the primary server (in active mode). While the backup server is in standby mode, it does not accept connections from clients.

To administer the backup server, the admin user can connect to it using the administration tool

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) and continue processing their current message state. As each client reconnects, the backup server reads its message state from the shared state files. You can instruct the server to clean up state information for clients that do not reconnect before a specified time limit.

The ft_reconnect_timeout configuration parameter specifies that time limit (in seconds). The default value is 60 seconds

Fault Tolerance in EMS

2009-07-18T04:45:00.000-07:00

You can arrange TIBCO Enterprise Message Service servers for fault-tolerant operation by configuring a pair of servers—one primary and one backup. The primary server accepts client connections, and interacts with clients to deliver messages. If the primary server fails, the backup server resumes operation in its place. (EMS does not support more than two servers in a fault-tolerant configuration.)

Shared State: A pair of fault-tolerant servers must have access to shared state, which consists of information about client connections and persistent messages. This information enables the backup server to properly assume responsibility for those connections and messages.

Server state includes 3 categories of information:

Persistent messages

Client connections of the primary server

Metadata about message delivery (stored in the meta.db file)

Persistent messages are stored in 2 files: async-msgs.db file, which contains all the messages stored under normal mode, and sync-msgs.db file that contains all messages that are for failsafe destinations

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

Click to read about Configuring Fault Tolerance.

EMS Message Delivery Mode Extensions (Reliable Message Delivery): PERSISTENT and NON PERSISTENT

2009-07-16T10:45:00.000-07:00

TIBCO Enterprise Message Service(EMS) introduces two types of message delivery which are extensions to the JMS specification.

JMS delivery requirements ensure the delivery of all messages in almost all circumstances. However this requirements leads to a lot of overheads in the sense of network traffic (message and a return message confirming the receipt of the message) and the memory allocated for each persistent message and durable subscriber.

For higher throughput, EMS has come up with 2 ways of reducing the above overheads:

Reliable Message Delivery
No-Acknowledgement Delivery receipt

Reliable Message Delivery:

JMS has PERSISTENT and NON_PERSISTENT delivery modes for both topic and queue. In addition to these modes, you can use Tibjms.RELIABLE_DELIVERY mode from TIBCO Enterprise Message Service.

PERSISTENT and NON_PERSISTENT delivery require the server to return a system message to the client application to ensure proper handling of messages. In reliable delivery mode, the client application does not wait for this system message. Thus, reliable mode decreases the volume of message traffic, allowing better usage of system resources, and higher message rates.

No-Acknowledgement Message Receipt:

In no-acknowledge receipt mode, after the server sends a message to the client, all information regarding that message for that consumer is eliminated from the server. Therefore, there is no need for the client application to send an acknowledgement to the server about the received message. Not sending acknowledgements decreases the message traffic and saves time for the receiver, therefore allowing better utilization of system resources.