Return-Path: Delivered-To: apmail-axis-java-dev-archive@www.apache.org Received: (qmail 63930 invoked from network); 1 Apr 2010 00:51:38 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Apr 2010 00:51:38 -0000 Received: (qmail 99111 invoked by uid 500); 1 Apr 2010 00:51:37 -0000 Delivered-To: apmail-axis-java-dev-archive@axis.apache.org Received: (qmail 98821 invoked by uid 500); 1 Apr 2010 00:51:37 -0000 Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@axis.apache.org Delivered-To: mailing list java-dev@axis.apache.org Received: (qmail 98813 invoked by uid 99); 1 Apr 2010 00:51:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Apr 2010 00:51:37 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=AWL,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of samisa.abeysinghe@gmail.com designates 209.85.223.171 as permitted sender) Received: from [209.85.223.171] (HELO mail-iw0-f171.google.com) (209.85.223.171) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Apr 2010 00:51:33 +0000 Received: by iwn1 with SMTP id 1so522688iwn.27 for ; Wed, 31 Mar 2010 17:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=HqrSQmQwX+2osh46jyXteP9Zjb7nwTidi3gC3eqOLQo=; b=cCAAK8D2+EPELrVtfdu9cvkovNnpisz8o1z40cFahekbZWWfxwXQRNxSyTBrNT40Oq 3rmeCRRD4I6TdThY0BqMs3l6GcVhLgMtrMemEXwh2iSepJsnTP7tQKJQ1gybz/M+F4Uz aaql5OfehnJGujzXpsa3WcLQa7ZwyP4qGU3vk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Ojb42SzbHqk/kxJGhYsoqUwkN2cjh/qxKd11n1QzjwoY3MXz0nPhAOvnyaguLAEdkA 5l/PPGaGLTyMqhk/Omt/yJEjoqT52dLC5QPfvZDVS0OvAZ7bMc3B2jAuA5FpwfDN87X4 postEp6L4Ebh9VYwIafC9x7sNRCvjZeZRPIPs= MIME-Version: 1.0 Received: by 10.231.153.137 with HTTP; Wed, 31 Mar 2010 17:51:12 -0700 (PDT) In-Reply-To: References: <3054da0f1003241438n62153ab8hf7201a18d98a58c4@mail.gmail.com> <3054da0f1003241503x4805a81bt10c2b2f44300bc0b@mail.gmail.com> <3054da0f1003280916o3a5760b3oe80529a1f33ff332@mail.gmail.com> Date: Thu, 1 Apr 2010 06:21:12 +0530 Received: by 10.231.151.197 with SMTP id d5mr659749ibw.73.1270083072420; Wed, 31 Mar 2010 17:51:12 -0700 (PDT) Message-ID: Subject: Re: [GSoC Project Proposal] Distributed TCP Monitor From: Samisa Abeysinghe To: java-dev@axis.apache.org Content-Type: multipart/alternative; boundary=0016e68ea0205dec490483224263 --0016e68ea0205dec490483224263 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 1, 2010 at 4:53 AM, nilupa bandara 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 > wrote: > > What UI technology would be used for this? > > > > Samisa... > > > > On Wed, Mar 31, 2010 at 4:26 AM, Andreas Veithen > > wrote: > >> I was thinking more about something like ITCAM for SOA. > >> > >> On Tue, Mar 30, 2010 at 13:40, Sanjiva Weerawarana > >> 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.veithen@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 > 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 > >>>> > 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 > >>>> >> 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 > >>>> >>> 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-unsubscribe@axis.apache.org > >>>> >>>> For additional commands, e-mail: java-dev-help@axis.apache.org > >>>> >>>> > >>>> >>>> > >>>> >>> > >>>> >>> > --------------------------------------------------------------------- > >>>> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org > >>>> >>> For additional commands, e-mail: java-dev-help@axis.apache.org > >>>> >>> > >>>> >>> > >>>> >> > >>>> >> > --------------------------------------------------------------------- > >>>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org > >>>> >> For additional commands, e-mail: java-dev-help@axis.apache.org > >>>> >> > >>>> >> > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > ============================ > >>>> > Srinath Perera, Ph.D. > >>>> > WSO2 Inc. http://wso2.com > >>>> > Blog: http://srinathsview.blogspot.com/ > >>>> > > >>>> > > --------------------------------------------------------------------- > >>>> > To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org > >>>> > For additional commands, e-mail: java-dev-help@axis.apache.org > >>>> > > >>>> > > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org > >>>> For additional commands, e-mail: java-dev-help@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-unsubscribe@axis.apache.org > >> For additional commands, e-mail: java-dev-help@axis.apache.org > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org > > For additional commands, e-mail: java-dev-help@axis.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org > For additional commands, e-mail: java-dev-help@axis.apache.org > > Samisa... -- blog: http://samisa-abeysinghe.blogspot.com/ --0016e68ea0205dec490483224263 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 1, 2010 at 4:53 AM, nilupa b= andara <nilupas@g= mail.com> wrote:
I was thinking about Java Swing based UI

Sw= ing is a good start. But if you look at some of the requirements like monit= oring multiple instances and correlate them, discussed in this thread, it s= ounds as if we would be better off having a Web interface, rather than a de= sktop client.=A0
=A0
because the client may have<= br> to cache whatever messages it already has and will receive,

If you are looking to support message-correlation, as dis= cussed in some replies in this thread above, you need to have a=A0persisten= ce=A0storage (a DB or something like that) rather than a memory cache.
Because, some message=A0sequences, like those involved in an async inv= ocations, need to have a way to keep the messages, in there, longer, and ma= y be there is a server re-start, in the middle.=A0
Of course, thi= s requirements=A0spend=A0on the scope of this effort.=A0

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=A0pe= rsistence=A0layer. Again this might be out of scope for this project, but i= f this is to be extended to support these, you better think of this right n= ow.=A0
=A0
build the
message flow and update the UI accordingly. Perhaps there is a better
way ?=A0

We=A0already=A0do what you are try= ing to do, and much more with WSO2 BAM. I am tempted to say that Shinding b= ased gadget dashboard is really a compelling UI for this.=A0

=
I am not trying to take away you project or trying to hinder this effo= rt at all.=A0
I think it will be a good idea for you to have a lo= ok at BAM and see what the missing=A0pieces=A0are and figure out the right = model for this tool.=A0

Also, having had worked on WSO2 BAM project, I also hav= e some understanding on sort of problems that you might run into, when doin= g this. For e.g., if you want to correlate message sequences in a high volu= me setup, you will be swamped by the volume of messages, sooner than later.= So=A0correlation=A0for the purpose of=A0monitoring=A0is not an easy thing = to do. Correlation, for the purpose of debugging will not run into this pro= blem, if you run this on a controlled environment. However,=A0what=A0you re= ally want to debug is the deal clustered setup, and not a staged dev setup,= the=A0problem=A0again surfaces.=A0

You might want to list the objectives and then break th= em down into=A0monitoring=A0and debugging spaces.=A0

Samisa...
=A0

Thanks
Nilupa.

On Wed, Mar 31, 2010 at 4:12 PM, Samisa Abeysinghe
<samisa= .abeysinghe@gmail.com> wrote:
> What UI technology would be us= ed for this?
>
> Samisa...
>
> On Wed, Mar 31, 2010 at 4:26 AM, Andreas Veithen
> <andreas.veithen@gmail= .com> wrote:
>> I was thinking more about something like ITCAM for SOA.
>>
>> On Tue, Mar 30, 2010 at 13:40, Sanjiva Weerawarana
>> <sanjiva@opensource.lk= > wrote:
>>> That runtime monitoring / correlation is what the WSO2 Busines= s Activity
>>> Monitor does / is for ...
>>> See:=A0http://wso2.com/products/business-activity-monit= or/
>>> Sanjiva.
>>>
>>> On Tue, Mar 30, 2010 at 2:27 PM, Andreas Veithen <andreas.veithen@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 sufficien= tly low so
>>>> that messages can be correlated based on time. Here is a c= oncrete
>>>> scenario from a project in my company:
>>>>
>>>> - Request comes in on an ESB that does security and valida= tion.
>>>> - Request is processed by an application server which pers= ists 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 inter= cept 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 en= able
>>>> end-to-end monitoring on a per-message basis: I add a spec= ial SOAP or
>>>> HTTP header to the initial request to enable logging and t= his
>>>> information is propagated along the chain. Every service/c= omponent
>>>> then sends a copy of the incoming/outgoing requests/respon= ses to a
>>>> central place where the sequence of events is reconstructe= d.
>>>>
>>>> One way this could be achieved is with a tool that postpro= cesses the
>>>> artifacts from the build process. For each artifact, the t= ool would
>>>> disassemble the artifact, instrument the code using a set = of AspectJ
>>>> aspects and reassemble the artifact for deployment. The re= sponsibility
>>>> of the aspects would be to intercept messages, log them an= d modify
>>>> them to ensure proper correlation. Of course this only wor= ks if the
>>>> artifacts are J2EE deployables (WARs or EARs). Note that w= e already
>>>> use AspectJ for a similar use case (although at a much sma= ller scale)
>>>> in the transport test suites [1]. Interestingly, this appr= oach would
>>>> allow to cover interactions that are not SOAP based, e.g. = one could
>>>> even intercept the database queries executed during the fl= ow.
>>>>
>>>> Andreas
>>>>
>>>> [1]
>>>> https://svn.apache.org/repos/asf/axis/ax= is2/java/transports/trunk/modules/jms/src/test/java/org/apache/axis2/transp= ort/jms/LogAspect.java
>>>>
>>>> On Tue, Mar 30, 2010 at 09:11, Srinath Perera <hemapani@gmail.com> wrote:
>>>> > Hi Nilupa;
>>>> >
>>>> > When we collect messages from a one location by insta= lling proper
>>>> > handler that will intercept and send messages to to t= hat one location
>>>> > (this one location can be a single server, pub/sub ch= annel etc). There
>>>> > is many ways to make sense of those collected message= s. What Andreas
>>>> > mentioned (following complete transaction) is a one p= ossibility.
>>>> >
>>>> > 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 <<= a href=3D"mailto:nilupas@gmail.com">nilupas@gmail.com>
>>>> > wrote:
>>>> >> Hi,
>>>> >>
>>>> >> First let me thank you for commenting.
>>>> >>
>>>> >> As far as I understood, what you would like to se= e from the proposed
>>>> >> tool is to view set of messages that are exchange= d 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 GU= I wich connects to
>>>> >> the central repository to provide the paramenters= (For instance the
>>>> >> value of 'To' header) from which an intel= ligent filtering can be done
>>>> >> for the set of messages avialable at the central = repository.
>>>> >>
>>>> >> Perhaps someone has an idea of a better way of do= ing it and is willing
>>>> >> to share it with us. It would be really nice to h= ear from them.
>>>> >>
>>>> >> Thanks in advance ..!!
>>>> >>
>>>> >> Best Regards,
>>>> >> Nilupa
>>>> >>
>>>> >> On Sat, Mar 27, 2010 at 6:40 PM, Andreas Veithen<= br> >>>> >> <= andreas.veithen@gmail.com> wrote:
>>>> >>> Personally, I think that the added value of e= xtending the SOAP monitor
>>>> >>> module to collect messages in a central place= is too limited to
>>>> >>> attract enough interest from the user communi= ty, so that it will be
>>>> >>> difficult to ensure the evolution of such a p= roject in the future.
>>>> >>> However, what many people are looking for is = a tool that allows to
>>>> >>> track the flow of a message through a distrib= uted system, or more
>>>> >>> generally to track the sequence of events tri= ggered by a given input
>>>> >>> message (sort of end-to-end transaction monit= oring).
>>>> >>>
>>>> >>> On Wed, Mar 24, 2010 at 23:03, nilupa bandara= <nilupas@gmail.com>
>>>> >>> wrote:
>>>> >>>> Hello,
>>>> >>>>
>>>> >>>> I am graduate student at Politecnica de M= adrid and I am thinking of
>>>> >>>> proposing a GSoC project this summer. I w= ould like to take project
>>>> >>>> "Distribute TCP Monitor" descri= ed[1] which is very interesting and
>>>> >>>> also should be helpful to any Java develo= per using Apache Axis2 Web
>>>> >>>> services middleware. I will submit more d= etailed proposal later. I
>>>> >>>> would really like to hear any feedback fr= om 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 e= ndpoints, which is bit hard
>>>> >>>> sometimes (e.g. two channels Async case f= or Axis2). We can solve the
>>>> >>>> problem by writing a Axis2 module (Handle= r) that intercept messages
>>>> >>>> comes in and goes out of a Axis2 server a= nd send to a UI (via a
>>>> >>>> pub/sub channel or a message Box e.g. ) o= r record them so user can
>>>> >>>> pull those messages. Also, we can do some= thing to turn the module on
>>>> >>>> and off remotely, so users can have his m= odule deployed, but turn it
>>>> >>>> on only when they want to debug the syste= m.
>>>> >>>>
>>>> >>>> Then we can take this to next level by ad= ding this module to all
>>>> >>>> services in a system , configuring module= s to send all collected
>>>> >>>> messages to a pub/sub channel, and subscr= ibing 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-unsubscribe@axis.apache.org=
>>>> >>>> For additional commands, e-mail: java-dev-help@axis.apache.org=
>>>> >>>>
>>>> >>>>
>>>> >>>
>>>> >>> ---------------------------------------------= ------------------------
>>>> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org=
>>>> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>> >>>
>>>> >>>
>>>> >>
>>>> >> -------------------------------------------------= --------------------
>>>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>> > Srinath Perera, Ph.D.
>>>> > =A0 WSO2 Inc. http://wso2.com
>>>> > =A0 Blog: http://srinathsview.blogspot.com/
>>>> >
>>>> > -----------------------------------------------------= ----------------
>>>> > To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>>> > For additional commands, e-mail: java-dev-help@axis.apache.org
>>>> >
>>>> >
>>>>
>>>> ----------------------------------------------------------= -----------
>>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Sanjiva Weerawarana, Ph.D.
>>> Founder, Director & Chief Scientist; Lanka Software Founda= tion;
>>> 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-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
> ---------------------------------------------------------------------<= br> > To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org

Samisa...
--<= br>blog:=A0http://samisa= -abeysinghe.blogspot.com/=A0


--0016e68ea0205dec490483224263--