Documentation?
On Mon, Aug 5, 2013 at 10:08 AM, Kasun Indrasiri <[email protected]> wrote: > It seems we are done with most of the core features and we should try to > finish this off by this week. > > > On Fri, Aug 2, 2013 at 9:36 AM, Isuru Udana <[email protected]> wrote: > >> Hi, >> >> As planned earlier, we have completed most of the implementation (about >> 90%) by today. To be more specific following are the things we have >> completed so far. >> >> -MS/MP core functionality >> -New blocking sender which supports most of the endpoint functionality >> -Fixing the UIs accordingly >> -Fixing the deployers accordingly >> -Testing basic functionality of the new implementation (both UI and non >> UI stuff) >> >> We have to test the multiple consumer scenarios as well (one > store/multiple processors) > >> Following are the left items to be completed. >> >> -Finish the implementation of In memory Message-Store >> -Integrate Message processor with the new blocking sender >> -Fix few functions of JMX MBeans of Message-Processors >> -Fix the existing failing test cases >> >> Since the new blocking sender is implemented in a generic way (does not >> contain message-processor specific functionality), As a part of this >> effort, I am planning to integrate it with the Callout mediator as well. So >> that it will be a significant improvement for the Callout Mediator. >> >> +1. > >> Next week we are planing to continue with testing the functionality >> including the MB integration, REST support, security,etc. >> >> Thanks. >> >> On Mon, Jul 29, 2013 at 10:41 AM, Shafreen Anfar <[email protected]>wrote: >> >>> Hi, >>> >>> Since the existing implementation of MS/MP is quite un-maintainable, we >>> thought of revamping the existing implementation. >>> >>> Link[1] contains the rough component diagram of the existing MS/MP >>> implementation. According to this design most of the work is done by the >>> MessageStore class. It was implemented with basic queue operations and act >>> as a proxy to the actual message stores such as in-memory-maps and >>> JMS-Queues. However, this design didn't cope well with scenarios such as >>> reliable messaging. For example, we came across a lot of integration issues >>> while we were testing ESB-4.7.0 with WSO2-MB. >>> >>> Moreover, though message processors are implemented using Quartz, the >>> existing implementation hasn't utilized it's APIs to the full extent. >>> >>> In addition to that current implementation is implemented basically >>> focusing on SOAP messages. And In the current implementation none of the >>> endpoint functionality is supported (security, RM, etc.). Only the Address >>> endpoint type is supported. Endpoint types like Http Endpoint is not >>> supported. >>> >>> link[2] contains the rough component diagram of the new implementation >>> of MS/MP. New implementation is designed with a view of message producers >>> and message consumers. As this makes easier to implement the requirements >>> associated with store-and-forward concepts. According the new design >>> MessageStore class act as a Manager and provides consumers and producers as >>> required to message processors and mediators in contrast to providing >>> methods to do queue operations. Along with this design following are the >>> tasks we are planning to complete. >>> >>> - Re-implement JMS message-store and JMS message-processor interfaces >>> - Proper connection handling >>> - moving classes to synapse >>> - Utilize Quartz in a proper way >>> - Fixing UI issues >>> - Unit/Integration tests >>> - Supporting all types of messages (Anyway, >>> existing implementation already supports most of the message types) >>> - Improve RESTful integration >>> - Support endpoint functionality (Security, RM etc.) >>> - Support Address, Default, WSDL, Http endpoints >>> >>> We have broken-down the implementation into three parts. >>> >>> Implement Message Stores (Ishan) >>> Implement Message Processors (Shafreen) >>> Implement stuff related to sending messages out from the ESB (Isuru) >>> >>> We are planning to complete the core-implementation within this week. In >>> the following week, we are going to do a comprehensive test against the new >>> implementation. >>> >>> [1] >>> https://docs.google.com/a/wso2.com/drawings/d/1U8z_rWaI8tRw6i6iDHtX6S_g0_BxgLLC3HfIS6Iyd5E/edit?usp=sharing >>> >>> [2] >>> https://docs.google.com/a/wso2.com/drawings/d/1AYKL9T3bDqQxH8Ik4pbb0GDoznyQAiAPrIwVVZFzZHQ/edit?usp=sharing >>> >>> -- >>> Regards, >>> *Shafreen* >>> Software Engineer >>> WSO2 Inc >>> Mobile : 077-556-395-1 >>> >> >> >> >> -- >> *Isuru Udana* >> * >> * >> Senior * >> Software Engineer >> * >> WSO2 Inc.; http://wso2.com >> email: [email protected] cell: +94 77 3791887 >> blog: http://mytecheye.blogspot.com/ >> twitter: http://twitter.com/isudana >> > > > > -- > Kasun Indrasiri > Software Architect > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +94 71 536 4128 > Blog : http://kasunpanorama.blogspot.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
