Using ITCAM for SOA to monitor BPM Systems: Part 2: How ITCAM for SOA monitors service-oriented architectures

Understand the metrics for SOA system and how ITCAM for SOA display the metrics to present SOA system status

The metrics collected by ITCAM for SOA are gathered from SCA messages, in this article, we will analyze the metrics, compare and map metrics to the WebSphere Dynamic Process Edition (WDPE) and runtime behaviors. We also explain how to read, understand and analysis the metrics, and how to aware the WDPE applications from the metrics.

Yunjie Tan (tanyj@cn.ibm.com), BPM Integration QA, IBM  

Yunjie TanYunjie Tan (Jim) is a staff software engineer and the BPM Integration QA team Designer. Besides the in-depth knowledge about the WPS/WID products, he is also an expert of UML, Business analysis/modeling, and Software methodology. He also is an author of the popular Chinese book about the UML - "Elephant--thinking in UML".



Hua Cheng (chenghua@cn.ibm.com), BPM Integration QA, IBM  

Hua ChengHua Cheng (Ted) joined IBM since 2003 and currently is the BPM Integration QA team Lead, He has broad experience of BPM products including WID, WPS, Modeler, Monitor and Adapter. Also has the In-depth knowledge covering Java/J2EE development and product testing. Before taking the current role, he works for several WPS development and test project, including the WPS (Webpshere Process Server) component owner, development lead and test lead.



Sen Wang (wangsbj@cn.ibm.com), BPM Integration QA, IBM  

Sen WangSen Wang (Watson) currently is the BPM Integration QA team member, He has broad experience of BPM products including WID, WPS, Message Broker, WSRR and FileNet, also has the In-depth knowledge covering Java/J2EE development. Before taking the current role, he works for SOA design center as intern since 2007 and have rich experience of custom projects, such as bank and insurance projects.



28 August 2009

Also available in Chinese Spanish

Example scenario

Besides ITCAM for SOA, there are other ITCAM products, such as ITCAM for Response Time, ITCAM for WebResource, and ITCAM for Transaction. However, these products monitor system at the application granularity level. Unlike the other products, ITCAM for SOA can monitor systems at a granularity level rather than application level. That is, ITCAM for SOA can recognize Service component architecture (SCA) components and messages in applications to monitor systems.

Let's begin from the example scenario illustrated in Figure 1 to explore ITCAM for SOA. In this example scenario, there are three modules, Module 1 contains a Business Process Execution Language (BPEL) SCA component which provide service for clients; Module 2 and Module 3 contains some Java SCA components which provide computing services to BPEL. When clients invoke the BPEL component, BPEL invokes the Java components for computing. Assume the 3 modules are deployed on heterogeneous environment, thus BPEL have to invoke computing services using various protocols. In this example, as you see, the SCA/JAX-RPC/JMS/HTTP bindings are being utilized.

In Figure 1 below, the arrows are indicating where messages are being requested/responsed. The right-arrow means request message and left-arrow means response message. The different arrow styles means different message protocol. In next the section, we will explain "ServiceRequester" and "ServiceProvider".

Figure 1. Example scenario
example scenarios used in this artical

How ITCAM for SOA record traffic data

While the application illustrated in Figure 1 executing, Data Collector of ITCAM for SOA monitoring the SCA or WebService messages and send these messages as traffic data to ITCAM for SOA server side. ITCAM for SOA analysis system exactly based on these traffic data. When traffic data arrived, ITCAM for SOA analyze the traffic data to get information such as Service-Provider, WSDL-ServicePort and their namespaces to identify each unique transaction, then create record in the Services_Inventory table for the identified transactions.

Although one traffic data may content the service requester and service provider, ITCAM for SOA only record the service provider, will not record the service requester. That is, even there may be many clients request one service, ITCAM for SOA only records the information of request messages to service provider and response messages from service provide, the information of service requester are ignored. ITCAM for SOA will create two records for the service provider information, one is to record request messages and the other is to record response message.

Meanwhile, ITCAM for SOA will gather certain data from the traffic data as metrics to update them to the corresponding transaction records in Services_Inventory table. The important metrics for ITCAM for SOA are "Message Count", "Avg Message Length", "Avg Elapsed Time " and "Fault Count". (See Table 1 below for more detail of the Services_Inventory table fields).

Based on upon understanding, for example, when component "AccountVerificationToBe" invoke "CustomerRetrieval" component once, there should be two records in Services_Inventory table.

Table 1. Example records in Services_Inventory
ModuleNameComponent NameOperationNameService TypeMessage CountAvg Message SizeAvg Elapsed TimeFault Count
AccountVerificationCustomerRetrievalInputCriterionRequester202910
AccountVerificationCustomerRetrievalInputCriterionProvider202900

From this example, we can see that:

  • ITCAM for SOA will only record the request message to service provider, and response message from service proivder, regardless the service requester. In this example, component "AccountVerificationToBe" is the service requester to service provider, the component "CustomerRetrieval". Thus ITCAM for SOA create one "requester" row to record the request messages to service provider "CustomerRetrieval", and another row to record the response messages from service provider "CustomerRetrieval".
  • If run the application many times, the records won't increase, ITCAM for SOA will only update the metrics value of the record, such as "Message Count", "Avg Message Length", "Avg Elapsed Time" and "Fault Count".

Figure 2 displays the message count that ITCAM for SOA record down while the example application run once. The digit on each arrow shows how many messages ITCAM for SOA caught in one invocation.

Figure 2. Message count ITCAM for SOA record via one single run
Full result ITCAM for SOA record via one single run

Through figure 2, there has 6 questions Q1 to Q6. They need to do more explanation to understand how ITCAM works.

  • Q1: Why there is no message count be caught for "Account VerificationToBe" component ?
    Because Data Collector of ITCAM for SOA only detect SCA and WebService messages. "Account VerificationToBe" component is the first interface for clients, if the transactions from out side to "Account VerificationToBe" component are not SCA or WebService message, Data Collector can not detect them. In another word, if clients invoke "Account VerificationToBe" component through SCA or WebService protocol, there should have message count caught.
  • Q2: Why one invocation cause 2 request message and 2 response message? Shouldn't it be 1 ?
    At first glance, the message count of request and response should be 1, since there only one invocation happened. However, the correct answer is 2. This is because of the implements of SCA invocation mechanism. The invocation from caller to callee is indirectly, caller send one SCA request message to SCA container, and then SCA container forward a new SCA message to callee. In this case, Data Collector will get two SCA messages, both of them has same invocation source and target.

That means, ITCAM for SOA count all SCA messages here. Figure 3 below shows the interactions in SCA container. Now, it's clear why the DataCollector got 2 request messages and 2 response messages. In fact, different SCA invocation pattern would cause different message count. Please refer SCA invocation pattern in WebSphere Process Server V6.1 to learn more SCA invocation pattern.

Figure 3. Synchronous invocation (request-response operation)
Interactions of Synchronous invocation (request-response operation
  • Q3: Why is there no message between Import and Export?
    WDPE SCA container consider Export as special component, it is not treated as real service provide. The messages to Export won't detected by SCA DataCollector. Thus the message count between Import and Export is 0. But, if the message protocol is WebService, it's another story, see Q4.
  • Q4: Why there is only one request and one response message?
    From Q3, the messages to Export can not be detected by SCA DataCollector. But besides SCA DataCollector, ITCAM for SOA have another WebService DataCollector. Although the message can not detected by SCA DataCollector, the WebService DataCollector detected the JAX-RPC message.
    From Q2, we knew one because of SCA invocation mechanism, one invocation would have 2 messages. Here we only have 1, it indicate that the message is not caught by SCA DataCollector, but by WebService DataCollector. The message is not pass thought SCA container, so only 1 message caught.
  • Q5: Why is the response message count three?
    This is because of the implements of JMS invocation mechanism. At JMS caller side, it might have two queues, the "send" queue and "receive" queue; but at JMS callee side, it might have three queues, "receive", "send" and "callback" queue. So, if application set the JMS callee to use "callback" queue, there will has 3 messages generated at callee side.
  • Q6: Why both the two component are "ServiceProvider" ?
    From Q1, we knew since "Account VerificationToBe" component is the first interface for the clients, DataCollector can not detect the non-WebService messages from clients, it act as "ServiceRequester"; From Q3, we knew Export is not treated as real service provider by SCA container, it act as "ServiceRequester".

Both "DetermineApplicantEligibility" and "DetermineApplicantEligibilityHTTPImport" are not the situation of Q1 and Q3. They act as both "ServiceProvider" and "ServiceRequester". E.g., "DetermineApplicantEligibility" is the "ServiceProvider" for "DetermineApplicantEligibility SCA export"; and it also the "ServiceRequester" for "DetermineApplicantEligibilityHTTPImport".


Services_Inventory table fields overview

The traffic data is stored in the Services_Inventory table. ITCAM for SOA uses the data in Services_Inventory table to present the system status that under monitoring. Table 2 below lists all the fields within the Services_Inventory table.

Note: The Services_Inventory table is commonly used within TEP, both for common WebService and SCA component. In case of the SCA component, some of the field names are not compatible with the content. For example, the SCA component does not have a property named "Operation Namespace", so in the filed "Operation Namespace (Unicode)" it exactly store the name of the method on the interface of the SCA component being invoked. All the incompatible fields are highlight as bold font.

Note: The message length is not currently supported in WPS SCA container. As shown in Figure 4 and Figure 5, all the SCA message size are 0 but the WebService message size are not.

Table 2. ITCAM for SOA metrics
Metric NameExplanation and Usage
Origin NodeThe application environment instance of the managed system.
Interval StatusThe status of this interval, (Incomplete=1, Complete=2)
Operation Name (Unicode)In case WebService, it's the name of the WSDL operation. In case SCA components, it's the name of the method on the interface of the SCA component being invoked.
Operation Namespace (Unicode)In case WebService, it's the namesapce of the WSDL operation as monitored by the data collector. In case SCA component, it's the name of the SCA module containing the SCA component being invoked.
Service Port Namespace (Unicode)In case WebService, it's the namespace of the service port where the message was intercepted. In case SCA component, it's the name of the SCA component being invoked.
Application Server Cell Name (Unicode)The cell name of the application server where the message was intercepted.
Application Server Node Name (Unicode)The node name of the application server where the message was intercepted. In case ND, it can indicate in which cluster member the traffic data happened.
Application Server Cluster Name (Unicode)The name of the application server cluster where the message was intercepted.
Application Server EnvironmentThe type of application server runtime environment in which the data collector is running.
Application Server Name (Unicode)The name of the application server where the message was intercepted.
Local Hostname (Unicode)The name of the host computer where the message was intercepted.
Local IP Address (Unicode)The IP address of the computer where the message was intercepted.
Service Port Name (Unicode)In case WebService, it's the name of the service port where the message was intercepted. In case SCA component, it's the name of the SCA component being invoked.
Service TypeThe type of service. (0=Requester,1=Provider)
Average Elapsed Message Round Trip TimeThe average elapsed round trip time, in milliseconds.
Elapsed Time Message CountThe number of messages observed during this interval that contain an elapsed time value.
Message CountThe number of messages observed during this interval.
Max Elapsed TimeThe largest elapsed time, in milliseconds, of any message observed during the current interval.
Min Elapsed TimeThe smallest elapsed time, in milliseconds, of any message observed during the current interval.
Interval Begin TimeThe inclusive beginning date (UTC) and time when the message was intercepted.
Interval End TimeThe exclusive end date (UTC) and time when the message was intercepted.
Interval LengthThe length of the interval. In minutes.
Elapsed Message Round Trip Time Std DevThe standard deveiation of all elapsed round trip times, in milliseconds, observed during this interval.
Port NumberThe number of the port, 0 - 65535,on which the application server runtime environment that is being monitored is listening.
Average Message LengthThe average message length, in bytes, observed during this interval (including headers whenever possible). Currently, SCA message length are not supported.
DC Info (Unicode)The data collector information used to link to other workspaces that are related to this environment.
Fault CountThe number of faults observed during this interval.
Max Message LengthThe length of the largest message, in bytes, observed during this interval.Currently, SCA message length are not supported.
Message Length Std DevThe standard deviation of all message lengths, in bytes, observed during the current interval.
Min Message LengthThe length of the smallest message, in bytes, observed during this interval.
Service Port Name TypeThe name of service port.
Table Version (Unicode)The version of this inventory table.
TEMA Info (Unicode)The information that is related to the Tivoli Enterprise Monitoring Agent that might to be used to link to other related workpsaces.

View traffic data within TEP

Next we show how ITCAM for SOA operates and how it records the traffic data into the Service_Inventory table. ITCAM for SOA displays the traffic data within TEP graphically. The following figures shows how ITCAM for SOA displays the traffic data.

Figure 4. Message summary workspace view in TEP
Message Summary workspace view in TEP
Figure 5. Services management workspace view in TEP
Services management workspace view in TEP
Figure 6. Performance summary workspace view in TEP
Performance summary workspace view in TEP

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services, Tivoli
ArticleID=424300
ArticleTitle=Using ITCAM for SOA to monitor BPM Systems: Part 2: How ITCAM for SOA monitors service-oriented architectures
publish-date=08282009