On Thu, Apr 1, 2010 at 03:28, Sanka Samaranayake <ssa...@gmail.com> wrote: > Hi Samisa, > > I think the this scope of this project would be to provide a > light-weight tool which allows to monitor the message flows, execution > in each node in response to those message flows to a given input > message primarily for debugging purposes . (Just like the way tcpmon > is used in developing Web services) > > And I guess now the question is whether such a tool is useful ..
Yes, if at least two additional requirements are satisfied: - It should offer the possibility to measure response times. This should be an easy one (except for the usual issues with time measurements in distributed systems): just log the relevant timestamps. - It should not be limited to SOAP and it should not be specifically targeted at Axis2: it should e.g. allow to add JDBC to the picture and it should be easy to add support for other Web service stacks. BTW, it may be a good idea to present the idea to other Apache projects (CXF, ServiceMix, etc.) to see if they are interested in supporting this project as well. > > Anyone cares to share their thoughts ? > > Nilupa > > On Thu, Apr 1, 2010 at 2:51 AM, Samisa Abeysinghe > <samisa.abeysin...@gmail.com> wrote: >> >> >> On Thu, Apr 1, 2010 at 4:53 AM, nilupa bandara <nilu...@gmail.com> wrote: >>> >>> I was thinking about Java Swing based UI >> >> Swing is a good start. But if you look at some of the requirements like >> monitoring multiple instances and correlate them, discussed in this thread, >> it sounds as if we would be better off having a Web interface, rather than a >> desktop client. >> >>> >>> because the client may have >>> to cache whatever messages it already has and will receive, >> >> If you are looking to support message-correlation, as discussed in some >> replies in this thread above, you need to have a persistence storage (a DB >> or something like that) rather than a memory cache. >> Because, some message sequences, like those involved in an async >> invocations, need to have a way to keep the messages, in there, longer, and >> may be there is a server re-start, in the middle. >> Of course, this requirements spend on the scope of this effort. >> Plus, if you want to deal with historic data, and look at what was happening >> to message sequences over time, you got to use a persistence layer. Again >> this might be out of scope for this project, but if this is to be extended >> to support these, you better think of this right now. >> >>> >>> build the >>> message flow and update the UI accordingly. Perhaps there is a better >>> way ? >> >> We already do what you are trying to do, and much more with WSO2 BAM. I am >> tempted to say that Shinding based gadget dashboard is really a compelling >> UI for this. >> I am not trying to take away you project or trying to hinder this effort at >> all. >> I think it will be a good idea for you to have a look at BAM and see what >> the missing pieces are and figure out the right model for this tool. >> Also, having had worked on WSO2 BAM project, I also have some understanding >> on sort of problems that you might run into, when doing this. For e.g., if >> you want to correlate message sequences in a high volume setup, you will be >> swamped by the volume of messages, sooner than later. So correlation for the >> purpose of monitoring is not an easy thing to do. Correlation, for the >> purpose of debugging will not run into this problem, if you run this on a >> controlled environment. However, what you really want to debug is the deal >> clustered setup, and not a staged dev setup, the problem again surfaces. >> You might want to list the objectives and then break them down >> into monitoring and debugging spaces. >> Samisa... >> >>> >>> Thanks >>> Nilupa. >>> >>> On Wed, Mar 31, 2010 at 4:12 PM, Samisa Abeysinghe >>> <samisa.abeysin...@gmail.com> wrote: >>> > What UI technology would be used for this? >>> > >>> > Samisa... >>> > >>> > On Wed, Mar 31, 2010 at 4:26 AM, Andreas Veithen >>> > <andreas.veit...@gmail.com> wrote: >>> >> I was thinking more about something like ITCAM for SOA. >>> >> >>> >> On Tue, Mar 30, 2010 at 13:40, Sanjiva Weerawarana >>> >> <sanj...@opensource.lk> wrote: >>> >>> That runtime monitoring / correlation is what the WSO2 Business >>> >>> Activity >>> >>> Monitor does / is for ... >>> >>> See: http://wso2.com/products/business-activity-monitor/ >>> >>> Sanjiva. >>> >>> >>> >>> On Tue, Mar 30, 2010 at 2:27 PM, Andreas Veithen >>> >>> <andreas.veit...@gmail.com> >>> >>> wrote: >>> >>>> >>> >>>> I was actually referring to scenarios where a service may call other >>> >>>> services, which in turn may call again other services. In these >>> >>>> scenarios, it is not sufficient to simply collect received/sent >>> >>>> messages on different hosts, unless the system is isolated >>> >>>> (development environment) or the request rate is sufficiently low so >>> >>>> that messages can be correlated based on time. Here is a concrete >>> >>>> scenario from a project in my company: >>> >>>> >>> >>>> - Request comes in on an ESB that does security and validation. >>> >>>> - Request is processed by an application server which persists the >>> >>>> received information and publishes a JMS message (pub/sub events). >>> >>>> - The event is consumed by one or more components that may in turn >>> >>>> interact with other services. >>> >>>> >>> >>>> If you want track this flow, it is not sufficient to intercept the >>> >>>> messages on the different hosts: in addition, you need to instrument >>> >>>> the services so that the outgoing requests are correlated with the >>> >>>> incoming requests (by adding SOAP and/or transport headers). What I >>> >>>> would like to be able to do in the above scenario is to enable >>> >>>> end-to-end monitoring on a per-message basis: I add a special SOAP or >>> >>>> HTTP header to the initial request to enable logging and this >>> >>>> information is propagated along the chain. Every service/component >>> >>>> then sends a copy of the incoming/outgoing requests/responses to a >>> >>>> central place where the sequence of events is reconstructed. >>> >>>> >>> >>>> One way this could be achieved is with a tool that postprocesses the >>> >>>> artifacts from the build process. For each artifact, the tool would >>> >>>> disassemble the artifact, instrument the code using a set of AspectJ >>> >>>> aspects and reassemble the artifact for deployment. The >>> >>>> responsibility >>> >>>> of the aspects would be to intercept messages, log them and modify >>> >>>> them to ensure proper correlation. Of course this only works if the >>> >>>> artifacts are J2EE deployables (WARs or EARs). Note that we already >>> >>>> use AspectJ for a similar use case (although at a much smaller scale) >>> >>>> in the transport test suites [1]. Interestingly, this approach would >>> >>>> allow to cover interactions that are not SOAP based, e.g. one could >>> >>>> even intercept the database queries executed during the flow. >>> >>>> >>> >>>> Andreas >>> >>>> >>> >>>> [1] >>> >>>> >>> >>>> https://svn.apache.org/repos/asf/axis/axis2/java/transports/trunk/modules/jms/src/test/java/org/apache/axis2/transport/jms/LogAspect.java >>> >>>> >>> >>>> On Tue, Mar 30, 2010 at 09:11, Srinath Perera <hemap...@gmail.com> >>> >>>> wrote: >>> >>>> > Hi Nilupa; >>> >>>> > >>> >>>> > When we collect messages from a one location by installing proper >>> >>>> > handler that will intercept and send messages to to that one >>> >>>> > location >>> >>>> > (this one location can be a single server, pub/sub channel etc). >>> >>>> > There >>> >>>> > is many ways to make sense of those collected messages. What >>> >>>> > Andreas >>> >>>> > mentioned (following complete transaction) is a one possibility. >>> >>>> > >>> >>>> > I think you should come up with few scenarios on how you would make >>> >>>> > sense of the message. >>> >>>> > >>> >>>> > Thanks >>> >>>> > Srinath >>> >>>> > >>> >>>> > On Sun, Mar 28, 2010 at 9:46 PM, nilupa bandara <nilu...@gmail.com> >>> >>>> > wrote: >>> >>>> >> Hi, >>> >>>> >> >>> >>>> >> First let me thank you for commenting. >>> >>>> >> >>> >>>> >> As far as I understood, what you would like to see from the >>> >>>> >> proposed >>> >>>> >> tool is to view set of messages that are exchanged in reponse to a >>> >>>> >> particular input message. With the understanding that I am having >>> >>>> >> at >>> >>>> >> the momnet, one way to do it is to filter out the central >>> >>>> >> repository >>> >>>> >> of messages based on 'To' , 'From' headers and try to contruct the >>> >>>> >> message chain from it. We can allow the client GUI wich connects >>> >>>> >> to >>> >>>> >> the central repository to provide the paramenters (For instance >>> >>>> >> the >>> >>>> >> value of 'To' header) from which an intelligent filtering can be >>> >>>> >> done >>> >>>> >> for the set of messages avialable at the central repository. >>> >>>> >> >>> >>>> >> Perhaps someone has an idea of a better way of doing it and is >>> >>>> >> willing >>> >>>> >> to share it with us. It would be really nice to hear from them. >>> >>>> >> >>> >>>> >> Thanks in advance ..!! >>> >>>> >> >>> >>>> >> Best Regards, >>> >>>> >> Nilupa >>> >>>> >> >>> >>>> >> On Sat, Mar 27, 2010 at 6:40 PM, Andreas Veithen >>> >>>> >> <andreas.veit...@gmail.com> wrote: >>> >>>> >>> Personally, I think that the added value of extending the SOAP >>> >>>> >>> monitor >>> >>>> >>> module to collect messages in a central place is too limited to >>> >>>> >>> attract enough interest from the user community, so that it will >>> >>>> >>> be >>> >>>> >>> difficult to ensure the evolution of such a project in the >>> >>>> >>> future. >>> >>>> >>> However, what many people are looking for is a tool that allows >>> >>>> >>> to >>> >>>> >>> track the flow of a message through a distributed system, or more >>> >>>> >>> generally to track the sequence of events triggered by a given >>> >>>> >>> input >>> >>>> >>> message (sort of end-to-end transaction monitoring). >>> >>>> >>> >>> >>>> >>> On Wed, Mar 24, 2010 at 23:03, nilupa bandara <nilu...@gmail.com> >>> >>>> >>> wrote: >>> >>>> >>>> Hello, >>> >>>> >>>> >>> >>>> >>>> I am graduate student at Politecnica de Madrid and I am thinking >>> >>>> >>>> of >>> >>>> >>>> proposing a GSoC project this summer. I would like to take >>> >>>> >>>> project >>> >>>> >>>> "Distribute TCP Monitor" descried[1] which is very interesting >>> >>>> >>>> and >>> >>>> >>>> also should be helpful to any Java developer using Apache Axis2 >>> >>>> >>>> Web >>> >>>> >>>> services middleware. I will submit more detailed proposal later. >>> >>>> >>>> I >>> >>>> >>>> would really like to hear any feedback from you. Any suggestions >>> >>>> >>>> or >>> >>>> >>>> features that you would like to see in a "Distributed TCP >>> >>>> >>>> Monitor" >>> >>>> >>>> are >>> >>>> >>>> most welcome. >>> >>>> >>>> >>> >>>> >>>> Best Regards, >>> >>>> >>>> Nilupa Bandara >>> >>>> >>>> >>> >>>> >>>> [1] >>> >>>> >>>> >>> >>>> >>>> Distributed TCP monitor >>> >>>> >>>> >>> >>>> >>>> To use TCP monitor we have to tweak the endpoints, which is bit >>> >>>> >>>> hard >>> >>>> >>>> sometimes (e.g. two channels Async case for Axis2). We can solve >>> >>>> >>>> the >>> >>>> >>>> problem by writing a Axis2 module (Handler) that intercept >>> >>>> >>>> messages >>> >>>> >>>> comes in and goes out of a Axis2 server and send to a UI (via a >>> >>>> >>>> pub/sub channel or a message Box e.g. ) or record them so user >>> >>>> >>>> can >>> >>>> >>>> pull those messages. Also, we can do something to turn the >>> >>>> >>>> module on >>> >>>> >>>> and off remotely, so users can have his module deployed, but >>> >>>> >>>> turn it >>> >>>> >>>> on only when they want to debug the system. >>> >>>> >>>> >>> >>>> >>>> Then we can take this to next level by adding this module to all >>> >>>> >>>> services in a system , configuring modules to send all collected >>> >>>> >>>> messages to a pub/sub channel, and subscribing to those messages >>> >>>> >>>> via >>> >>>> >>>> a >>> >>>> >>>> UI, and depicting those messages through a UI. Then users have a >>> >>>> >>>> TCPMon for a whole system. >>> >>>> >>>> >>> >>>> >>>> >>> >>>> >>>> --------------------------------------------------------------------- >>> >>>> >>>> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >>> >>>> >>>> For additional commands, e-mail: java-dev-h...@axis.apache.org >>> >>>> >>>> >>> >>>> >>>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> --------------------------------------------------------------------- >>> >>>> >>> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >>> >>>> >>> For additional commands, e-mail: java-dev-h...@axis.apache.org >>> >>>> >>> >>> >>>> >>> >>> >>>> >> >>> >>>> >> >>> >>>> >> --------------------------------------------------------------------- >>> >>>> >> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >>> >>>> >> For additional commands, e-mail: java-dev-h...@axis.apache.org >>> >>>> >> >>> >>>> >> >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> > -- >>> >>>> > ============================ >>> >>>> > Srinath Perera, Ph.D. >>> >>>> > WSO2 Inc. http://wso2.com >>> >>>> > Blog: http://srinathsview.blogspot.com/ >>> >>>> > >>> >>>> > >>> >>>> > --------------------------------------------------------------------- >>> >>>> > To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >>> >>>> > For additional commands, e-mail: java-dev-h...@axis.apache.org >>> >>>> > >>> >>>> > >>> >>>> >>> >>>> --------------------------------------------------------------------- >>> >>>> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >>> >>>> For additional commands, e-mail: java-dev-h...@axis.apache.org >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Sanjiva Weerawarana, Ph.D. >>> >>> Founder, Director & Chief Scientist; Lanka Software Foundation; >>> >>> http://www.opensource.lk/ >>> >>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ >>> >>> Member; Apache Software Foundation; http://www.apache.org/ >>> >>> Director; Sahana Software Foundation; http://www.sahanafoundation.org/ >>> >>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ >>> >>> >>> >>> Blog: http://sanjiva.weerawarana.org/ >>> >>> >>> >> >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >>> >> For additional commands, e-mail: java-dev-h...@axis.apache.org >>> >> >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >>> > For additional commands, e-mail: java-dev-h...@axis.apache.org >>> > >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >>> For additional commands, e-mail: java-dev-h...@axis.apache.org >>> >> Samisa... >> -- >> blog: http://samisa-abeysinghe.blogspot.com/ >> > > > > -- > Sanka Samaranayake > > http://sankas.blogspot.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org > For additional commands, e-mail: java-dev-h...@axis.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org For additional commands, e-mail: java-dev-h...@axis.apache.org
