What’s Service-to-Service topology
We can use an example to explain what is Service-to-Service topology. In the example scenario shown in figure1, one BPEL component invokes 4 serial of services to finish its work. Assume the 4 serial of services are heterogeneous, BPEL component has to invoke them by different protocols such as SCA, JAX-RPC, JMS and HTTP.
Figure 1. Example scenario
The above example scenario shows the toplology of such scenario. The BPEL component uses imports (SCA import\JAX-RPC import\JMS import) to invoke the services by corresponding exports. This sceanrio can be implemented in WID, then deploy the applications to WPS(Websphere Process Server) and run. When ITCAM for SOA monitored such scanrio, it will show the topology for such sceanio in Service-to-Service topology view as shown in Figure 2.
Figure 2. Service-to-Service topology view
Here in the Figure 2, one "gear wheel" represents one service, The arrows between gear wheels represent invoking transactions, ITCAM for SOA builds up the relationship between services by the transactions between them. Since the figure shows the relationship between services as topology, we call it Service-to-Service Topology.
ITCAM for SOA could not only show the topology of the transactions, but also show the detail of the transactions such as the traffic data. As shown in figure 2, there are many gear wheels, and when you move mouse over a gear wheel it will show the detail traffic data information, which is shown in the figure 3. traffic data of one transaction.
Figure 3. Traffic data of one transaction
Limit data scope in the topology diagram
The topology view by default will layout all the relationships ITCAM for SOA could find, so the diagram would become very complex if there are many applications involved. If you navigate the Service-to-Serivce topology workspace by opening the "ITCAM for SOA" Navigator view and selecting the "Operational Flows" workspace, the view shows the topology for all flows in the entire enterprise ITCAM for SOA ever monitored. We call this the "All Operational Flows" view, see figure 4 All Operational Flows for details. In figure 4, we can see not only the topology shown as figure 3, but also other topologies from other system that ITCAM for SOA are monitoring
Figure 4. All Operational Flows
The amount of "gear wheel"s will increase significantly along with the increasing of the number of applications, hence the topology diagram for complicated system with lots of applications will become more and more complex. You definitely need a way to find out the part you want to see among the huge number of "gear wheel", else you will get in trouble. There are many approaches to limit the data scope that present in the view to find out what you want to see easily and accurately.
To limit the data scope, you can launch to the operation flows view from different ways, such as launching by specific server node or specific messages. The elements shown in the topology are limited to the scope from which you launched.
1. Link to Service-to-Service topology view by specific server node.
The purpose of this way is to limit the topology in the scope of the selected application server, the topology view shows the relationship of Service-to-Service in the selected application server instead of the entire enterprise.
If you navigate to one of the application server nodes (e.g. AppMem1, see figure 5 Limit data scope to one application server) for a machine and select the "Operational Flow for application Server", the services will be limited to those invocations happened on the selected application Server. Figure 2 Service-to-Service topology view is exactly the result after selecting the "Operational Flow for application Server" for AppMem1, you can see it's clearer and simpler relative to the aggregated service diagram shown in Figure 4 All Operational Flows.
Figure 5. Limit data scope to one application server
2. Link to Service-to-Service topology view by specific message.
The propurse of this way is to limit the topology in scope of message type. In ITCAM for SOA there are two types of messages, Requester and Provider. You can choose to display topology from Requester side or Provider side.
If you navigate to one of the application server nodes (e.g. AppMem1) for the Performance Summary view, the lower pane shows the "Services Inventory". The link icon at the left of the rows in the table can be used to link to the Service-to-Service topology view. See see figure 6 Link to Service-to-Service topology by message.
Figure 6. Link to Service-to-Service topology by message
If you select the link for a "requester" row, the link is called "Operational Flows for Application Server". This link will result in a topology that shows ONLY the selected messge from requester side. See figure 7 message topology view for the result of selecting message from requester side.
If the services are invoked in a ND environment, message instances may run on either of the application members. No matter which application member the message are execute, ITCAM for SOA show the message out. For example, if you link the message topology view from AppMem1, ITCAM for SOA will highlighted the messages that execute on AppMem1 in blue, show other messages in grey to tell they are not execute on AppMem1 but catched by ITCAM for SOA. Figure 7 shows the message topology view of AppMem1. You may notice the blue ones and the grey ones. You can read the Part IV of this serial article, the Using ITCAM for SOA to monitor and analysis ND cluster environment, to learn more about the ITCAM for SOA on ND cluster environment.
Figure 7. message topology view
If you select the link for a "provider" row, the link is called "Operational Flows for Operation". This link will result in a topology that shows ONLY those flows that involve the Service/Operation in that row of the Services Inventory table. Be similar to "requester" view, The node in the "Operational Flows for Operation" topology that represents the selected Service/Operation is highlighted in blue to tell that it is executed, and other nodes in the flow are shown in grey to tell they are not executed.
In general, we do not recommend that users reach the Service-to-Service Topology workspace via the "All Operation Flows" path, we recommend launching to them in one of these two ways, so the topology are scoped to the specific item (Application Server or Service/Operation) that the user is easier to monitor.
Use Service-Group to customize cared services
By default, the Service-to-Service topology view will layout all monitored operations. However, customers may be more interested in a certain part of the services diagram instead of the whole topology. For example, look at figure 2 Service-to-Service topology view, the topology has 4 branches, assume customer only care about the first branch because this branch is related with handling the high-risk applicant.
In some other cases, customer may want to layout unrelated service in one view. For example, in one Web purchase scenario, the "customer order product" and "Logistics deliver product" are two unrelated processes and run in differenct systems, but customer want to show them together to track the whole purchase state from the beginning to the end.
To make this happen, we can use Service group. In the Service-to-Service topology workspace, we can pick up the operation nodes we care, and then choose "Manage Service Groups" command on right click pop up menu, then define service groups in next dialog box. Figure 8 shows how to define the service group.
Figure 8. Define service group
Then the Manage Service Group pannel shown in figure 9 will pop up, we could define a "High risk verfication" for the choosed services.
Figure 9. Manage Service Group
Once defined a service group, you could check the state of the service from "Service Groups Summary" view. To visit the service group view, go to the "ITCAM for SOA" navigator, and then choose "Service Groups Summary" command from the pop up menu. See figure 10 Service groups summary view, the right part of the diagram shows the state of defined service gourp.
Figure 10. Service groups summary view
The status of the service group we just defined is shown in the summary view. In this view, we can quickly monitor the status of the services we care. If the service group got problem, it has 4 states, which are
By defining the service group, we can logically group the services to match the business meaning. This provides customer ability to monitor their enterprise not only at IT level but even at Business Level.
Use SystemContext qualifier to avoid fragment in Service-to-Service topology
In the topology view, you may find that the relationship are broken in case of the none-SCA bindings, thus the topology looks fragmentally and hard to understand. See figure 11 The fragmented topology view, it's the Service-to-Service topology of the similar scenario with the original scenario whose service topology is shown in Figure 2. It contains the none-SCA bindings without applying the SystemContext qualifier.
Figure 11. The fragmented topology view
In figure 11, there are some pieces of fragments; this makes people hard to understand the relationship of correlative services. Such fragments happened here because the relationship data comes from the transactions, and transactions need system context to know the invocation source and target. System Context is propagated with bindings, however, by default, only SCA binding will propagate System Context, the other bindings won't propogate. So when the system context is missing, the ITCAM for SOA can not get to know the invocation soure and target to build up relationship, hence the fragments in topology view will appear.
To avoid such fragments and show the whole picture, the System Context must be propagated. From WPS 6.2 release, the System Context propagation are support by none-SCA bindings (include JMS/MQ/JAX-RPC/JAX-WS/HTTP/JCA bindings). We need to add "Propagate system context" to the import binding to enable the propagation since the System Context is designed to not propagate by default.
1. Using WID18.104.22.168
Than WID22.214.171.124 already support add "Propagate system context" qualifier by GUI. In the WID assembler view, choose the import component, than changed the "Propagation" properties, set "Propagate system context" to true. See figure 12 Enable system context propagation in WID126.96.36.199
Figure 12. Enable system context propagation in WID188.8.131.52
After setting the qualifier, ITCAM for SOA can get to know the invocation source and target from the system context to build up the necessary relationship between the service requirester and provider. From the Fragment disappeared picture shown in figure 13, you can see the fragments are disappeared, compared with the topology view shown in figure 11.
Figure 13. Fragment disappeared
2. Using WID 6.2
We strongly recommend customers to upgrade their WID to 184.108.40.206 if they are uing WID 6.2. Else, they have to add the qualified manually by modify the Import file since the enablement of "Propagate system context" is not support by WID 6.2.
Here is an example of how to enable the "Propagate system context" manually, you need to find the *.import file to propagate the system context and open it by a text editor. Then add string "<scdl:bindingQualifier xsi:type="scdl:IsTargetSCA" value="true"/>"in the <esbBinding></esbBinding> pairs. See the bold text in the following snippet. This is fully equivalent to enable "Propagate system context" with the GUI way for WID 220.127.116.11.
<?xml version="1.0" encoding="UTF-8"?> <scdl:import xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:Binding4="http://tSessionAsyncLib/testInterface/Binding4" xmlns:ns1="http://tSessionAsyncLib/testInterface" xmlns:scdl="http://www.ibm.com/xmlns/prod/websphere/scdl/6.0.0" xmlns:webservice="http://www.ibm.com/xmlns/prod/websphere/scdl/webservice/6.0.0" xmlns:wsdl="http://www.ibm.com/xmlns/prod/websphere/scdl/wsdl/6.0.0" displayName="targetWSImport" name="targetWSImport"> <interfaces><interface xsi:type="wsdl:WSDLPortType" portType="ns1:testInterface"/> </interfaces> <esbBinding xsi:type="webservice:WebServiceImportBinding" endpoint="http://localhost:9080/tSessionBusinessContextTargetWeb/sca /testInterfaceExport1" port="Binding4:testInterfaceExport1_testInterfaceHttpPort" service="Binding4:testInterfaceExport1_testInterfaceHttpService" userContextPropagationEnabled="true"> <scdl:bindingQualifier xsi:type="scdl:IsTargetSCA" value="true"/> </esbBinding> </scdl:import>
In this part you've learned what Service-to-Service topology is and how to use Service-to-Service topology view to monitor WDPE runtime.There are a lot of best practices to simplify the diagram and fast determining the interested service snippets, such as limiting the topology shown scope, defining the Service-Group and enabling SystemContext qualifier propgation to avoid diagram fragment. It's useful for customers to use the ITCAM for SOA to efficently and easily monitor thir BPM system.
- Visit the WDPE product page.
- Learn more in the WebSphere Dynamic Process Edition information center.
- Learn more in the WebSphere Message Modeler information center.
- Learn more in the WebSphere Process Server information center.
- Learn more in the WebSphere Business Services Fabric infromation center.
- Learn more in the WebSphere Business Monitor infromation center.
- Learn more in the ITCAM for SOA 7.1.1 infromation center.
- View the IBM Tivoli Monitoring installation guide.
- Read the Redbook IBM Tivoli Composite Application Manager Family Installation, Configuration, and Basic Usage, (SG24-7151-02), January 2008.
Dig deeper into SOA and web services on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.