Return-Path: Delivered-To: apmail-synapse-dev-archive@www.apache.org Received: (qmail 31073 invoked from network); 1 Aug 2010 16:35:59 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Aug 2010 16:35:59 -0000 Received: (qmail 43309 invoked by uid 500); 1 Aug 2010 16:35:59 -0000 Delivered-To: apmail-synapse-dev-archive@synapse.apache.org Received: (qmail 43262 invoked by uid 500); 1 Aug 2010 16:35:58 -0000 Mailing-List: contact dev-help@synapse.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@synapse.apache.org Delivered-To: mailing list dev@synapse.apache.org Received: (qmail 43255 invoked by uid 99); 1 Aug 2010 16:35:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Aug 2010 16:35:58 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of charith.dhanushka@gmail.com designates 209.85.215.170 as permitted sender) Received: from [209.85.215.170] (HELO mail-ey0-f170.google.com) (209.85.215.170) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Aug 2010 16:35:54 +0000 Received: by eyh6 with SMTP id 6so6417472eyh.15 for ; Sun, 01 Aug 2010 09:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=2e1D/DmFvZrdkDmCU6wE2wt1l5Qy/q8KYlFbKnJMvsQ=; b=T+JaeJfqhMuhwnLy8YSWJblnYZ8gXuiXSZDRV7YvrZQ4e6ZpbV5W36Mh7nvNHroEMn iEieX+7bsD9/FjzHNVwZjKMdSbpGZAK0AlH7CBZhxPtBy24MamOzdkRF6SJO9bjsBp8x iX5es5FTARCA0DeCeZF5I6kokkimrdX0WiYvk= 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=NwgTUYLyn6AzeseqgBp7NA4P9fP9it61Y4CrPSG/f3xLm3m+A2hMvTpaYoWZmt0YhI AVNaOKTZOrv3lwGoLodW2QaegUynx0ZzHSLnGBXvtTi6zhB/Uu1foV9RJCcPmP8rHFtU XY2mS5+CK5WUnrF/rHrEKLP2rLUltjATCiheg= MIME-Version: 1.0 Received: by 10.14.47.16 with SMTP id s16mr3002700eeb.52.1280680261845; Sun, 01 Aug 2010 09:31:01 -0700 (PDT) Received: by 10.14.29.73 with HTTP; Sun, 1 Aug 2010 09:31:01 -0700 (PDT) In-Reply-To: References: Date: Sun, 1 Aug 2010 22:01:01 +0530 Message-ID: Subject: Re: Storing Messages in the JMS Transport From: Charith Wickramarachchi To: dev@synapse.apache.org Content-Type: multipart/alternative; boundary=90e6ba539ed414022d048cc59c5a --90e6ba539ed414022d048cc59c5a Content-Type: text/plain; charset=ISO-8859-1 On Sun, Aug 1, 2010 at 7:03 PM, Ruwan Linton wrote: > Charith, > > I think the problem you have to solve is more broader :-) you have to keep > the complete state of the message, meaning what is its endpoint, ow it > reached this endpoint, for example if it is via a proxy foo, you need to > make sure that the response message after delivering it later gets > dispatched to the out sequence of the proxy, or if there are any other > mediators after the send (endpoint) you need to remember those to execute > that rest of the sequence after delivering the message and so forth. > > So ideally what we should be doing is to keep a reference to the > configuration in its complete serialization format. So in effect you need to > build up a referencing mechanism to refer to any bit of the synapse > configuration, that way we can support message persistence not only for > messages sending out, but also for any mediation, in the future. :-) > > Thanks for the feed back. I'll come up with a design for this soon. At a high level i feel like this can be achieved by keeping a JNDI Context at the Synpase Environment and using a string based naming syntax to uniquely lookup any point in the configuration. We can populate the Context while building the Synapse configuration model. WDYT? > Thanks, > Ruwan > > > On Sun, Aug 1, 2010 at 6:43 PM, Charith Wickramarachchi < > charith.dhanushka@gmail.com> wrote: > >> Thanks for the reply. >> >> On Sun, Aug 1, 2010 at 6:25 PM, Paul Fremantle wrote: >> >>> Why do you object to serializing the endpoint? >> >> Seems like it would be >>> the right thing to do. >> >> >> Here what i mean by serializing is serializing it to a ObjectMessage >> in JMS. >> >> >>> Can't it be serialized as a address in >>> the message header? >>> >> >> If i do that, in a re delivery scenario will i be able to use the >> original endpoint to re-deliver the message ?. >> -- Charith >> >>> >>> Paul >>> >>> On Sun, Aug 1, 2010 at 7:24 AM, Charith Wickramarachchi >>> wrote: >>> > Hi devs , >>> > While working on the patch for the JMS Based Message store i got stuck >>> in >>> > the place where i need to persist the Message. >>> > Idea of persisting message is to later it can be redelivered >>> or views later. >>> > So in the InMemory Message store case when storing i kept >>> the reference to >>> > the Message context (built) and its associated endpoint. >>> > Keeping a reference to the Endpoint in this case is not costly since >>> its >>> > just an Object reference. >>> > But keeping the Endpoint associated with a Message Context is >>> > bit problematic in a persistent scenario since there is no point >>> > in serializing the Endpoint :). >>> > I have 2 solutions to solve this. >>> > >>> > Make all the endpoints globally accessible from the configuration (Even >>> > the anonymous ones Ex : say a endpoint defined in a send mediator). so >>> that >>> > i need only to keep the name of the endpoint with the Message. >>> > Support Message store feature only with the Endpoints defined globally. >>> > >>> > WDYT ? >>> > >>> > -- >>> > Charith Dhanushka Wickramarachchi >>> > http://charithwiki.blogspot.com/ >>> > >>> > >>> >>> >>> >>> -- >>> Paul Fremantle >>> Co-Founder and CTO, WSO2 >>> Apache Synapse PMC Chair >>> OASIS WS-RX TC Co-chair >>> >>> blog: http://pzf.fremantle.org >>> paul@wso2.com >>> >>> "Oxygenating the Web Service Platform", www.wso2.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org >>> For additional commands, e-mail: dev-help@synapse.apache.org >>> >>> >> >> >> -- >> Charith Dhanushka Wickramarachchi >> http://charithwiki.blogspot.com/ >> >> > > > -- > Ruwan Linton > Software Architect & Product Manager, WSO2 ESB; http://wso2.org/esb > WSO2 Inc.; http://wso2.org > > Lean . Enterprise . Middleware > > phone: +1 408 754 7388 ext 51789 > email: ruwan@wso2.com; cell: +94 77 341 3097 > blog: http://blog.ruwan.org > linkedin: http://www.linkedin.com/in/ruwanlinton > google: http://www.google.com/profiles/ruwan.linton > tweet: http://twitter.com/ruwanlinton > -- Charith Dhanushka Wickramarachchi http://charithwiki.blogspot.com/ --90e6ba539ed414022d048cc59c5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Aug 1, 2010 at 7:03 PM, Ruwan Li= nton <ruwan.= linton@gmail.com> wrote:
Charith,

I think the problem you have to solve is more broader :-) y= ou have to keep the complete state of the message, meaning what is its endp= oint, ow it reached this endpoint, for example if it is via a proxy foo, yo= u need to make sure that the response message after delivering it later get= s dispatched to the out sequence of the proxy, or if there are any other me= diators after the send (endpoint) you need to remember those to execute tha= t rest of the sequence after delivering the message and so forth.

So ideally what we should be doing is to keep a reference to the config= uration in its complete serialization format. So in effect you need to buil= d up a referencing mechanism to refer to any bit of the synapse configurati= on, that way we can support message persistence not only for messages sendi= ng out, but also for any mediation, in the future. :-)


Thanks for the feed back.
= =A0

=A0=A0 I'll come up with a design for this= soon. At a high level i feel like this can be=A0achieved=A0by keeping a JN= DI Context at the Synpase Environment and using a string based naming synta= x to uniquely lookup any point in the configuration. We can populate the Co= ntext while building the Synapse configuration model.

WDYT?

=A0
Thanks,
Ruwan


=
On Sun, Aug 1, 2010 at 6:43 PM, Charith Wickramarachchi &= lt;charith= .dhanushka@gmail.com> wrote:
Thanks for the reply.
On Sun, Aug 1, 2010 at 6:25 PM, Paul = Fremantle <pzfreo@gmail.com> wrote:
Why do you object to serializing the endpoint?
Seems like it would be
the right thing to do.

=A0=A0=A0=A0H= ere what i mean by serializing is serializing it to a ObjectMessage in JMS.= =A0
=A0
Can't it be serialized as a <wsa:to> address in
the message header?
=A0=A0=A0
=A0=A0If= i do that, in a re delivery=A0scenario will i be able to use the original = endpoint to re-deliver=A0the message ?. =A0=A0
=A0=A0 -- Charith = =A0

Paul

On Sun, Aug 1, 2010 at 7:24 AM, Charith Wickramarachchi
> Hi devs ,
> While working on the patch for the JMS Based Message store i got stuck= in
> the place where i need to persist the Message.
> Idea of=A0persisting=A0message=A0is to later it can be redelivered or= =A0views=A0later.
> So in the InMemory Message store case when storing i kept the=A0refere= nce=A0to
> the Message context (built) and its=A0associated=A0endpoint.
> Keeping a =A0reference=A0to the Endpoint in this case is not costly si= nce its
> just an Object=A0reference.
> But keeping the Endpoint =A0associated with a=A0Message Context=A0is > bit=A0problematic in a=A0persistent=A0scenario since there is no point=
> in=A0serializing=A0=A0the Endpoint :).
> I have 2 solutions to solve this.
>
> Make all the endpoints=A0globally=A0accessible=A0from the configuratio= n (Even
> the=A0anonymous=A0ones Ex : say a endpoint defined in a send mediator)= . so that
> i need only to keep the name of the endpoint with the Message.
> Support Message store feature only with the Endpoints defined=A0global= ly.
>
> WDYT ?
>
> --
> Charith Dhanushka Wickramarachchi
> http://= charithwiki.blogspot.com/
>
>



--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair

blog: http://pzf.fre= mantle.org
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

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




--
<= /div>
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/




-- Ruwan Linton
Software Architect & Product Manager, WSO2 ESB; http://wso2.org/esb
WSO2= Inc.; http://wso2.org
Lean . Enterprise . Middleware

phone: +1 408 754 7388 ext 51789<= br>email: ruwan@wso2.co= m; cell: +94 77 341 3097
blog: http://blog.ruwan.org
linkedin: http://www.linkedin.com/in/ruwanlinton
google: http://www.google.= com/profiles/ruwan.linton
tweet: http://= twitter.com/ruwanlinton



--
Charith Dhanushka Wickr= amarachchi
http://charithwi= ki.blogspot.com/

--90e6ba539ed414022d048cc59c5a--