Skip to main content
Jump to: navigation, search

PolicyBuilder TCPMonitor Integration

TCP monitoring Tool Integration with proposed Policy Builder

Proposed Policy Builder component for STP policy Editor is a tool which basically would extract WS : Policy assertions from WS: policy compliant messages it is provided with . So the primary requirement of the policy builder tool is to derive one or more policy assertions from the respective message sources it has been registered with .

Inputs and Outputs and Other Extensions

In abstract sense Policy builder should have extensions points in input source , output destination and formats/WS standards types it support , which would make it a fully extensible framework where different input/output sources , various XML wire types and schemas can be supported.

Input Sources  -Incoming message for the policy builder component can be  registered of various input  
sources  system supports such as  from  XML message types stored in local repositories ,  Live message
streams coming from TCP monitoring tools , Databases ,etc…
Output Sources  –  The in-memory model of derived policy instances after Policy extraction process  can
be stored  at different destinations  including local file system , database or even in remote repositories. 
For  STP policy editor integration (in-order to edit the extracted policy instance  ) ,  this can best be
achieved storing in a local file system under current project .
Message Formats and Standards ­­ - Extensions should be provided for various XML message types to process and
various WS:compliant standards that the extraction process supports .

Using the concrete implementations (set of exemplars) for various extension points of the framework as described above would fully utilize the power of the policy builder tool integrated with STP policy editor.

Providing Live Message Streams

One of the most important requirements of all , for the aforementioned tool is to provide it with Live message streams to extract ws compliant policy instances for the real time messages coming from Web Services , ESB’s and other SOA end points. Apache TCP Mon , Eclipse TCP/IP monitor and some other third party plugins provide this kind of TCP monitoring functionality currently. Integrating with such tooling with Policy Builder may require some design decisions and requirements to full fill . Following describe these in abstract point of view.

   * .    First of all relevant Live stream tools should be registered under message sources as a input 
          source. Necessary extension points must be provided by these tools to register them as services 
          for the policy builder .

   * ·    Monitoring tool should support asynchronous monitoring facility in-order to provide messages 
          real-time without users refreshing the view time to time. However currently most of the tools
          do support this functionality .  

   * ·    The monitoring tools should have nice interface where the messages  of the live stream would be
          displayed accordingly and appropriately in a very usable manner.

   * ·    After registering the live stream as a message source  , the monitoring tool should support the
          integration of policy builder tool  by providing necessary options to redirect the messages it 
          has currently to the policy builder in-order for the policy extraction process to take place .

   * ·    Optionally it would be useful if Monitoring tools could provide validation/filtering  mechanism 
          to differentiate normal HTTP kind (text/MultiPart/MTOM )of requests from XML type HTTP requests 
          so that only XML messages will be provided for the policy extraction process. This will reduce
          improve the usability and efficiency of the tool.

How Eclipse TCP/IP Monitor Can be used as a Message Monitoring Tool

Eclipse has an internal TCP/IP monitor which is used basically for this http packet monitoring functionality. Eclipse “TCP/IP Monitor” is a sub project of Eclipse WTP .Like many other monitoring tools ,it act as an intermediary where client has to point to the intermediate location rather than the original endpoint and tool will send and receive requests and responses while acting as a intermediate Listener. To use this functionality user has to mention local listening port as well as the actual intended endpoint per monitor connection which he want to achieve.


Eclipse TCP/IP monitor can be accessed by Window > Preferences > Run/Debug > TCP/IP Monitor or Window > View > Debug > TCP/IP Monitor , menu links of the IDE . Tool has the ability to monitor several endpoints with asynchronously (non-blocking) displaying messages it has intercepted. However several enhancements will be needed to better support the functionality of the proposed policy builder plug-in .

   * ·    Input Source for the policy builder may be provided by a import Wizard found in File > Import or
          in  context sensitive menus. File > Import > Policy > Derived Policies is an good example for entry
          point of the plug-in . Here users will be able to have the choice of selecting a relevant message 
          source that has been registered in message sources extension registry. Thus  among different message
          sources such as Database location , local File System , etc ,  “From TCP/IP Monitor” choice need to 
          be provided in the wizard options list for message sources. Hence TCP/IP monitor plug-in should 
          in-turn be able to provide necessary extension points to register it as service for providing live 
          message streams.

   * ·    Selection of “From TCP/IP Monitor“ as a message source would provide several possibilities to 
          integrate the monitoring tool for the policy extraction process as described below.
              >  As the next step of using live message stream for the extraction process users can be 
                 provided with the TCP/IP monitoring UI embedded inside the wizard page itself so that users 
                 can create connections , monitor the messages , and produce the required messages for the 
                 policy builder within the wizard and on the fly . Hence to cater such requirement necessary
                 UI extensions should be provided by the tool.
              >  As an general approach TCP/IP monitor preference page can show up “Enable Policy Builder 
                 Integration” option (if TCP/IP monitor is registered as a source) so that Window > View > 
                 Debug > TCP/IP Monitor  View would contain necessary UI commands and necessary context 
                 sensitive menus (per message) to redirect messages for the policy extraction process . View  
                 could also facilitate selecting single or multiple messages for this process with nice ui  
              >  Rather than using traditional TCP/IP view we  could use a whole new Modified View panel (ie 
                 :- Window > View > Policy Builder > Monitor  ) by using the extensions provided , where all  
                 the aforementioned requirements can be met  with enhanced and a fully customized  UI . (ie:- 
                 Tabs for each connection created , stacked messages with context sensitive menus for policy 
                 extraction ,formatting , etc)  

   * -    TCP/IP monitor currently  supports XML pretty printing / formatting so that incoming requests or 
          responses are  presented in a nice an appropriate manner . However necessary extension points may be 
          needed if we are going for a fully customized view . It will be useful if TCP/IP monitor could 
          provide an extension point to display policy headers in a  view. 

   * -    TCP/IP monitor should be able to render out/extract full message along with headers (ie:- SOAP Body 
          + Headers ) in their view , since headers are a major requirement for policy extraction process.

   * -    Necessary UI features could further enhance the user experience and efficiency of the policy builder 
          tool .Some of the features are ,
              >  Links and context sensitive menus for the intercepted messages so that single or multiple 
                 requests can be sent to the policy extraction process to produce derived  policy instances.
                            -User can highlight single/multiple messages  in the view Panel and press “Extract
                             Policy ” command
                            -Right click relevant message/s and through that pop-up menu link
                             “Policy Builder > Extract Policy”
              >  Multiple tabs for each connection would provide a  nice User Experience where user be able
                 to clearly differentiate messages coming from each SOA endpoint

   * -    Additionally it would be a useful (Although optional) addition , if the Monitoring View could 
          provide a way to filter valid  XML Messages in-to the view Panel message stack so that it would 
          filter out Malformed / Fault XML messages  for the Policy Extraction process , thus increasing 
               >  Ie:- providing “Filter” option within the message stack panel would be a good way to go 
                  with,in this scenario.


GoogleDoc Reference

Policy-Builder Proposal

Back to the top