Notice: this Wiki will be going read only early in 2024 and edits will no longer be 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.
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
interface.
> 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.
Ie:-
-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
efficiency.
> Ie:- providing “Filter” option within the message stack panel would be a good way to go
with,in this scenario.
Links