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.