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
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
| ModuleName | Component Name | OperationName | Service Type | Message Count | Avg Message Size | Avg Elapsed Time | Fault Count |
|---|---|---|---|---|---|---|---|
| AccountVerification | CustomerRetrieval | InputCriterion | Requester | 2 | 0 | 291 | 0 |
| AccountVerification | CustomerRetrieval | InputCriterion | Provider | 2 | 0 | 290 | 0 |
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
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)
- 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 Name | Explanation and Usage |
|---|---|
| Origin Node | The application environment instance of the managed system. |
| Interval Status | The 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 Environment | The 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 Type | The type of service. (0=Requester,1=Provider) |
| Average Elapsed Message Round Trip Time | The average elapsed round trip time, in milliseconds. |
| Elapsed Time Message Count | The number of messages observed during this interval that contain an elapsed time value. |
| Message Count | The number of messages observed during this interval. |
| Max Elapsed Time | The largest elapsed time, in milliseconds, of any message observed during the current interval. |
| Min Elapsed Time | The smallest elapsed time, in milliseconds, of any message observed during the current interval. |
| Interval Begin Time | The inclusive beginning date (UTC) and time when the message was intercepted. |
| Interval End Time | The exclusive end date (UTC) and time when the message was intercepted. |
| Interval Length | The length of the interval. In minutes. |
| Elapsed Message Round Trip Time Std Dev | The standard deveiation of all elapsed round trip times, in milliseconds, observed during this interval. |
| Port Number | The number of the port, 0 - 65535,on which the application server runtime environment that is being monitored is listening. |
| Average Message Length | The 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 Count | The number of faults observed during this interval. |
| Max Message Length | The length of the largest message, in bytes, observed during this interval.Currently, SCA message length are not supported. |
| Message Length Std Dev | The standard deviation of all message lengths, in bytes, observed during the current interval. |
| Min Message Length | The length of the smallest message, in bytes, observed during this interval. |
| Service Port Name Type | The 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. |
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
Figure 5. Services management workspace view in TEP
Figure 6. Performance summary workspace view in TEP
-
Learn more SCA invocation pattern in WebSphere Process Server V6.1
to aware how ITCAM for SOA get the message count.
-
ITCAM for SOA 7.1.1 information center
-
IBM Tivoli Monitoring installation guide
IBM Tivoli Monitoring installation guide
-
Redbook:
IBM Tivoli
Composite Application Manager Family Installation, Configuration, and Basic Usage,(SG24-7151-02), January 2008.
-
Introduction to
WebSphere Dynamic Process Edition
-
WebSphere Dynamic Process Edition Information Center
-
WebSphere Message Modeler Information Center
-
WebSphere Process Server Information Center
-
WebSphere Business Services Fabric Information Center
-
WebSphere Business Monitor Information Center
Yunjie 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 (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 (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.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
