I submited the Proposal in the Google OpenSource Program WebSite

Following are the links to Proposal in Google Space and Apache Wiki Space

 
http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/charith/t127030145826<http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/charith/t127030145826>

http://wiki.apache.org/general/charith/gsoc2010/synapse_deadLetter

thanks,
Charith

On Fri, Apr 2, 2010 at 2:28 PM, Charith Wickramarachchi <
[email protected]> wrote:

> I add the project proposal to the Apache Wiki 
> space.http://wiki.apache.org/general/charith/gsoc2010/synapse_deadLetter
>
>
> thanks,
> Charith
>
>
> On Fri, Apr 2, 2010 at 12:20 AM, Charith Wickramarachchi <
> [email protected]> wrote:
>
>>
>>
>> On Thu, Apr 1, 2010 at 10:50 AM, Hiranya Jayathilaka <
>> [email protected]> wrote:
>>
>>>
>>>
>>> On Sun, Mar 28, 2010 at 1:25 PM, Charith Wickramarachchi <
>>> [email protected]> wrote:
>>>
>>>> Thanks you for your feed back.
>>>>
>>>> I updated it with the changes you proposed.You can find the new document
>>>> here 
>>>> [1]<http://socghop.appspot.com/document/show/user/charith/deadletterchannel_apache_synapse>
>>>>
>>>
>>> Charith, formatting of the document seems to be messed up a little bit.
>>>
>>
>>    Yes. i 'm having a issue with google docs provided in the Summer of
>> code site.
>>  google
>>
>>> Please have a look. Also once you are done, shall we bring this into the
>>> Apache Wiki. I'd like to have everything related to this
>>>
>> project in the ASF space.
>>> Sure.I'll put new proposal in a Apache Wiki Space.
>>>
>>
>>    /charith
>>
>>
>>> Thanks,
>>> Hiranya
>>>
>>>
>>>>
>>>> thanks,
>>>> Charith
>>>>
>>>> [1
>>>> ]http://socghop.appspot.com/document/show/user/charith/deadletterchannel_apache_synapse
>>>>  
>>>> <http://socghop.appspot.com/document/show/user/charith/deadletterchannel_apache_synapse>
>>>>
>>>> On Sun, Mar 28, 2010 at 10:32 AM, Hiranya Jayathilaka <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi Charith,
>>>>>
>>>>> On Sat, Mar 27, 2010 at 2:35 PM, Charith Wickramarachchi
>>>>> <[email protected]> wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I wrote draft Proposal for the Project and its available at [1]
>>>>> > your feed backs on changes or improvements to the proposal is highly
>>>>> > appreciated.
>>>>>
>>>>> I had a quick look at the proposal. Pretty good stuff. I would also
>>>>> like to see a sample message store configuration in the document along
>>>>> with an endpoint configuration which uses the message store. Also I
>>>>> believe you can include the mediator development (currently listed
>>>>> under optional features) in the second development phase. I don't
>>>>> think writing a mediator takes that much time.
>>>>>
>>>>> Also please cite the source of your diagram ;)
>>>>>
>>>>> Thanks,
>>>>> Hiranya
>>>>>
>>>>> >
>>>>> > [1]
>>>>> http://socghop.appspot.com/document/show/user/charith/deadletterchannel_synapse
>>>>> >
>>>>> > On Wed, Mar 24, 2010 at 10:40 AM, Charith Wickramarachchi
>>>>> > <[email protected]> wrote:
>>>>> >>
>>>>> >> Thank you all  for your feedbacks.
>>>>> >>
>>>>> >> I'm currently looking at the Synapse Fault Handling Mechanism to
>>>>> Find a
>>>>> >> way to implement this.
>>>>> >> As far as i understand synapse uses a Stack base Fault handling
>>>>> Mechanism
>>>>> >> to achieve fault handling
>>>>> >> at the different Levels of  the Sequences and Endpoints in a correct
>>>>> >> order.
>>>>> >>
>>>>> >> I'm having some questions now.
>>>>> >>
>>>>> >> Implementing this with the Endpoint fault handling is clear to
>>>>> me.Where we
>>>>> >> can put the redelivery parameters/policies and Message Store at the
>>>>> end
>>>>> >> point so that at a failure it will considerer that parameters before
>>>>> >> executing the fault handler (so it will try to re deliver it
>>>>> according to
>>>>> >> the parameters /policy s specified and if failed it will store the
>>>>> Message
>>>>> >> ). As Amila said there we can use WS-RM policies.
>>>>> >>
>>>>> >> Do we need to impliment this with the Sequences too ?
>>>>> >>
>>>>> >> Then we need to have a machansim to find how to determine the
>>>>> sequnce name
>>>>> >> and at which level this message has failed from the stored Meta
>>>>> data  (Since
>>>>> >> same sequnces can be re used at deffrent levels).
>>>>> >>
>>>>> >> my next Question is about Stroing the Message?
>>>>> >>
>>>>> >> Since idea if storing the message is to  be able to re generate the
>>>>> same
>>>>> >> message again. Are we going to store the MessageContext object ?
>>>>> (And in a
>>>>> >> persistent storage case  we can use a Adapter and serialise that
>>>>> object.)Or
>>>>> >> is there a better memory effcient way?
>>>>> >>
>>>>> >> WDYT?
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Mon, Mar 22, 2010 at 10:57 AM, Amila Suriarachchi
>>>>> >> <[email protected]> wrote:
>>>>> >>>
>>>>> >>>
>>>>> >>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi
>>>>> >>> <[email protected]> wrote:
>>>>> >>>>
>>>>> >>>> Hi,
>>>>> >>>>
>>>>> >>>> Thanks for the reply and your feed back. I looked in to the Apache
>>>>> Camel
>>>>> >>>> DeadLetter channel features and its uses.
>>>>> >>>>  And also FUSE Mediation Router support this EIP too.[1].
>>>>> >>>>
>>>>> >>>> As per my current understanding Re delivery policies plays a major
>>>>> role
>>>>> >>>> when supporting this Pattern.Where users can configure the re
>>>>> delivery
>>>>> >>>> policy so that system will retry to deliver before message added
>>>>> to the
>>>>> >>>> Message store according to the policy defined.
>>>>> >>>
>>>>> >>> one option is to use ws-rm. which gives you a standard mechanism of
>>>>> >>> handling retransmissions.
>>>>> >>>
>>>>> >>> thanks,
>>>>> >>> Amila.
>>>>> >>>>
>>>>> >>>> And also i found that there is a requirement to make enable to
>>>>> execute a
>>>>> >>>> sequence after message is added to the message store(or just
>>>>> before adding
>>>>> >>>> to Message Store).
>>>>> >>>> So that it can be used to send notifications to the pre configured
>>>>> >>>> persons telling that Messages has been added to the Message
>>>>> store/Dead
>>>>> >>>> letter channel.
>>>>> >>>>
>>>>> >>>> I'm currently looking in to the Synapse code and architecture to
>>>>> figure
>>>>> >>>> out ways of implementing this.So your feed back is highly
>>>>> appreciated.
>>>>> >>>>
>>>>> >>>> As i understand synapse Currenty has a mechanism to plug custom
>>>>> >>>> configuration elements.
>>>>> >>>> ConfigurationFactoryAndSerializerFinder does that. So it looks
>>>>> like that
>>>>> >>>> the requirement Hiranya Mentioned about beging able to plug custom
>>>>> Message
>>>>> >>>> Stores easily can be archived using that Service provider
>>>>> machanishm.
>>>>> >>>>
>>>>> >>>> Your ideas on better ways of implimenting this feature is highly
>>>>> >>>> appriciated.
>>>>> >>>>
>>>>> >>>> thanks,
>>>>> >>>> /Charith
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> [1]
>>>>> http://fusesource.com/docs/router/1.6/eip/MsgCh-DeadLetter.html
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> On Thu, Mar 18, 2010 at 9:09 PM, Hiranya Jayathilaka
>>>>> >>>> <[email protected]> wrote:
>>>>> >>>>>
>>>>> >>>>> Hi Charith,
>>>>> >>>>>
>>>>> >>>>> There are actually several ways we can tackle this problem. And
>>>>> right
>>>>> >>>>> now even I'm not sure which approach is the best. We need to
>>>>> discuss
>>>>> >>>>> the options we got and then get to a suitable and feasible
>>>>> solution.
>>>>> >>>>>
>>>>> >>>>> One solution is to introduce a new top level component (as you
>>>>> have
>>>>> >>>>> suggested) for the message stores. The sequences already have the
>>>>> >>>>> onError attribute which can be used to specify a custom fault
>>>>> sequence
>>>>> >>>>> to be executed in case of an error. If a custom fault sequence is
>>>>> not
>>>>> >>>>> specified the default fault sequence will take over the control.
>>>>> Proxy
>>>>> >>>>> services also have the concept of fault sequences. So we need to
>>>>> >>>>> figure out how to link up this concept of fault sequences with
>>>>> the
>>>>> >>>>> message store top level element. One option would be to write a
>>>>> >>>>> mediator which can be placed in a fault sequence. The mediator
>>>>> will
>>>>> >>>>> take the faulty message and place it in a specified message
>>>>> store.
>>>>> >>>>>
>>>>> >>>>> On the other hand we can just have the mediator. The message
>>>>> store
>>>>> >>>>> concept can be built into the mediator itself so we don't need a
>>>>> new
>>>>> >>>>> top level element. This approach however has the disadvantage of
>>>>> not
>>>>> >>>>> being able to share and reuse a single message store instance
>>>>> across
>>>>> >>>>> the Synapse configuration.
>>>>> >>>>>
>>>>> >>>>> Another possible approach is to have the message store top level
>>>>> >>>>> element and then introduce an onError attribute to the endpoint
>>>>> top
>>>>> >>>>> level element. This is the approach suggested by Ruwan at [1].
>>>>> >>>>>
>>>>> >>>>> Please consider all these options when working on your proposal.
>>>>> Also
>>>>> >>>>> please take a look at some existing implementations of the dead
>>>>> letter
>>>>> >>>>> channel pattern. FYI Apache Camel supports this pattern.If we can
>>>>> >>>>> reuse some of the stuff done in Camel that would be fine too.
>>>>> >>>>> Personally though I prefer having our native implementation of
>>>>> the
>>>>> >>>>> dead letter channel pattern. And to be frank I does like the idea
>>>>> of
>>>>> >>>>> having the message store as a top level element in Synapse.
>>>>> >>>>>
>>>>> >>>>> I'm sure other members of the team also have a lot of ideas with
>>>>> >>>>> regard to this project. Let's give them sometime and see what
>>>>> they
>>>>> >>>>> think too :)
>>>>> >>>>>
>>>>> >>>>> Thanks,
>>>>> >>>>> Hiranya
>>>>> >>>>>
>>>>> >>>>> [1] - https://issues.apache.org/jira/browse/SYNAPSE-263
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> On Thu, Mar 18, 2010 at 12:36 PM, Charith Wickramarachchi
>>>>> >>>>> <[email protected]> wrote:
>>>>> >>>>> > Hi Hiranya,
>>>>> >>>>> >
>>>>> >>>>> > This I went through idea you mention in the proposal.
>>>>> >>>>> >
>>>>> >>>>> > This is the picture of the High level design in my mind after
>>>>> looking
>>>>> >>>>> > into
>>>>> >>>>> > it.
>>>>> >>>>> > The Message Store will be a high level  synapse configuration
>>>>> >>>>> > construct (at
>>>>> >>>>> > the sequence , endpoint ...  )level.
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> >>>>> > Ex
>>>>> >>>>> > <msg_store name ="foo"  class =
>>>>> >>>>> > "org.apache.synapse.core.JDBCMessageStore"
>>>>> >>>>> > .....>
>>>>> >>>>> >    Other message store specific details goes here ex :
>>>>> scheduling
>>>>> >>>>> > info ,
>>>>> >>>>> > user names , urls
>>>>> >>>>> > </msg_store>
>>>>> >>>>> >
>>>>> >>>>> > and sequences and the endpoints must be able to point to this
>>>>> store
>>>>> >>>>> > with a
>>>>> >>>>> > parameter like "on fault"
>>>>> >>>>> > and also there can be multiple message stores that can be
>>>>> reused.
>>>>> >>>>> >
>>>>> >>>>> > Is this the idea in your mind?
>>>>> >>>>> >
>>>>> >>>>> > WDYT? your feed back will be highly appreciated so that i can
>>>>> improve
>>>>> >>>>> > my
>>>>> >>>>> > proposal.
>>>>> >>>>> >
>>>>> >>>>> > thank,
>>>>> >>>>> > /Charith
>>>>> >>>>> >
>>>>> >>>>> > On Thu, Mar 18, 2010 at 12:03 PM, Charith Wickramarachchi
>>>>> >>>>> > <[email protected]> wrote:
>>>>> >>>>> >>
>>>>> >>>>> >> Hi,
>>>>> >>>>> >>
>>>>> >>>>> >> I m a Undergraduate Interested in this Project idea. I have
>>>>> worked
>>>>> >>>>> >> with
>>>>> >>>>> >> the synapse code base So i 'm glad to do this project as my
>>>>> GSoC
>>>>> >>>>> >> project.
>>>>> >>>>> >>
>>>>> >>>>> >> I'm now looking in to the ways of designing and implementing
>>>>> this.I
>>>>> >>>>> >> m
>>>>> >>>>> >> willing to have more design level ideas regarding this.
>>>>> >>>>> >>
>>>>> >>>>> >> I'll come up with a proposal for this soon.
>>>>> >>>>> >>
>>>>> >>>>> >> thanks,
>>>>> >>>>> >>
>>>>> >>>>> >> Charith
>>>>> >>>>> >>
>>>>> >>>>> >> On Wed, Mar 17, 2010 at 5:20 PM, Hiranya Jayathilaka (JIRA)
>>>>> >>>>> >> <[email protected]> wrote:
>>>>> >>>>> >>>
>>>>> >>>>> >>> [GSoC] Implement a Dead Letter Channel for Synapse
>>>>> >>>>> >>> --------------------------------------------------
>>>>> >>>>> >>>
>>>>> >>>>> >>>                 Key: SYNAPSE-618
>>>>> >>>>> >>>                 URL:
>>>>> >>>>> >>> https://issues.apache.org/jira/browse/SYNAPSE-618
>>>>> >>>>> >>>             Project: Synapse
>>>>> >>>>> >>>          Issue Type: New Feature
>>>>> >>>>> >>>          Components: Core, Endpoints
>>>>> >>>>> >>>            Reporter: Hiranya Jayathilaka
>>>>> >>>>> >>>             Fix For: FUTURE
>>>>> >>>>> >>>
>>>>> >>>>> >>>
>>>>> >>>>> >>> Currently when Synapse attempts to send a message and if it
>>>>> fails,
>>>>> >>>>> >>> following actions can be configured to deal with the error:
>>>>> >>>>> >>>
>>>>> >>>>> >>> * Execute a fault sequence and handle the failed request
>>>>> gracefully
>>>>> >>>>> >>> * Fail-over to a different endpoint
>>>>> >>>>> >>>
>>>>> >>>>> >>> In addition to these, Synapse ESB should support the "dead
>>>>> letter
>>>>> >>>>> >>> channel" enterprise integration pattern to deal with various
>>>>> errors
>>>>> >>>>> >>> that
>>>>> >>>>> >>> might occur during mediation or while sending. With the dead
>>>>> letter
>>>>> >>>>> >>> channel,
>>>>> >>>>> >>> the failed message will be put into a message store in the
>>>>> ESB.
>>>>> >>>>> >>> Later the
>>>>> >>>>> >>> ESB can retry to send the messages in the message store.
>>>>> >>>>> >>>
>>>>> >>>>> >>> We should be able to have multiple implementations of the
>>>>> actual
>>>>> >>>>> >>> message
>>>>> >>>>> >>> store and should be able to configure which store to use for
>>>>> a
>>>>> >>>>> >>> particular
>>>>> >>>>> >>> scenario. Users should be able to implement their own message
>>>>> >>>>> >>> stores and
>>>>> >>>>> >>> plug into the ESB easily. To start with we can have a simple
>>>>> >>>>> >>> in-memory
>>>>> >>>>> >>> message store and a persisting store based on JDBC or JMS.
>>>>> >>>>> >>>
>>>>> >>>>> >>> References:
>>>>> >>>>> >>> http://www.eaipatterns.com/DeadLetterChannel.html
>>>>> >>>>> >>> https://issues.apache.org/jira/browse/SYNAPSE-263
>>>>> >>>>> >>>
>>>>> >>>>> >>> Possible Mentors:
>>>>> >>>>> >>> Hiranya Jayathilaka
>>>>> >>>>> >>>
>>>>> >>>>> >>>
>>>>> >>>>> >>> --
>>>>> >>>>> >>> This message is automatically generated by JIRA.
>>>>> >>>>> >>> -
>>>>> >>>>> >>> You can reply to this email to add a comment to the issue
>>>>> online.
>>>>> >>>>> >>>
>>>>> >>>>> >>>
>>>>> >>>>> >>>
>>>>> >>>>> >>>
>>>>> ---------------------------------------------------------------------
>>>>> >>>>> >>> To unsubscribe, e-mail: [email protected]
>>>>> >>>>> >>> For additional commands, e-mail: [email protected]
>>>>> >>>>> >>>
>>>>> >>>>> >>
>>>>> >>>>> >>
>>>>> >>>>> >>
>>>>> >>>>> >> --
>>>>> >>>>> >> Charith Dhanushka Wickramarachchi
>>>>> >>>>> >> http://charithwiki.blogspot.com/
>>>>> >>>>> >>
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> >>>>> > --
>>>>> >>>>> > Charith Dhanushka Wickramarachchi
>>>>> >>>>> > http://charithwiki.blogspot.com/
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> --
>>>>> >>>>> Hiranya Jayathilaka
>>>>> >>>>> Software Engineer;
>>>>> >>>>> WSO2 Inc.;  http://wso2.org
>>>>> >>>>> E-mail: [email protected];  Mobile: +94 77 633 3491
>>>>> >>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>> >>>>>
>>>>> >>>>>
>>>>> ---------------------------------------------------------------------
>>>>> >>>>> To unsubscribe, e-mail: [email protected]
>>>>> >>>>> For additional commands, e-mail: [email protected]
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> --
>>>>> >>>> Charith Dhanushka Wickramarachchi
>>>>> >>>> http://charithwiki.blogspot.com/
>>>>> >>>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> --
>>>>> >>> Amila Suriarachchi
>>>>> >>> WSO2 Inc.
>>>>> >>> blog: http://amilachinthaka.blogspot.com/
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Charith Dhanushka Wickramarachchi
>>>>> >> http://charithwiki.blogspot.com/
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Charith Dhanushka Wickramarachchi
>>>>> > http://charithwiki.blogspot.com/
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Hiranya Jayathilaka
>>>>> Software Engineer;
>>>>> WSO2 Inc.;  http://wso2.org
>>>>> E-mail: [email protected];  Mobile: +94 77 633 3491
>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Charith Dhanushka Wickramarachchi
>>>> http://charithwiki.blogspot.com/
>>>>
>>>>
>>>
>>>
>>> --
>>> Hiranya Jayathilaka
>>> Software Engineer;
>>> WSO2 Inc.;  http://wso2.org
>>> E-mail: [email protected];  Mobile: +94 77 633 3491
>>> Blog: http://techfeast-hiranya.blogspot.com
>>>
>>
>>
>>
>> --
>> Charith Dhanushka Wickramarachchi
>> http://charithwiki.blogspot.com/
>>
>>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>


-- 
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/

Reply via email to