Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
PolicyBuilder TCPMonitor Integration
Contents
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.