Re: [Architecture] AS4 support in EI
uded in the other conformance profiles >>>> in[1], such as WS-Security, we are going to introduce AS4 support as a >>>> Connector implementation, so that we can include other required features >>>> which are described in the remaining two conformance profiles. >>>> >>>> [1] http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4- >>>> profile/v1.0/cs03/AS4-profile-v1.0-cs03.html >>>> >>>> Thanks, >>>> Manorama >>>> >>>> On Tue, Jul 4, 2017 at 2:04 PM, Manorama Perera >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Jun 28, 2017 at 4:49 PM, Manorama Perera >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> AS4 is a messaging standard which represents an open standard for >>>>>> exchanging of Business-to-business documents using Web services. >>>>>> >>>>>> *AS4 Messaging Model* >>>>>> >>>>>> AS4 messaging model defines the following entities. >>>>>> >>>>>> *Message Producer*: Business application which sends the message >>>>>> content to the sending Message Service Handler(MSH). >>>>>> >>>>>> *Sending Message Service Handler*: Packages the message content and >>>>>> sends to the intended receiving MSH. >>>>>> >>>>>> *Receiving Message Service Handler*: Receive the message from the >>>>>> sending MSH. >>>>>> >>>>>> *Message Consumer*: The business application which receives the >>>>>> message content from receiving MSH. >>>>>> >>>>>> *P-Mode Parameters*: Message sending and receiving operations are >>>>>> governed by P-Mode configuration. These are configured in sending and >>>>>> receiving MSHs. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The current implementation details of AS4 custom mediator[2] is as >>>>>> follows. >>>>>> >>>>>>- This is in conformance with AS4 Profile of ebMS 3.0 Version >>>>>>1.0[1]. >>>>>>- The current AS4 implementation only supports features as stated >>>>>>in the Access Point Implementation Guide (attached). >>>>>>- One-way / Push Message Exchange Patterns (MEPs) is supported. >>>>>>- Only the *required* P-Mode Parameters are supported (According >>>>>>to [1]). >>>>>> >>>>>> >>>>>> *Supported P-Mode Parameters* >>>>>> >>>>>> >>>>>> PMode Parameter >>>>>> >>>>>> Supported or not >>>>>> >>>>>> PMode.ID >>>>>> >>>>>> true >>>>>> >>>>>> PMode.Agreement >>>>>> >>>>>> true >>>>>> >>>>>> PMode.MEP >>>>>> >>>>>> true >>>>>> >>>>>> PMode.MEPbinding >>>>>> >>>>>> true >>>>>> >>>>>> PMode.Initiator.Party >>>>>> >>>>>> true >>>>>> >>>>>> PMode.Initiator.Role >>>>>> >>>>>> true >>>>>> >>>>>> PMode.Initiator.Authorization.username >>>>>> >>>>>> false >>>>>> >>>>>> PMode.Initiator.Authorization.password >>>>>> >>>>>> false >>>>>> >>>>>> PMode.Responder.Party >>>>>> >>>>>> true >>>>>> >>>>>> PMode.Responder.Role >>>>>> >>>>>> true >>>>>> >>>>>> PMode.Responder.Authorization.username >>>>>> >>>>>> false >>>>>> >>>>>> PMode.Responder.Authorization.password >>>>>> >>>>>> false >>>>>> >>>>>> PMode.Protocol.Address >>>>>> >>>>>> true >>>>>> >>>>>> PMode.Protocol.SOAPVersion >>>>>> >>>>>> true >>>>>> >>>>>> PMode.BusinessInfo.Service >>>>>> >>>>>> true >>>>>> >>>>>> PMode.BusinessInfo.Action >>>>>> >>>>>> true >>>>>> >>>>>> PMode.BusinessInfo.Properties[] >>>>>> >>>>>> false >>>>>> >>>>>> PMode.BusinessInfo.PayloadProfile[] >>>>>> >>>>>> false >>>>>> >>>>>> PMode.BusinessInfo.PayloadProfile.maxSize >>>>>> >>>>>> false >>>>>> >>>>>> PMode.ErrorHandling.Report.SenderErrorsTo >>>>>> >>>>>> false >>>>>> >>>>>> PMode.ErrorHandling.Report.ReceiverErrorsTo >>>>>> >>>>>> false >>>>>> >>>>>> PMode.ErrorHandling.Report.AsResponse >>>>>> >>>>>> true >>>>>> >>>>>> PMode.ErrorHandling.Report.ProcessErrorNotifyConsumer >>>>>> >>>>>> false >>>>>> >>>>>> PMode.ErrorHandling.Report.ProcessErrorNotifyProducer >>>>>> >>>>>> true >>>>>> >>>>>> PMode.ErrorHandling.Report.DeliveryFailuresNotifyProducer >>>>>> >>>>>> true >>>>>> >>>>>> PMode.Security.WSSVersion >>>>>> >>>>>> false >>>>>> >>>>>> PMode.Security.X509.Sign >>>>>> >>>>>> false >>>>>> >>>>>> PMode.Security. X509.Encryption >>>>>> >>>>>> false >>>>>> >>>>>> PMode.Security.UsernameToken >>>>>> >>>>>> false >>>>>> >>>>>> PMode.Security.PModeAuthorize >>>>>> >>>>>> false >>>>>> >>>>>> PMode.Security.SendReceipt >>>>>> >>>>>> true >>>>>> >>>>>> PMode.Security.SendReceipt.NonRepudiation >>>>>> >>>>>> false >>>>>> >>>>>> PMode.PayloadService.CompressionType >>>>>> >>>>>> true >>>>>> >>>>>> PMode.ReceptionAwareness >>>>>> >>>>>> true >>>>>> >>>>>> PMode.ReceptionAwareness.Retry.Parameters >>>>>> >>>>>> true >>>>>> >>>>>> AS4 support in EI, will be introduced as a separate transport. >>>>>> >>>>>> [1] http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/ >>>>>> AS4-profile/v1.0/os/AS4-profile-v1.0-os.html >>>>>> [2] https://github.com/manoramahp/org.wso2.carbon.mediator.as4 >>>>>> >>>>>> Thanks, >>>>>> Manorama >>>>>> -- >>>>>> Manorama Perera >>>>>> Software Engineer >>>>>> WSO2, Inc.; http://wso2.com/ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Manorama Perera >>>>> Software Engineer >>>>> WSO2, Inc.; http://wso2.com/ >>>>> >>>> >>>> >>>> >>>> -- >>>> Manorama Perera >>>> Software Engineer >>>> WSO2, Inc.; http://wso2.com/ >>>> >>> >>> >>> >>> -- >>> Manorama Perera >>> Software Engineer >>> WSO2, Inc.; http://wso2.com/ >>> >> >> >> >> -- >> >> Best Regards, >> >> Malaka Silva >> Associate Director / Architect >> M: +94 777 219 791 <+94%2077%20721%209791> >> Tel : 94 11 214 5345 >> Fax :94 11 2145300 >> Skype : malaka.sampath.silva >> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >> Blog : http://mrmalakasilva.blogspot.com/ >> >> WSO2, Inc. >> lean . enterprise . middleware >> https://wso2.com/signature >> http://www.wso2.com/about/team/malaka-silva/ >> <http://wso2.com/about/team/malaka-silva/> >> https://store.wso2.com/store/ >> >> Don't make Trees rare, we should keep them with care >> > > > > -- > Manorama Perera > Software Engineer > WSO2, Inc.; http://wso2.com/ > -- Kasun Indrasiri Director - Integration Architecture WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +1 650 450 2293 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic
sting gateway artifacts and restart the >>>> gateway container, then we need to fetch all the APIs from the core. IMHO >>>> it would better to persist data and load that data at restart as it would >>>> take time to fetch all the APIs from the core. >>>> >>>> Thank you! >>>> -- >>>> *Pubudu Gunatilaka* >>>> Committer and PMC Member - Apache Stratos >>>> Software Engineer >>>> WSO2, Inc.: http://wso2.com >>>> mobile : +94774078049 <%2B94772207163> >>>> >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 <+94%2071%20306%208779> >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Manoj Gunawardena >> Tech Lead >> WSO2, Inc.: http://wso2.com >> lean.enterprise.middleware >> Mobile : +94 77 2291643 >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thilini Shanika > Senior Software Engineer > WSO2, Inc.; http://wso2.com > 20, Palmgrove Avenue, Colombo 3 > > E-mail: tgtshan...@gmail.com > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Director - Integration Architecture WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +1 650 450 2293 <(650)%20450-2293> Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB connector auto generation tool
Hi Malaka,
We did a PoC project on generating a connector based on a given Swagger
definition. Is this a similar requirement?
On Tue, Sep 20, 2016 at 10:51 AM, Ajanthan Balachandran
wrote:
> What do you mean by a tool? Is it command line tool or maven plugin or
> eclipse plugin?
>
> On Fri, Sep 9, 2016 at 2:07 AM, Rajjaz Mohammed wrote:
>
>>
>> Hi,
>>>
>>> We have currently 150+ connectors in store
>>> <https://store.wso2.com/store/>. Using those we can easily build
>>> integration use cases with WSO2 ESB.
>>>
>>> However there are some apis that resides on premises and specific to
>>> some users. If we need to integrate such services, we either need to
>>> manually do the integration with ESB or develop a connector and use it.
>>>
>>> The idea of this project is to automate the development of connectors
>>> that makes the integration tasks more productive.
>>>
>>> So we are planning to start this with soap based connectors and move to
>>> rest based support later.
>>>
>>> For soap based connector generation we basically need to parse the wsdl
>>> and generate a connector operation per soap operation.
>>>
>>> For that we can use WSDL4J. Using this we can get the required
>>> operations and request/response messages required. Using this information
>>> we can build the connector operations.(Sequence Templates)
>>>
>>> eg:
>>> String wsdlPath = "/home/wso2/Desktop/ConnectorTest.wsdl";
>>> WSDLReader reader = javax.wsdl.factory.WSDLFactory
>>> .newInstance().newWSDLReader();
>>> javax.wsdl.Definition defn = reader.readWSDL(wsdlPath);
>>>
>>> Map tmp = defn.getAllServices();
>>>
>>> for(javax.xml.namespace.QName key:tmp.keySet()){
>>> ServiceImpl serviceImpl = tmp.get(key);
>>> Map mPorts = serviceImpl.getPorts();
>>> for(String k1:mPorts.keySet()){
>>> PortImpl portImpl = mPorts.get(k1);
>>> List bindingOperations =
>>> portImpl.getBinding().getBindingOperations();
>>> for(BindingOperationImpl bindingOperation:bindingOperations){
>>> System.out.println("operation:" + bindingOperation.getName());
>>> BindingInput bindingInput = bindingOperation.getBindingInput();
>>> }
>>> }
>>> }
>>> Map messages = defn.getMessages();
>>> Iterator msgIterator = messages.values().iterator();
>>> while (msgIterator.hasNext()){
>>> Message msg = (Message)msgIterator.next();
>>> if (!msg.isUndefined()) {
>>> System.out.println(msg.getQName());
>>> }
>>> }
>>> Thoughts?
>>>
>>>
>> Hi All,
>>
>> I have the plan to implement ESB connector auto-generation tool. Plase
>> add if anything more to above explanation about the tool.
>>
>> Best Regards,
>>>
>>> Malaka Silva
>>> Senior Technical Lead
>>> M: +94 777 219 791
>>> Tel : 94 11 214 5345
>>> Fax :94 11 2145300
>>> Skype : malaka.sampath.silva
>>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
>>> Blog : http://mrmalakasilva.blogspot.com/
>>>
>>> WSO2, Inc.
>>> lean . enterprise . middleware
>>> https://wso2.com/signature
>>> http://www.wso2.com/about/team/malaka-silva/
>>> <http://wso2.com/about/team/malaka-silva/>
>>> https://store.wso2.com/store/
>>>
>>> Don't make Trees rare, we should keep them with care
>>>
>>
>>
>>
>> --
>> Thank you
>> Best Regards
>>
>> *Rajjaz HM*
>> Associate Software Engineer
>> Platform Extension Team
>> WSO2 Inc. <http://wso2.com/>
>> lean | enterprise | middleware
>> Mobile | +94752833834|+94777226874
>> Email | raj...@wso2.com
>> LinkedIn <https://lk.linkedin.com/in/hmohammedrajjaz> | Blogger
>> <http://rajjazhm.blogspot.com/> | WSO2 Profile
>> <http://wso2.com/about/team/mohammer-rajjaz/>
>> [image: https://wso2.com/signature] <https://wso2.com/signature>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> Ajanthan
> Software Engineer;
> WSO2, Inc.; http://wso2.com/
>
> email: ajanthan <http://goog_595075977>@wso2.com; cell: +1 425 919 8630
> blog: http://bkayts.blogspot.com/
>
> Lean . Enterprise . Middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Kasun Indrasiri
Director, Integration Technologies
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware
cell: +1 650 450 2293
Blog : http://kasunpanorama.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Endpoint Separation From Gateway
>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>>> Bhathiya >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> sanjeewa. >>>>>>>>>>>> >>>>>>>>>>>>> [1] - http://wso2.com/library/arti >>>>>>>>>>>>>> cles/2016/03/article-architecting-a-multi-environment-api-ma >>>>>>>>>>>>>> nager-deployment-with-wso2-api-manager/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Harsha >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Harsha Kumara >>>>>>>>>>>>>> Software Engineer, WSO2 Inc. >>>>>>>>>>>>>> Mobile: +94775505618 >>>>>>>>>>>>>> Blog:harshcreationz.blogspot.com >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>>> Mobile : +94713068779 >>>>>>>>>>>>> >>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>> Mobile : +94713068779 >>>>>>>>>>>> >>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Harsha Kumara >>>>>>>>>>> Software Engineer, WSO2 Inc. >>>>>>>>>>> Mobile: +94775505618 >>>>>>>>>>> Blog:harshcreationz.blogspot.com >>>>>>>>>>> >>>>>>>>>>> ___ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> Architecture@wso2.org >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Bhathiya Jayasekara* >>>>>>>>>> *Senior Software Engineer,* >>>>>>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>>>>>>>> >>>>>>>>>> *Phone: +94715478185 <%2B94715478185>* >>>>>>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>>>>>>>> <http://www.linkedin.com/in/bhathiyaj>* >>>>>>>>>> *Twitter: https://twitter.com/bhathiyax >>>>>>>>>> <https://twitter.com/bhathiyax>* >>>>>>>>>> *Blog: http://movingaheadblog.blogspot.com >>>>>>>>>> <http://movingaheadblog.blogspot.com/>* >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Harsha Kumara >>>>>>>>> Software Engineer, WSO2 Inc. >>>>>>>>> Mobile: +94775505618 >>>>>>>>> Blog:harshcreationz.blogspot.com >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Sanjeewa Malalgoda* >>>>>>>> WSO2 Inc. >>>>>>>> Mobile : +94713068779 >>>>>>>> >>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Bhathiya Jayasekara* >>>>>>> *Senior Software Engineer,* >>>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>>>>> >>>>>>> *Phone: +94715478185 <%2B94715478185>* >>>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>>>>> <http://www.linkedin.com/in/bhathiyaj>* >>>>>>> *Twitter: https://twitter.com/bhathiyax >>>>>>> <https://twitter.com/bhathiyax>* >>>>>>> *Blog: http://movingaheadblog.blogspot.com >>>>>>> <http://movingaheadblog.blogspot.com/>* >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Sanjeewa Malalgoda* >>>>>> WSO2 Inc. >>>>>> Mobile : +94713068779 >>>>>> >>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Bhathiya Jayasekara* >>>>> *Senior Software Engineer,* >>>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>>> >>>>> *Phone: +94715478185 <%2B94715478185>* >>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>>> <http://www.linkedin.com/in/bhathiyaj>* >>>>> *Twitter: https://twitter.com/bhathiyax >>>>> <https://twitter.com/bhathiyax>* >>>>> *Blog: http://movingaheadblog.blogspot.com >>>>> <http://movingaheadblog.blogspot.com/>* >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *Sanjeewa Malalgoda* >>>> WSO2 Inc. >>>> Mobile : +94713068779 >>>> >>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>> :http://sanjeewamalalgoda.blogspot.com/ >>>> <http://sanjeewamalalgoda.blogspot.com/> >>>> >>>> >>>> >>> >>> >>> -- >>> *Bhathiya Jayasekara* >>> *Senior Software Engineer,* >>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>> >>> *Phone: +94715478185 <%2B94715478185>* >>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>> <http://www.linkedin.com/in/bhathiyaj>* >>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >>> *Blog: http://movingaheadblog.blogspot.com >>> <http://movingaheadblog.blogspot.com/>* >>> >> >> >> >> -- >> >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/ >> <http://sanjeewamalalgoda.blogspot.com/> >> >> >> > > > -- > Harsha Kumara > Software Engineer, WSO2 Inc. > Mobile: +94775505618 > Blog:harshcreationz.blogspot.com > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Director, Integration Technologies WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +1 650 450 2293 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] RDBMS based coordinator election algorithm for MB
;>>>>>>>>>> the network >>>>>>>>>>>>>>>> connection to DB fails then this will be a single point of >>>>>>>>>>>>>>>> failure. I don't >>>>>>>>>>>>>>>> think we can scale RDBMS instances and expect the election >>>>>>>>>>>>>>>> algorithm to >>>>>>>>>>>>>>>> work. That would be reducing this problem to another problem >>>>>>>>>>>>>>>> (electing >>>>>>>>>>>>>>>> coordinator RDBMS instance). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> IMHO it would be better to look at Zookeeper Atomic >>>>>>>>>>>>>>>> Broadcast (ZAB) [1] or RAFT leader election [2] algorithms >>>>>>>>>>>>>>>> which have >>>>>>>>>>>>>>>> already proven results. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] https://cwiki.apache.org/c >>>>>>>>>>>>>>>> onfluence/display/ZOOKEEPER/Zab1.0 >>>>>>>>>>>>>>>> [2] http://libraft.io/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, Jul 28, 2016 at 1:42 PM, Nandika Jayawardana < >>>>>>>>>>>>>>>> nand...@wso2.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> +1 to make it a common component . We have the clustering >>>>>>>>>>>>>>>>> implementation for BPEL component based on hazelcast. If the >>>>>>>>>>>>>>>>> coordination >>>>>>>>>>>>>>>>> is available at RDBMS level, we can remove hazelcast >>>>>>>>>>>>>>>>> dependancy. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>> Nandika >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Jul 28, 2016 at 1:28 PM, Hasitha Aravinda < >>>>>>>>>>>>>>>>> hasi...@wso2.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Can we make it a common component, which is not hard >>>>>>>>>>>>
Re: [Architecture] A JavaScript based Tooling Platform for WSO2 Middleware
Hi Harshana, The tooling platform that we have proposed above is for our next generation products. We will continue to work on existing developer studio tooling and keep on improving them. For instance, ESB 5 tooling that is based on dev-studio contains major feature enhancements such as Data Mapper, mediation debugger etc. So, we will continue to support/enhance it. On Mon, Jul 25, 2016 at 2:23 PM, Harshana Eranga Martin < harshan...@gmail.com> wrote: > Hi Imesh, > > A huge -1 for this idea. > > This is going to introduce the same issue we had before with Tooling > splitting between Dev Studio and Browser providing different > features, going out of sync at some point and different development > guidelines. > > It took years to get out of that mess and to get the focus on tooling to > build a unified tooling experience for the platform. > > If there are gaps in the Dev Studio based tooling the correct approach > would be to allocate people and time required to fix the gap. Train people > to expedite the development process. Taking shirtcut and introducing > another tooling playform is not the way to go. It introduce further > confusion for the customers to choose which is the correct tooling and what > should be the accepted development process. This is the same issue we had > before and you are trying to go back to the same mess again with this > alternative tooling idea. > > So absolutely -1 for anything to suggest to take the focus away from > unified tooling experience on one platform taking place right now. > > Thanks and Regards, > Harshana > > On Friday, 22 July 2016, Imesh Gunaratne wrote: > >> Hi All, >> >> According to an internal discussion we had, we thought of introducing >> $subject for improving the overall tooling experience of WSO2 middleware. >> The main goal of this effort is to build a lightweight, cross-platform, >> attractive, user-oriented tooling platform with reusable visualization >> components. >> >> This has several sub goals: >> >>- Implementing reusable tooling components which can be used for >>building an unified IDE: >> - This would be similar to WSO2 Carbon architecture and analytics >> platform where we implement reusable components and build products by >> aggregating them. >>- Reusing visualization components in web based UIs >>- Making the tooling platform available on the web/cloud >> >> To achieve this, we thought of implementing tooling components in HTML5, >> CSS and JavaScript. This would allow us to make the tooling platform; >> platform independent, reusable and web enabled. >> >> >> *WSO2 JS Tooling Platform High Level Architecture* >> >> [image: Inline image 1] >> On high level, the WSO2 JS tooling platform would have above components. >> Out of these we would first start with the visualization component and try >> to come up with a JS library which can provide features needed for >> implementing product specific tooling components. >> >> >> *WSO2 JS Tooling Platform Component Architecture* >> [image: Inline image 3] >> >> According to the above concept, we would use existing JS frameworks such >> as D3.js, Backbone and Lodash for implementing the core tooling framework. >> In this model, D3.js will be used for utilizing basic features needed for >> drawing shapes, Backbone will be used for implementing JavaScript >> extendibility features (only using Model and View from its MVC >> architecture) and finally Lodash will be used for utilizing utility >> functions. >> >> On top of the core tooling framework a collection of tooling components >> will be implemented according to WSO2 product requirements. Initially we >> will be starting with the NextGen ESB (Integration Server) by implementing >> a sequence diagramming and data mapper modules. >> >> The initial source code of this effort can be found in WSO2 Incubator >> [1]. Please feel free to try this out and share your thoughts. >> >> [1] >> https://github.com/wso2-incubator/js-tooling-framework >> >> Thanks >> >> -- >> *Imesh Gunaratne* >> Software Architect >> WSO2 Inc: http://wso2.com >> T: +94 11 214 5345 M: +94 77 374 2057 >> W: https://medium.com/@imesh TW: @imesh >> lean. enterprise. middleware >> >> > > -- > Sent from Gmail Mobile for IPhone > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Director, Integration Technologies WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +1 650 450 2293 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10
Shall we finalize the things that are going to deprecate in ESB 5? ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [ESB] Can we get rid of the usage of get-property function?
We also need to add system scope. >>>> >>>> Are we talking about removing get-property function or just implement >>>> what ever we can do with get-property() to do with context variables and >>>> recommending to use variables. I believe we are doing the latter. >>>> Completely removing it is not an option due to migration issues, need to do >>>> massive changes in samples, articles, blogs, documentation. >>>> >>>> And also regarding the unnecessary registry access, I think we should >>>> check again whether we can fix it. I will check the possibility doing that. >>>> >>>> Thanks. >>>> >>>> On Thu, Jun 2, 2016 at 5:27 AM, Nadeeshaan Gunasinghe < >>>> nadeesh...@wso2.com> wrote: >>>> >>>>> Hi Kasun, >>>>> >>>>> Will go through the aforementioned fact. >>>>> >>>>> Thanks, >>>>> >>>>> *Nadeeshaan Gunasinghe* >>>>> Software Engineer, WSO2 Inc. http://wso2.com >>>>> +94770596754 | nadeesh...@wso2.com | Skype: nadeeshaan.gunasinghe >>>>> <#m_3233678506527721877_m_-7945033807554017813_m_6820348976097291375_m_4205543007657424697_m_-6918896767413548059_> >>>>> <http://www.facebook.com/nadeeshaan.gunasinghe> >>>>> <http://lk.linkedin.com/in/nadeeshaan> >>>>> <http://twitter.com/Nadeeshaan> <http://nadeeshaan.blogspot.com/> >>>>> Get a signature like this: Click here! >>>>> <http://ws-promos.appspot.com/r?rdata=eyJydXJsIjogImh0dHA6Ly93d3cud2lzZXN0YW1wLmNvbS9lbWFpbC1pbnN0YWxsP3dzX25jaWQ9NjcyMjk0MDA4JnV0bV9zb3VyY2U9ZXh0ZW5zaW9uJnV0bV9tZWRpdW09ZW1haWwmdXRtX2NhbXBhaWduPXByb21vXzU3MzI1Njg1NDg3Njk3OTIiLCAiZSI6ICI1NzMyNTY4NTQ4NzY5NzkyIn0=&u=789400881267119> >>>>> >>>>> On Wed, Jun 1, 2016 at 3:08 PM, Kasun Indrasiri >>>>> wrote: >>>>> >>>>>> We need to add this to ESB 5. (We just came across another perf issue >>>>>> due to the redundant use of get-property) >>>>>> >>>>>> @Nadeeshan : Can you please check the limitations on adding this to >>>>>> other scopes such as operations/registry? >>>>>> >>>>>> On Wed, Jun 17, 2015 at 7:49 PM, Chanaka Fernando >>>>>> wrote: >>>>>> >>>>>>> Also some customers use the "operation" scope to store and retrieve >>>>>>> values within the mediation flow. Better if we can add "$operation" >>>>>>> also. >>>>>>> >>>>>>> On Thu, Jun 18, 2015 at 1:44 AM, Isabelle Mauny >>>>>>> wrote: >>>>>>> >>>>>>>> Totally +1 to that suggestion.. backward compatibility is key .. >>>>>>>> >>>>>>>> >>>>>>>> - >>>>>>>> *Isabelle Mauny* >>>>>>>> VP, Product Management - WSO2, Inc. - http://wso2.com/ >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jun 17, 2015 at 3:17 PM, Colin Roy-Ehri >>>>>>>> wrote: >>>>>>>> >>>>>>>>> +1 >>>>>>>>> It would be great to simplify the options available for property >>>>>>>>> lookup. I think this would increase the usability of our product. I >>>>>>>>> am >>>>>>>>> also concerned about customers migrating their existing xml code. >>>>>>>>> >>>>>>>>> In order to gain performance by moving away from get-property, >>>>>>>>> would customers need to revise all their use of these mediators? I >>>>>>>>> support >>>>>>>>> deprecating the get-property from the UI wizard and Dev Studio, but it >>>>>>>>> would also be great to revise the get-property implementation for >>>>>>>>> future >>>>>>>>> versions. In other words, would it be possible to change the >>>>>>>>> get-property >>>>>>>>> implementation so that proxies, APIs and sequences could be migrated >>
Re: [Architecture] [ESB] [DataMapper] Adding new functionalities to the Data Mapper
Can we do concat up to 'n' number of params? On Sun, Jun 12, 2016 at 11:35 PM, Eranda Rajapakshe wrote: > Hi, > > We are going to add following operations to the data mapper. These updates > will be added to the Data Mapper Graphical Editor inside ESB tooling. > > Boolean: > >- AND (Boolean, Boolean) : Boolean >- OR (Boolean, Boolean) : Boolean >- NOT (Boolean) : Boolean > > Conditional: > >- If Else > > String > >- String Length (String) : Number >- Starts with (String, String) : Boolean >- Ends with (String, String) : Boolean >- Substring (String, Number, Number) : String > > > Following operations are already included, > > Common > >- Constant > > Arithmetic > >- Add (Number, Number) : Number >- Subtract (Number, Number) : Number >- Multiply (Number, Number) : Number >- Divide (Number, Number) : Number >- Ceiling (Number) : Number >- Floor (Number) : Number >- Round (Number) : Number >- Set Precision (Number, Number) : Number >- Absolute Value (Number) : Number > > String > >- Concat (String, String, String) : String >- Contains (String) : String >- Split (String) : String[] >- LowerCase (String) : String >- UpperCase(String) : String > > > You can refer [1] for more information and we have mentioned other > possible functionalities that can be included as well in the document. > Please update the document for further requirements. > > [1]. > https://docs.google.com/a/wso2.com/spreadsheets/d/1uDLkH-_Ce2YJUSL6QoP_i_PU7jzMBJzF2mCrhSo8q-A/edit?usp=sharing > > Thanks, > > -- > *Eranda Rajapakshe* > Software Engineer > WSO2 Inc. > Mobile : +94784822608 > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [ESB] Can we get rid of the usage of get-property function?
We need to add this to ESB 5. (We just came across another perf issue due to the redundant use of get-property) @Nadeeshan : Can you please check the limitations on adding this to other scopes such as operations/registry? On Wed, Jun 17, 2015 at 7:49 PM, Chanaka Fernando wrote: > Also some customers use the "operation" scope to store and retrieve values > within the mediation flow. Better if we can add "$operation" also. > > On Thu, Jun 18, 2015 at 1:44 AM, Isabelle Mauny wrote: > >> Totally +1 to that suggestion.. backward compatibility is key .. >> >> >> - >> *Isabelle Mauny* >> VP, Product Management - WSO2, Inc. - http://wso2.com/ >> >> >> On Wed, Jun 17, 2015 at 3:17 PM, Colin Roy-Ehri wrote: >> >>> +1 >>> It would be great to simplify the options available for property >>> lookup. I think this would increase the usability of our product. I am >>> also concerned about customers migrating their existing xml code. >>> >>> In order to gain performance by moving away from get-property, would >>> customers need to revise all their use of these mediators? I support >>> deprecating the get-property from the UI wizard and Dev Studio, but it >>> would also be great to revise the get-property implementation for future >>> versions. In other words, would it be possible to change the get-property >>> implementation so that proxies, APIs and sequences could be migrated >>> forward without change, and still use the more efficient scoped-style >>> efficient implementation? This would prevent the registry performance hit, >>> and prevent the necessity for customers to modify all their xml code. >>> >>> >>> >>> Thanks, >>> Colin Roy-Ehri >>> Software Engineer >>> *WSO2, Inc. : wso2.com <http://wso2.com/>* >>> *Mobile* : 812-219-6517 >>> >>> On Wed, Jun 17, 2015 at 2:41 AM, Kasun Indrasiri wrote: >>> >>>> Hi, >>>> >>>> It seems we can get rid of the usage of get-property and stick to the >>>> usage of scope variable declarations only (the current impl of get-property >>>> function always triggers a call to ESB registry interface, which can be a >>>> performance hit). >>>> >>>> For example we can use: >>>> >>>> $ctx, $trp etc to get required property values from the context. >>>> @Nadeeshan : we need to include $registry: as well. >>>> >>>> Any other use cases that we need to cover? >>>> >>>> -- >>>> Kasun Indrasiri >>>> Software Architect >>>> WSO2, Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> cell: +94 77 556 5206 >>>> Blog : http://kasunpanorama.blogspot.com/ >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > -- > Chanaka Fernando > Senior Technical Lead > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 773337238 > Blog : http://soatutorials.blogspot.com > LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 > Twitter:https://twitter.com/chanakaudaya > Wordpress:http://chanakaudaya.wordpress.com > > > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Introducing Secure-Vault support to C5
keystore.identity.store.password: identity.store.password >>>>> >>>>> The CipherTool will be used for creating encrypted values for given >>>>> plain text secrets in the *secrets**.properties* [1]. >>>>> >>>>> If a user need to make a value secure, >>>>> >>>>>1. they have to add a unique name (alias) to their carbon >>>>>configuration element (eg: a value of an element in carbon.yml) >>>>>2. add the same unique-name along with the plain-text password to >>>>>the *secrets.properties* file. >>>>> >>>>> *Example:* >>>>> >>>>> Assume that we need to secure a value "password" under element >>>>> "Security/Keystore" in Carbon.yml configuration. First we add a unique a >>>>> alias as the value to the Password as below [3]. Second we add that unique >>>>> alias with its plain text password to *secrets*.properties file[4]. >>>>> >>>>> CipherTool will encrypt the plain-text password and replace the >>>>> plain-text password with the encrypted value. (In c4 we have added >>>>> plain-text passwords within square brackets. If not they are identified as >>>>> encrypted values). >>>>> >>>>> When loading the carbon.yml (or any other custom configuration file), >>>>> we read the secured values using secure-vault service. This secure vault >>>>> service will either return the password from the *secrets*.properties >>>>> file if the secret is not encrypted, OR return the encrypted value. >>>>> >>>>> [3] >>>>> >>>>> >>>>>id: carbon-kernel #Value to uniquely identify a server >>>>>name: WSO2 Carbon Kernel#Server Name >>>>>version: 5.1.0-SNAPSHOT #Server Version >>>>>tenant: default #Tenant Name >>>>> >>>>># Keystore used by this server >>>>>Security: >>>>> Keystore >>>>> Password: Carbon.Security.Keystore.Password >>>>> >>>>> >>>>> ### >>>>> >>>>> [4] Carbon.Security.Keystore.Password=[wso2carbon] >>>>> >>>>> >>>>> *New design decisions taken compared to C4 SecureVault implementation:* >>>>> >>>>>1. We have removed the usage of cipher-tool.properties file. (This >>>>>file was used to keep the alias, the location to the configuration >>>>> file, >>>>>and the xpath to the secret element in the configuration file). >>>>>2. We can support any format of configuration file with this model >>>>>as we only care about the secret-key that we define in the >>>>>*secrets*.properties file and do not depend on the xpath to find >>>>>the location of the secret element. >>>>> >>>>> Thanks, >>>>> Nipuni >>>>> >>>>> -- >>>>> Nipuni Perera >>>>> Software Engineer; WSO2 Inc.; http://wso2.com >>>>> Email: nip...@wso2.com >>>>> Git hub profile: https://github.com/nipuni >>>>> Blog : http://nipunipererablog.blogspot.com/ >>>>> Mobile: +94 (71) 5626680 >>>>> <http://wso2.com> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Sameera Jayasoma, >>>> Software Architect, >>>> >>>> WSO2, Inc. (http://wso2.com) >>>> email: same...@wso2.com >>>> blog: http://blog.sameera.org >>>> twitter: https://twitter.com/sameerajayasoma >>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>>> Mobile: 0094776364456 >>>> >>>> Lean . Enterprise . Middleware >>>> >>>> >>> >>> Regards, >>> Nira >>> -- >>> >>> *Niranjan Karunanandham* >>> Senior Software Engineer - WSO2 Inc. >>> WSO2 Inc.: http://www.wso2.com >>> >> >> >> >> -- >> With regards, >> *Manu*ranga Perera. >> >> phone : 071 7 70 20 50 >> mail : m...@wso2.com >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > Srinath Perera, Ph.D. >http://people.apache.org/~hemapani/ >http://srinathsview.blogspot.com/ > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Improving error handling at different layers in ESB
For most of E3 type errors (such as timeout, connection closing etc.) we do invoke fault sequence (if not specified default fault sequence) of the associated mediation logic. However, the current design doesn't not guarantee that all possible errors are handled in that way. That's why we need a generic fault handling logic in the transport layer, so that we propagate all errors. On Mon, May 16, 2016 at 11:19 PM, Srinath Perera wrote: > > > On Tue, May 17, 2016 at 11:28 AM, Isuru Udana wrote: > >> Hi Srinath, >> >> On Tue, May 17, 2016 at 11:13 AM, Srinath Perera >> wrote: >> >>> Kasun, what is the answer? >>> >>> Problem is that client does not know when the result will come back. >>> >>> >>>1. If client call start only a one sequence, and it has failed, then >>>we can stop the client connection. >>>2. If client call has started multiple sequences, error handler >>>should decide what to do. We should provide killCurrentCall() kind of a >>>sequence to let error handler tell engine to cleanup. >>>3. If all fails, then timeout will handle that. >>> >>> WDYT? >>> >> I am not sure whether I got your idea correctly. >> IMO, irrespective of number of sequences in the message flow, we should >> invoke the fault handler for all errors occurring at different layers and >> at the fault handler we need to allow user to decide what's need to be >> done. >> > > Two concerns in this case > > 1. In default case, where no error handler has been defined, scenario > should work and print correct errors. > Yes, it invokes the default fault handler. The problem is that if the default fault handler just logs the errors does not respond client, the client waits and holds the connection to ESB. We can easily fix this by changing the default fault handler logic. 2. When, multiple threads or sequences has been started, we need to provide > helper fucntion to stop cleanup other thread if user need to handle it. > > Yeah, this make sense when we have complex mediation logic that involves multiple threads (such as iterate,clone etc.) > I am trying to address above two. > > > >> Currently for all the errors happens at the mediation layer, fault >> sequence is getting executed. >> But there can be situations where fault handler is not executed for >> errors happens at the lower layers at the transport sender side. That is >> the problem we need to test and address carefully. >> > Can we give java level callback for this case? > Yeah, I think we can use a generic callback object and use that across the transport layer to invoke when any error happens. > > >> >> Thanks. >> >> >>> >>> --Srinath >>> >>> On Tue, May 17, 2016 at 10:33 AM, Artur Reaboi >>> wrote: >>> >>>> +1 >>>> >>>> >>>> >>>> Are there any workarounds recommended for E3 type of errors on current >>>> WSO2 ESB 4.9.0? >>>> >>>> >>>> >>>> Best regards, >>>> >>>> *Artur Reaboi* >>>> *Enterprise Architect | e-Government Center* >>>> >>>> Tel +373 22 250 487 |Mob +373 79 440 064 |Skype reaboi.artur >>>> >>>> >>>> >>>> *From:* Architecture [mailto:architecture-boun...@wso2.org] *On Behalf >>>> Of *Kasun Indrasiri >>>> *Sent:* marți, 17 mai 2016 00:07 >>>> *To:* architecture >>>> *Subject:* [Architecture] Improving error handling at different layers >>>> in ESB >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> ESB has to deal with different types of errors occurring at multiple >>>> layers in ESB message flow. As depicted in the following diagram, there can >>>> be different places where an error could happen. >>>> >>>> >>>> >>>> At the moment, the current design doesn't seems to ensure that all >>>> errors are propagated back to the other layers. For instance, if something >>>> goes wrong at the target side (E3 type errors) there's no generic place >>>> that all such errors are caught or handled and client may be holding up the >>>> connection to ESB. In most cases, such errors should be propagated to the >>>> associated fault sequence and error handling happens in the fault sequence. >>>> >>>> Therefore we need to carefully eval
Re: [Architecture] Product Integration Server thread model and implementation
;>>> >>>>>>> Use case:- >>>>>>> >>>>>>> (CPU ) >>>>>>> >>>>>>> Header based routing , send messages to Echo service and respond >>>>>>> back to client. >>>>>>> >>>>>>> TPS >>>>>>> >>>>>>> [image: image3.png] >>>>>>> >>>>>>> Latency >>>>>>> >>>>>>> [image: image4.png] >>>>>>> >>>>>>> >>>>>>> For test results please look in to [1] >>>>>>> >>>>>>> [1] >>>>>>> https://docs.google.com/spreadsheets/d/1A2dxknP1xEJKBpl4ymbQD2Mt9kWywYCI-60j16JVLx0/edit#gid=0 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> IsuruR >>>>>>> >>>>>>> -- >>>>>>> Best Regards >>>>>>> Isuru Ranawaka >>>>>>> M: +94714629880 >>>>>>> Blog : http://isurur.blogspot.com/ >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thank you and Best Regards, >>>>>> Chanaka Fernando >>>>>> Senior Technical Lead >>>>>> WSO2, Inc.; http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> >>>>>> mobile: +94 773337238 >>>>>> Blog : http://soatutorials.blogspot.com >>>>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >>>>>> Twitter:https://twitter.com/chanakaudaya >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ___ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *S. Suhothayan* >>>>> Technical Lead & Team Lead of WSO2 Complex Event Processor >>>>> *WSO2 Inc. *http://wso2.com >>>>> * <http://wso2.com/>* >>>>> lean . enterprise . middleware >>>>> >>>>> >>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>>>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: >>>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: >>>>> http://lk.linkedin.com/in/suhothayan >>>>> <http://lk.linkedin.com/in/suhothayan>* >>>>> >>>> >>>> >>>> >>>> -- >>>> Best Regards >>>> Isuru Ranawaka >>>> M: +94714629880 >>>> Blog : http://isurur.blogspot.com/ >>>> >>> >>> >>> >>> -- >>> >>> *S. Suhothayan* >>> Technical Lead & Team Lead of WSO2 Complex Event Processor >>> *WSO2 Inc. *http://wso2.com >>> * <http://wso2.com/>* >>> lean . enterprise . middleware >>> >>> >>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: >>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: >>> http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> *Ruwan Abeykoon* >> *Architect,* >> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >> *lean.enterprise.middleware.* >> >> email: ruw...@wso2.com >> > > > > -- > Best Regards > Isuru Ranawaka > M: +94714629880 > Blog : http://isurur.blogspot.com/ > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Siddhi] Making Disruptor configurable
Hi Suho, We have observed similar behavior with recent Gateway framework development in which the heavy resource consumption overrules the performance gain that the Disruptor brings in. Also for IO bound scenarios we tried using dedicated Disruptors for CPU and IO bound scenarios but that again didn't give a significant gain. In CEP's case have we identified specific use cases that we must use Disruptor configuration for gain maximum throughput? Thanks, Kasun On Sun, May 15, 2016 at 3:28 AM, Sriskandarajah Suhothayan wrote: > > Hi > > We have made Disruptor as optional for Siddhi[1], currently its always > enabled and it uses PhasedBackoffWaitStrategy, event though Disruptor was > giving high throughput there are several issues identified. > > 1. It is adding latency, and tuning latency is subject to use-cases hence > the deployment is becoming complicated. > 2. PhasedBackoffWaitStrategy is not showing good results when there are > lots of Disruptors. > > Hence we have removed disruptor by default and made is as an option to add > via configurations. > > By using @plan:async(bufferSize='') you can enable Disruptor at all > streams in an execution-plan with the queue size of . Here > (bufferSize='') is optional. > > e.g > > *@plan:async(bufferSize='2')* > > define stream cseEventStream (symbol string, price float, volume int); > > @info(name = 'query1') > from cseEventStream[70 > price] > select * > insert into innerStream ; > > @info(name = 'query2') > from innerStream[volume > 90] > select * > insert into outputStream ; > > In this case cseEventStream, innerStream and outputStream will have > async behaviors using Disruptor > > Alternatively we can also enable Disruptor for specific streams by > annotating them as below. > > e.g > > *@async(bufferSize='2')* > define stream cseEventStream (symbol string, price float, volume int); > > @info(name = 'query1') > from cseEventStream[70 > price] > select * > insert into innerStream ; > > @info(name = 'query2') > from innerStream[volume > 90] > select * > insert into outputStream ; > > > Here only cseEventStream will have async behavior using Disruptor > > Performance stats after the improvements. > > Filter Query *without* *Disruptor* > Throughput : 3.5M Events/sec > Time spend : *2.29E-4 ms* > > Filter Query *with Disruptor * > Throughput : *6.1M Events/sec * > Time spend : 0.028464 ms > > Multiple Filter Query without Disruptor > Throughput : 3.0M Events/sec > Time spend : 2.91E-4 ms > > Multiple Filter Query with Disruptor > Throughput : 5.5M Events/sec > Time spend : 0.089888 ms > > [1]https://github.com/wso2/siddhi/tree/latency > > Regards > Suho > > -- > > *S. Suhothayan* > Technical Lead & Team Lead of WSO2 Complex Event Processor > *WSO2 Inc. *http://wso2.com > * <http://wso2.com/>* > lean . enterprise . middleware > > > *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: > http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: > http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: > http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Debugger - Representing wire message debugging at the visual editor
Looks good. How do we handle the use cases in which we have multiple requests going out from ESB (i.e. such as service chaining scenario). In that case can we clearly identify and correlate wirelogs with its respecting requests/response? On Tue, May 3, 2016 at 12:12 AM, Rajith Vitharana wrote: > [Attaching some Screen shots] > > On Tue, May 3, 2016 at 12:28 PM, Rajith Vitharana > wrote: > >> Hi Kasun, >> >> Implemented the scenario, now it works fine other than below limitations >> >> * need to add a debug point in where ever we need to see wirelogs (for >> example if we need to see wirelogs for some send mediator, we need to put a >> debug point to that mediator) >> * need to right click on the mediator and click "show wirelogs" to view >> the wirelogs for that mediator( In the code review , it was suggested to >> change wirelog view so that it shows the corresponding wirelogs when ever >> we clicked on a mediator, didn't had time to do this yet) >> * flow is not implemented in nhttp transport >> * flow is not implemented in case we use clone mediator in the flow (need >> to clone the log holder object which reside inside message context and need >> to think of a way to aggregate that later) >> * have to test with some complex flows >> >> Other than that, now we can correlate and see wire logs for mediators >> (for example if there is a send mediator in the flow, we can see the >> wirelog sent to back end from the send mediator and the response for it, >> faced some difficulties when relating those information with the >> corresponding mediator when the messages are large, and was able to >> overcome them by introducing some locking mechanism in wirelevel. >> >> Thanks, >> >> On Tue, May 3, 2016 at 12:14 PM, Kasun Indrasiri wrote: >> >>> @Rajith : Can you please update the progress on this? >>> >>> On Mon, Apr 4, 2016 at 9:52 PM, Viraj Rajaguru wrote: >>> >>>> Hi Rajith, >>>> >>>> With the current implementation, we can only see the wire logs from >>>> Developer Studio while debugging without any correlation with the mediator. >>>> This might be acceptable when we have a simple message flow to debug with >>>> one or two back-end calls etc. But it comes to scenarios with large number >>>> of back-end calls, service chaining, scatter-gather etc.. the way we >>>> showing the wire logs might not be useful for users since we do not have >>>> any correlation. >>>> >>>> At the initial discussion we had with Kasun, we thought of having this >>>> correlation with mediators for wire logs. What we thought is to have a new >>>> view in Developer Studio to show the wire logs and show only the associated >>>> wire logs for a particular mediator(call, send etc.) once we click on the >>>> relevant mediator while debugging. >>>> >>>> As per the discussion we are having currently, it is not >>>> straightforward to have this correlation with mediators. But it might be >>>> really useful if we can implement this. >>>> >>>> Thanks, >>>> Viraj. >>>> >>>> On Tue, Apr 5, 2016 at 9:30 AM, Isuru Udana wrote: >>>> >>>>> Hi Kasun, >>>>> >>>>> TRANSPORT_HEADERS case is somewhat different, because we have access >>>>> to the all the transport level headers from the HttpRequest coming from >>>>> Http Core level, but for the entire message we won't be able to take that >>>>> approach. >>>>> >>>>> Thanks. >>>>> >>>>> On Tue, Apr 5, 2016 at 9:24 AM, Isuru Udana wrote: >>>>> >>>>>> Hi Kasun, >>>>>> >>>>>> It is not possible to make it a part of the message context as we >>>>>> don't have access to any context at the Wire level (Not even the http >>>>>> core >>>>>> level context). >>>>>> >>>>>> >>>>>> On Tue, Apr 5, 2016 at 9:11 AM, Kasun Indrasiri >>>>>> wrote: >>>>>> >>>>>>> Can we have wire level message information as part of the message >>>>>>> context (Of course we have to do this only if debugging is enabled or >>>>>>> something), so that we can correlate message and its wire level message >>>>>>> while debugging. >>>>>>> >&
[Architecture] Improving error handling at different layers in ESB
Hi, ESB has to deal with different types of errors occurring at multiple layers in ESB message flow. As depicted in the following diagram, there can be different places where an error could happen. At the moment, the current design doesn't seems to ensure that all errors are propagated back to the other layers. For instance, if something goes wrong at the target side (E3 type errors) there's no generic place that all such errors are caught or handled and client may be holding up the connection to ESB. In most cases, such errors should be propagated to the associated fault sequence and error handling happens in the fault sequence. Therefore we need to carefully evaluate the possible places that the errors can occur and handle them at an unified layer. Thanks, Kasun -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] ESB Analytics - Exposing ESB stats via JMX
Hi, We need to make sure that all the possible mediation stats are exposed via JMX too. We had JMX support in previous impl. Hence we can't lose that in the new impl. -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Debugger - Representing wire message debugging at the visual editor
@Rajith : Can you please update the progress on this? On Mon, Apr 4, 2016 at 9:52 PM, Viraj Rajaguru wrote: > Hi Rajith, > > With the current implementation, we can only see the wire logs from > Developer Studio while debugging without any correlation with the mediator. > This might be acceptable when we have a simple message flow to debug with > one or two back-end calls etc. But it comes to scenarios with large number > of back-end calls, service chaining, scatter-gather etc.. the way we > showing the wire logs might not be useful for users since we do not have > any correlation. > > At the initial discussion we had with Kasun, we thought of having this > correlation with mediators for wire logs. What we thought is to have a new > view in Developer Studio to show the wire logs and show only the associated > wire logs for a particular mediator(call, send etc.) once we click on the > relevant mediator while debugging. > > As per the discussion we are having currently, it is not straightforward > to have this correlation with mediators. But it might be really useful if > we can implement this. > > Thanks, > Viraj. > > On Tue, Apr 5, 2016 at 9:30 AM, Isuru Udana wrote: > >> Hi Kasun, >> >> TRANSPORT_HEADERS case is somewhat different, because we have access to >> the all the transport level headers from the HttpRequest coming from Http >> Core level, but for the entire message we won't be able to take that >> approach. >> >> Thanks. >> >> On Tue, Apr 5, 2016 at 9:24 AM, Isuru Udana wrote: >> >>> Hi Kasun, >>> >>> It is not possible to make it a part of the message context as we don't >>> have access to any context at the Wire level (Not even the http core level >>> context). >>> >>> >>> On Tue, Apr 5, 2016 at 9:11 AM, Kasun Indrasiri wrote: >>> >>>> Can we have wire level message information as part of the message >>>> context (Of course we have to do this only if debugging is enabled or >>>> something), so that we can correlate message and its wire level message >>>> while debugging. >>>> >>>> >>>> On Fri, Apr 1, 2016 at 9:46 AM, Rajith Vitharana >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I was able to simply show the wire log (what is just written to the >>>>> wire) as a property when a debug point get hits, But in that case there >>>>> are >>>>> some drawbacks, such as we can't see back end call wire logs because we >>>>> can't set debug point just after back end call happens, (we can see back >>>>> end response but not back end request) and also we can't see the final >>>>> response to the client as well(due to the same reason). >>>>> >>>>> But if we can just print the wire logs (as already doing when wire >>>>> logs are enabled in ESB) in Developer studio side when something gets >>>>> written to the wire, IMO that would be more usable, If we are going to do >>>>> that, we will have to figure out a way to filter the wire logs for that >>>>> specific service only(which is being debugged) otherwise it will show >>>>> everything which get's written to the wire. >>>>> WDYT? >>>>> >>>>> Thanks, >>>>> >>>>> On Thu, Mar 31, 2016 at 10:54 AM, Kasun Indrasiri >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> We came across a sort of a mandatory requirement for debugger : >>>>>> debugging wire level message from the visual editor. We need to >>>>>> figure out how to represent this visually + implement this at the core >>>>>> engine level (probably propagate these transport level information to the >>>>>> mediation level). >>>>>> >>>>>> With this feature, the debugger can be used to design/debug complete >>>>>> end to end message flows in ESB. >>>>>> >>>>>> Thanks, >>>>>> -- >>>>>> Kasun Indrasiri >>>>>> Software Architect >>>>>> WSO2, Inc.; http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> >>>>>> cell: +94 77 556 5206 >>>>>> Blog : http://kasunpanorama.blogspot.com/ >>>>>> >>>>> >>>>> >>>>> >>
Re: [Architecture] Replacing current JS engine used in script mediator with new rhino and nashorn script engines
Pallewela* >>>>> >>>>> >>>>> *Software Engineer* >>>>> >>>>> *WSO2, Inc. *http://wso2.com >>>>> *lean . enterprise . middleware* >>>>> >>>>> Email *nuw...@wso2.com * >>>>> Mobile *+94719079739 <%2B94719079739>@* >>>>> >>>>> >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Best Regards, >>>> >>>> Malaka Silva >>>> Senior Tech Lead >>>> M: +94 777 219 791 >>>> Tel : 94 11 214 5345 >>>> Fax :94 11 2145300 >>>> Skype : malaka.sampath.silva >>>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >>>> Blog : http://mrmalakasilva.blogspot.com/ >>>> >>>> WSO2, Inc. >>>> lean . enterprise . middleware >>>> http://www.wso2.com/ >>>> http://www.wso2.com/about/team/malaka-silva/ >>>> <http://wso2.com/about/team/malaka-silva/> >>>> https://store.wso2.com/store/ >>>> >>>> Save a tree -Conserve nature & Save the world for your future. Print >>>> this email only if it is absolutely necessary. >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Vanjikumaran Sivajothy >>> *Associate Technical Lead* >>> *WSO2 Inc. http://wso2.com <http://wso2.com/>* >>> *+1-925-464-6816* >>> [image: Facebook] <https://www.facebook.com/vanjikumaran> [image: >>> Twitter] <https://twitter.com/vanjikumaran> [image: LinkedIn] >>> <http://www.linkedin.com/pub/vanjikumaran-sivajothy/25/b31/293> [image: >>> Blogger] <http://vanjikumaran.blogspot.com/> [image: SlideShare] >>> <http://www.slideshare.net/vanjikumaran> >>> >>> This communication may contain privileged or other >>> confidential information and is intended exclusively for the addressee/s. >>> If you are not the intended recipient/s, or believe that you may >>> have received this communication in error, please reply to the >>> sender indicating that fact and delete the copy you received and in >>> addition, you should not print, copy, re-transmit, disseminate, or >>> otherwise use the information contained in this communication. >>> Internet communications cannot be guaranteed to be timely, secure, error >>> or virus-free. The sender does not accept liability for any errors >>> or omissions >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> *Prabath Ariyarathna* >> >> *Associate Technical Lead* >> >> *WSO2, Inc. * >> >> *lean . enterprise . middleware * >> >> >> *Email: prabat...@wso2.com * >> >> *Blog: http://prabu-lk.blogspot.com <http://prabu-lk.blogspot.com>* >> >> *Flicker : https://www.flickr.com/photos/47759189@N08 >> <https://www.flickr.com/photos/47759189@N08>* >> >> *Mobile: +94 77 699 4730 * >> >> >> >> >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Replacing current JS engine used in script mediator with new rhino and nashorn script engines
+1. How about the effort involves in moving to the new version? Anyway, better to do this enhancement for ESB 5.0. On Mon, Apr 11, 2016 at 12:22 PM, Nuwan Pallewela wrote: > Hi All, > > There is a limitation in wso2 script mediator when we try to manipulate > payloads with JavaScript as the scripting language, when the Payload size > is larger than 64KB, ESB throws an exception. Cause for this is Rhino > version which is used by the script mediator has a limitation of handling > JavaScript objects of size 64KB or more. But rhino have fixed it in the > later versions. So we can include new rhino and nashorn engines as the > script engine for JS in script mediator and avoid the limitation of > handling larger payloads. > Can we do this improvement to ESB 5.0.0 release? > > Thanks, > Nuwan > > -- > -- > > *Nuwan Chamara Pallewela* > > > *Software Engineer* > > *WSO2, Inc. *http://wso2.com > *lean . enterprise . middleware* > > Email *nuw...@wso2.com * > Mobile *+94719079739 <%2B94719079739>@* > > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Debugger - Representing wire message debugging at the visual editor
Yeah.. we might be not able to use the current wire-log implementation for do this but we need to find a way how we can pass the wire level message as part of the ctx. On Tue, Apr 5, 2016 at 9:30 AM, Isuru Udana wrote: > Hi Kasun, > > TRANSPORT_HEADERS case is somewhat different, because we have access to > the all the transport level headers from the HttpRequest coming from Http > Core level, but for the entire message we won't be able to take that > approach. > > Thanks. > > On Tue, Apr 5, 2016 at 9:24 AM, Isuru Udana wrote: > >> Hi Kasun, >> >> It is not possible to make it a part of the message context as we don't >> have access to any context at the Wire level (Not even the http core level >> context). >> >> >> On Tue, Apr 5, 2016 at 9:11 AM, Kasun Indrasiri wrote: >> >>> Can we have wire level message information as part of the message >>> context (Of course we have to do this only if debugging is enabled or >>> something), so that we can correlate message and its wire level message >>> while debugging. >>> >>> >>> On Fri, Apr 1, 2016 at 9:46 AM, Rajith Vitharana >>> wrote: >>> >>>> Hi, >>>> >>>> I was able to simply show the wire log (what is just written to the >>>> wire) as a property when a debug point get hits, But in that case there are >>>> some drawbacks, such as we can't see back end call wire logs because we >>>> can't set debug point just after back end call happens, (we can see back >>>> end response but not back end request) and also we can't see the final >>>> response to the client as well(due to the same reason). >>>> >>>> But if we can just print the wire logs (as already doing when wire logs >>>> are enabled in ESB) in Developer studio side when something gets written to >>>> the wire, IMO that would be more usable, If we are going to do that, we >>>> will have to figure out a way to filter the wire logs for that specific >>>> service only(which is being debugged) otherwise it will show everything >>>> which get's written to the wire. >>>> WDYT? >>>> >>>> Thanks, >>>> >>>> On Thu, Mar 31, 2016 at 10:54 AM, Kasun Indrasiri >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> We came across a sort of a mandatory requirement for debugger : >>>>> debugging wire level message from the visual editor. We need to >>>>> figure out how to represent this visually + implement this at the core >>>>> engine level (probably propagate these transport level information to the >>>>> mediation level). >>>>> >>>>> With this feature, the debugger can be used to design/debug complete >>>>> end to end message flows in ESB. >>>>> >>>>> Thanks, >>>>> -- >>>>> Kasun Indrasiri >>>>> Software Architect >>>>> WSO2, Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> cell: +94 77 556 5206 >>>>> Blog : http://kasunpanorama.blogspot.com/ >>>>> >>>> >>>> >>>> >>>> -- >>>> Rajith Vitharana >>>> >>>> Software Engineer, >>>> WSO2 Inc. : wso2.com >>>> Mobile : +94715883223 >>>> Blog : http://lankavitharana.blogspot.com/ >>>> >>> >>> >>> >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >> >> >> >> -- >> *Isuru Udana* >> Associate Technical Lead >> WSO2 Inc.; http://wso2.com >> email: isu...@wso2.com cell: +94 77 3791887 >> blog: http://mytecheye.blogspot.com/ >> > > > > -- > *Isuru Udana* > Associate Technical Lead > WSO2 Inc.; http://wso2.com > email: isu...@wso2.com cell: +94 77 3791887 > blog: http://mytecheye.blogspot.com/ > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Debugger - Representing wire message debugging at the visual editor
I mean.. from transport layer to mediation layer, we need to pass the relevant information for wire message. For instance, we are doing a similar thing to pass the transport headers through the mediation with the use of a map with 'TRANSPORT_HEADERS'. I guess we can do a similar thing to support the above use case too. WDYT? On Tue, Apr 5, 2016 at 9:11 AM, Kasun Indrasiri wrote: > Can we have wire level message information as part of the message context > (Of course we have to do this only if debugging is enabled or something), > so that we can correlate message and its wire level message while > debugging. > > > On Fri, Apr 1, 2016 at 9:46 AM, Rajith Vitharana wrote: > >> Hi, >> >> I was able to simply show the wire log (what is just written to the wire) >> as a property when a debug point get hits, But in that case there are some >> drawbacks, such as we can't see back end call wire logs because we can't >> set debug point just after back end call happens, (we can see back end >> response but not back end request) and also we can't see the final response >> to the client as well(due to the same reason). >> >> But if we can just print the wire logs (as already doing when wire logs >> are enabled in ESB) in Developer studio side when something gets written to >> the wire, IMO that would be more usable, If we are going to do that, we >> will have to figure out a way to filter the wire logs for that specific >> service only(which is being debugged) otherwise it will show everything >> which get's written to the wire. >> WDYT? >> >> Thanks, >> >> On Thu, Mar 31, 2016 at 10:54 AM, Kasun Indrasiri wrote: >> >>> Hi, >>> >>> We came across a sort of a mandatory requirement for debugger : >>> debugging wire level message from the visual editor. We need to figure >>> out how to represent this visually + implement this at the core engine >>> level (probably propagate these transport level information to the >>> mediation level). >>> >>> With this feature, the debugger can be used to design/debug complete >>> end to end message flows in ESB. >>> >>> Thanks, >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >> >> >> >> -- >> Rajith Vitharana >> >> Software Engineer, >> WSO2 Inc. : wso2.com >> Mobile : +94715883223 >> Blog : http://lankavitharana.blogspot.com/ >> > > > > -- > Kasun Indrasiri > Software Architect > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +94 77 556 5206 > Blog : http://kasunpanorama.blogspot.com/ > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Debugger - Representing wire message debugging at the visual editor
Can we have wire level message information as part of the message context (Of course we have to do this only if debugging is enabled or something), so that we can correlate message and its wire level message while debugging. On Fri, Apr 1, 2016 at 9:46 AM, Rajith Vitharana wrote: > Hi, > > I was able to simply show the wire log (what is just written to the wire) > as a property when a debug point get hits, But in that case there are some > drawbacks, such as we can't see back end call wire logs because we can't > set debug point just after back end call happens, (we can see back end > response but not back end request) and also we can't see the final response > to the client as well(due to the same reason). > > But if we can just print the wire logs (as already doing when wire logs > are enabled in ESB) in Developer studio side when something gets written to > the wire, IMO that would be more usable, If we are going to do that, we > will have to figure out a way to filter the wire logs for that specific > service only(which is being debugged) otherwise it will show everything > which get's written to the wire. > WDYT? > > Thanks, > > On Thu, Mar 31, 2016 at 10:54 AM, Kasun Indrasiri wrote: > >> Hi, >> >> We came across a sort of a mandatory requirement for debugger : debugging >> wire >> level message from the visual editor. We need to figure out how to >> represent this visually + implement this at the core engine level (probably >> propagate these transport level information to the mediation level). >> >> With this feature, the debugger can be used to design/debug complete end >> to end message flows in ESB. >> >> Thanks, >> -- >> Kasun Indrasiri >> Software Architect >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> cell: +94 77 556 5206 >> Blog : http://kasunpanorama.blogspot.com/ >> > > > > -- > Rajith Vitharana > > Software Engineer, > WSO2 Inc. : wso2.com > Mobile : +94715883223 > Blog : http://lankavitharana.blogspot.com/ > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] ESB Debugger - Representing wire message debugging at the visual editor
Hi, We came across a sort of a mandatory requirement for debugger : debugging wire level message from the visual editor. We need to figure out how to represent this visually + implement this at the core engine level (probably propagate these transport level information to the mediation level). With this feature, the debugger can be used to design/debug complete end to end message flows in ESB. Thanks, -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Proposal 8: [ESB/GW] HTTP Load balancer on top of WSO2 Gateway - Reg
Venkat added few comments. The proposal looks good! On Fri, Mar 25, 2016 at 11:25 PM, Venkat Raman wrote: > Hi Kasun, > > I have enabled it now. Kindly add your comments. I'll incorporate them > and plan accordingly. > > Thanks, > Venkat. > On Mar 25, 2016 11:03 PM, "Venkat Raman" wrote: > >> Sure Kasun. We can start. We are having Culturals, just now saw your >> mail. >> >> Yes OK, I'll enable it now. But I have only 1 hour to make change and >> submit proposal. >> >> Thanks, >> Venkat. >> On Mar 25, 2016 4:53 PM, "Kasun Indrasiri" wrote: >> >>> I think for the LB runtime also we should use the same engine that we >>> are building for the integration server. I think IsuruU is still finalizing >>> the code and the repo structure. Once it is completed, Venkat can start >>> working on the same engine. >>> So, in the mean time shall we start focusing on a use case. May be the >>> session persistence thing? >>> >>> On Fri, Mar 25, 2016 at 12:44 PM, Senduran Balasubramaniyam < >>> sendu...@wso2.com> wrote: >>> >>>> Hi Venkat, >>>> >>>> As a first step, you can extend the carbon message process with your >>>> simpleLB. Similar to your MockEngine. >>>> I'll share you a sample soon to send a request to the server. >>>> >>>> Regards >>>> Senduran >>>> >>>> On Wed, Mar 23, 2016 at 5:41 PM, Venkat Raman >>>> wrote: >>>> >>>>> Hi Senduran, >>>>> >>>>> Good Evening. I'm aspiring to participate in GSoC 2016 with HTTP LB >>>>> on top of gw as my project. I see u as a major contributor for product gw. >>>>> So, I am seeking your help. >>>>> >>>>> From the previous conversation in this mail with Isuru and Kasun you >>>>> can find that we will not be using Apache camel engine. So for reading LB >>>>> configurations, I have to use my own custom XSDs. Before starting with >>>>> XSD, I'm planning to do simple routing with my own custom routes that I >>>>> define using XML bean. Could you kindly guide me to write my own simple >>>>> producer and consumer? So far with the help of this post >>>>> <http://shafreenanfar.blogspot.in/2016/03/write-your-own-engine-for-wso2-gw.html>, >>>>> I've created my own engine and display all config from my Sample XML >>>>> <https://github.com/Venkat2811/SimpleLB/blob/master/src/main/java/loadbalancer-config.xml> >>>>> bean. >>>>> >>>>> Once I am able to do this, I will start with creating custom XSD and >>>>> proceed with my proposal >>>>> <https://docs.google.com/document/d/1Agl-Y_UKM5eMon8IDZa02aDGj0Yh_vZ7kFC2b1IzFI4/edit?usp=sharing> >>>>> . >>>>> >>>>> Will be looking forward for your help and guidance. >>>>> >>>>> >>>>> >>>>> >>>>> *Thanks,* >>>>> *Venkat.* >>>>> >>>>> On Tue, Mar 22, 2016 at 10:33 PM, Venkat Raman >>>>> wrote: >>>>> >>>>>> Hi Kasun, >>>>>> >>>>>> I've gone through gateway code. Route identification, Producer and >>>>>> Consumer are using Apache Camel with Carbon. As I've mentioned earlier, >>>>>> I'm trying to create simple mediation from my own XML bean. So, my >>>>>> endpoint from custom XML has to be registered as a route. >>>>>> >>>>>> The blog post for creating own gw-engine was very helpful and I >>>>>> learnt and understood a lot by implementing it. Could you kindly share >>>>>> any >>>>>> ref document or blog post for writing my own producers and consumers.? >>>>>> >>>>>> Will be looking forward for your guidance. >>>>>> >>>>>> >>>>>> >>>>>> *Thanks,* >>>>>> *Venkat.* >>>>>> >>>>>> On Mon, Mar 21, 2016 at 1:49 PM, Venkat Raman >>>>>> wrote: >>>>>> >>>>>>> Hi Isuru & Kasun, >>>>>>> >>>>>>> The above code gives a very basic definition based only on >>>>&
Re: [Architecture] Proposal 8: [ESB/GW] HTTP Load balancer on top of WSO2 Gateway - Reg
>>> >>>>>> >>>>>> >>>>>> >>>>>> *Thanks,* >>>>>> *Venkat.* >>>>>> >>>>>> On Thu, Mar 17, 2016 at 7:03 PM, Venkat Raman >>>>>> wrote: >>>>>> >>>>>>> Hi Isuru, >>>>>>> >>>>>>> Sorry for the inconvenience. I found the correct maven repository. >>>>>>> >>>>>>> With the changes in Pom.xml <http://pastebin.com/72fQMrs1> Build >>>>>>> was successful. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Thanks,* >>>>>>> *Venkat.* >>>>>>> >>>>>>> On Thu, Mar 17, 2016 at 11:35 AM, Venkat Raman >>>>>> > wrote: >>>>>>> >>>>>>>> Hi Isuru, >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> I went through the code and I'm having good overview about it. I >>>>>>>> also tried connecting to gateway through TELNET and tried few OSGi >>>>>>>> commands. It worked fine. >>>>>>>> >>>>>>>> I tried implementing the same MockEngine Example >>>>>>>> <http://shafreenanfar.blogspot.in/2016/03/write-your-own-engine-for-wso2-gw.html>, >>>>>>>> but I'm getting this Error <http://pastebin.com/jCW7kNGR> >>>>>>>> >>>>>>>> Please find the code here: >>>>>>>> >>>>>>>> Pom.xml <http://pastebin.com/LPKJVrQs> >>>>>>>> >>>>>>>> MockEngine.java <http://pastebin.com/ysPiqnx6> >>>>>>>> >>>>>>>> EchoEngineActivator.java <http://pastebin.com/jY6VYQ5q> >>>>>>>> >>>>>>>> I also couldn't find maven repos when I googled for them. Could >>>>>>>> you kindly help me with this.? I'll also be tying to fix this error >>>>>>>> from >>>>>>>> my side. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Thanks,* >>>>>>>> *Venkat.* >>>>>>>> >>>>>>>> On Thu, Mar 17, 2016 at 8:18 AM, Isuru Ranawaka >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Venkat, >>>>>>>>> >>>>>>>>> I have gone through your usecases document and it seems good.We >>>>>>>>> need to figure out a way how we can actually implement those >>>>>>>>> usecases. As >>>>>>>>> Kasun mentioned please look in to carbon transport implementation and >>>>>>>>> try >>>>>>>>> to write a simple engine . Basically we need figure out best way for >>>>>>>>> configure transport according to configurations given through engine >>>>>>>>> . for >>>>>>>>> example we need to configure transport for SSL support and those >>>>>>>>> informations are published by loadbalancer engine to the transport >>>>>>>>> any how >>>>>>>>> those need to be loosely couple with transport implementation . >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> >>>>>>>>> On Tue, Mar 15, 2016 at 8:15 PM, Venkat Raman < >>>>>>>>> vraman2...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Kasun, >>>>>>>>>> >>>>>>>>>> Thank you for your valuable guidance. I started drafting my >>>>>>>>>> proposal. I'll look into it and come up with design and share it >>>>>>>>>> with you. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *Thanks,* >>>>>>>>>> *Venkat.* >>>>>>>>>> >>>>>>>>>> On Tue, Mar
Re: [Architecture] The new disruptor based Netty transport is not working well for MSF4J
hould perform as same level >>>>> as vanilla Netty. >>>>> >>>> >>>> There's no reason why that cannot be the case. >>>> >>>> Can't we keep Disruptor while improve performance of Carbon transport >>>>> ? >>>>> >>>> >>>> Disruptor is a technique to make things more performant not less >>>> performant. We have to figure out what's wrong and fix it - not throw the >>>> baby out with the bathwater. >>>> >>> >>> Yes, we are in the process of trying to figure out why disruptor as >>> opposed to the Netty executor threadpool gives better performance for the >>> gateway (dispatching to a zero delay backend), while for an MSF4J service >>> which has a sleep in it, it is the other way around. >>> >>> >>>> >>>> Sanjiva. >>>> -- >>>> Sanjiva Weerawarana, Ph.D. >>>> Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ >>>> email: sanj...@wso2.com; office: (+1 650 745 4499 | +94 11 214 5345) >>>> x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311 >>>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >>>> Lean . Enterprise . Middleware >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Afkham Azeez* >>> Director of Architecture; WSO2, Inc.; http://wso2.com >>> Member; Apache Software Foundation; http://www.apache.org/ >>> * <http://www.apache.org/>* >>> *email: **az...@wso2.com* >>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>> *http://blog.afkham.org* <http://blog.afkham.org> >>> *twitter: **http://twitter.com/afkham_azeez* >>> <http://twitter.com/afkham_azeez> >>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>> <http://lk.linkedin.com/in/afkhamazeez>* >>> >>> *Lean . Enterprise . Middleware* >>> >> >> >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>* >> *email: **az...@wso2.com* >> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >> *http://blog.afkham.org* <http://blog.afkham.org> >> *twitter: **http://twitter.com/afkham_azeez* >> <http://twitter.com/afkham_azeez> >> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >> <http://lk.linkedin.com/in/afkhamazeez>* >> >> *Lean . Enterprise . Middleware* >> > > > > -- > Best Regards > Isuru Ranawaka > M: +94714629880 > Blog : http://isurur.blogspot.com/ > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] The new disruptor based Netty transport is not working well for MSF4J
Yes, Azeez. So we are currently testing following approaches, with some processing at the engine side (rather than doing just pass-thru). - Transport with netty worker pool(IO) -> message processing worker pool which does the dispatching/processing of the messages : (No Disruptor/Making the disruptor optional) - Transport with Disruptor + Single event handler (GW's default thread model) : This is the model that gave us the best performance for the GW scenario(header based routing). - Transport with Disruptor + native worker pool for event handler. Based on the outcome of this, we can decide which thread model suits the best when it comes to msf4j like scenario and we can make it configurable at the transport side. On Fri, Mar 11, 2016 at 10:06 AM, Afkham Azeez wrote: > I think Samiyuru tested with that nrw worker pool & still the performance > is unacceptable. > On Mar 11, 2016 9:45 AM, "Isuru Ranawaka" wrote: > >> Hi , >> >> We have already added native worker pool for Disruptor and Samiyuru is >> doing testing on that. We will make disruptor optional as well. >> >> thanks >> >> On Thu, Mar 10, 2016 at 9:29 AM, Kasun Indrasiri wrote: >> >>> Yes, we can make the disruptor optional. Also, we should try using the >>> native worker pool for Event Handler[1], so that the Disruptor itself runs >>> the event handler on a worker pool. We'll implement both approaches and do >>> a comparison. >>> >>> [1] >>> https://lmax-exchange.github.io/disruptor/docs/com/lmax/disruptor/dsl/Disruptor.html#handleEventsWithWorkerPool(com.lmax.disruptor.WorkHandler.. >>> .) >>> >>> On Thu, Mar 10, 2016 at 8:48 AM, Afkham Azeez wrote: >>> >>>> After upgrading to the new transport, we are seeing a significant drop >>>> in performance for any service that take some time to execute. We have >>>> tried with the configuration used for the gateway which gave the best >>>> figures on the same hardware. We have also noted that using a separate >>>> dedicated executor thread pool, which is supported by Netty, gave much >>>> better performance than the disruptor based implementation. Even in theory, >>>> disruptor cannot give better performance when used with a real service that >>>> does some real work, rather than doing passthrough, for example. Can we >>>> improve the Netty transport to make going through disruptor optional? >>>> >>>> -- >>>> *Afkham Azeez* >>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>> Member; Apache Software Foundation; http://www.apache.org/ >>>> * <http://www.apache.org/>* >>>> *email: **az...@wso2.com* >>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>> *twitter: **http://twitter.com/afkham_azeez* >>>> <http://twitter.com/afkham_azeez> >>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>> >>>> *Lean . Enterprise . Middleware* >>>> >>> >>> >>> >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >> >> >> >> -- >> Best Regards >> Isuru Ranawaka >> M: +94714629880 >> Blog : http://isurur.blogspot.com/ >> > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] The new disruptor based Netty transport is not working well for MSF4J
Yes, we can make the disruptor optional. Also, we should try using the native worker pool for Event Handler[1], so that the Disruptor itself runs the event handler on a worker pool. We'll implement both approaches and do a comparison. [1] https://lmax-exchange.github.io/disruptor/docs/com/lmax/disruptor/dsl/Disruptor.html#handleEventsWithWorkerPool(com.lmax.disruptor.WorkHandler.. .) On Thu, Mar 10, 2016 at 8:48 AM, Afkham Azeez wrote: > After upgrading to the new transport, we are seeing a significant drop in > performance for any service that take some time to execute. We have tried > with the configuration used for the gateway which gave the best figures on > the same hardware. We have also noted that using a separate dedicated > executor thread pool, which is supported by Netty, gave much better > performance than the disruptor based implementation. Even in theory, > disruptor cannot give better performance when used with a real service that > does some real work, rather than doing passthrough, for example. Can we > improve the Netty transport to make going through disruptor optional? > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **az...@wso2.com* > * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez* > <http://twitter.com/afkham_azeez> > *linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [ANNOUNCEMENT][WSO2 ESB]Changing the version number of the next WSO2 ESB release from 4.10.0 to 5.0.0
Also, to clarify that there won't be any major changes related to mediation language or runtime. Therefore that ensures the seamless migration from old versions to ESB 5. On Wed, Feb 10, 2016 at 2:03 PM, Chanaka Fernando wrote: > Hi Devs, > > WSO2 team has decided to change the version of the next WSO2 ESB release > from 4.10.0 to 5.0.0 with immediate effect. We have been adding several new > features with the ongoing development tasks and after considering the > importance of the new features, we have decided to do a major version bump > and made the next ESB release version as 5.0.0. Here are the main features > which we are going to introduce with this release. > > 1. WebSockets Connectivity - Adding websockets support for WSO2 ESB. > > 2. Message Flow Tracing - Comprehensive message flow tracing with the Data > Analytics Server (DAS) integration. > > 3. Message Flow Statistics - Advanced application level statistics (Proxy, > API, Sequence, Mediator) support with the DAS integration. > > 4. JMS 2.0 support - Adding JMS 2.0 specification support for existing JMS > messaging features. > > 5. Mediation flow debugger - Adding debugging capability to ESB mediation > flows from the WSO2 Developer Studio tool. > > 6. Updating smooks - To achieve better performance, smooks bundle has been > updated to latest stable released version 1.5.1. > > We will release the first milestone version of the ESB 5.0.0 as the next > release. > > Thanks, > Chanaka > > -- > Thank you and Best Regards, > Chanaka Fernando > Senior Technical Lead > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 773337238 > Blog : http://soatutorials.blogspot.com > LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 > Twitter:https://twitter.com/chanakaudaya > > > > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [MB] Abstracting transport layer from core
On Tue, Feb 9, 2016 at 5:48 PM, Kishanthan Thangarajah wrote: > For this requirement, can we follow the same approach of how > carbon-transports and carbon-messaging layers have been developed with the > abstraction where you can plugin any transports and/or any message types > associated with transports for processing? > > Yes, please check the thread "GW/ESB5 messaging architecture" on architecture@. For GW/ESB we had a similar requirement and we introduced the carbon message concept as the generic message representation in C5. I think you guys should use the same messaging architecture with MB, so that you can completely decouple protocol layer from your internal engine/core. Otherwise we'll end up having different design for inbound and outbound messaging for different products. Ideally we should use the same transport (for a given protocol) across the entire platform (say MQTT or AMQP) but there may some exceptions. > On a related note, In kernel we have the managed transports concept, where > the kernel manages the lifecycle of all transports such as start, stop, > begin maintenance, etc [1]. > > Thanks, > Kishanthan. > [1] > https://github.com/wso2/carbon-kernel/blob/master/core/src/main/java/org/wso2/carbon/kernel/transports/CarbonTransport.java > > On Tue, Feb 9, 2016 at 4:36 PM, Selvaratnam Uthaiyashankar < > shan...@wso2.com> wrote: > >> >> >> On Tuesday, February 9, 2016, Pamod Sylvester wrote: >> >>> Hi All, >>> >>> Currently transports (AMQP,MQTT) in MB are coupled with the andes core >>> (same bundle). We're in process of identifying a way to abstract the >>> transports from its core, so that we bring in a pluggable architecture >>> which would allow plug in the relevant transport to the broker on demand. >>> This will help to featherweight MB. >>> >>> The abstract message flow would look like the following, >>> [image: Inline image 2] >>> As depicted in the above diagram, if the transport is abstracted into a >>> separate bundle, there will be circular dependency between the core and the >>> transport. i.e when messages are published 'transport' will need to call >>> services in the 'core' and when messages are distributed to the subscribers >>> the 'core' will need to call services in the 'transport' >>> >> >> When we have multiple transports, how the core knows which transport to >> call to distribute messages to subscribers? Isn't the core suppose to call >> an "interface", so that the core doesn't know about any concrete >> transports? If so, there won't be any circular dependencies, right? >> >> >> >>> >>> Currently we're in the process of identifying a solution for the >>> circular dependency, making the cardinality of one of the referencing >>> service optional [1] could be a solution, but we need to understand whether >>> there's a better approach for this. >>> >>> WDYT ? >>> >>> [1] >>> http://docs.spring.io/osgi/docs/current/api/org/springframework/osgi/service/importer/support/Cardinality.html >>> >>> Thanks, >>> Pamod >>> -- >>> *Pamod Sylvester * >>> >>> *WSO2 Inc.; http://wso2.com <http://wso2.com>* >>> cell: +94 77 7779495 >>> >> >> >> -- >> S.Uthaiyashankar >> VP Engineering >> WSO2 Inc. >> http://wso2.com/ - "lean . enterprise . middleware" >> >> Phone: +94 714897591 >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Kishanthan Thangarajah* > Associate Technical Lead, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* > Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Fwd: ESB Analytics Mediation Event Publishing Mechanism
I think for trancing use case we need to publish events one by one from
each mediator (we can't aggregate all such events as it also contains the
message payload)
-- Forwarded message --
From: Supun Sethunga
Date: Mon, Feb 8, 2016 at 2:54 PM
Subject: Re: ESB Analytics Mediation Event Publishing Mechanism
To: Anjana Fernando
Cc: "engineering-gr...@wso2.com" , Srinath
Perera , Sanjiva Weerawarana , Kasun
Indrasiri , Isuru Udana
Hi all,
Ran some simple performance tests against the new relational provider, in
comparison with the existing one. Follow are the results:
*Records in Backend DB Table*: *1,054,057*
*Conversion:*
Spark Table
id a b c
Backend DB Table 1 xxx yyy zzz
id data 1 ppp qqq rrr
1
[{'a':'aaa','b':'bbb','c':'ccc'},{'a':'xxx','b':'yyy','c':'zzz'},{'a':'ppp','b':'qqq','c':'rrr'}]
--
To --> 1 aaa bbb ccc
2
[{'a':'aaa','b':'bbb','c':'ccc'},{'a':'xxx','b':'yyy','c':'zzz'},{'a':'ppp','b':'qqq','c':'rrr'}]
2 xxx yyy zzz
2 aaa bbb ccc
2 ppp qqq rrr
*Avg Time for Query Execution:*
Querry
Execution time (~ sec)
Existing Analytics Relation Provider New (ESB) Analytics Relation Provider* *
New relational provider split a single row to multiple rows. Hence the
number of rows in the table equivalent to 3 times (as each row is split to
3 rows) as the original table.
SELECT COUNT(*) FROM ; 13 16
SELECT * FROM ORDER BY id ASC; 13 16
SELECT * FROM WHERE id=98435; 13 16
SELECT id,a,first(b),first(c) FROM GROUP BY id,a ORDER BY id ASC; 18
26
Regards,
Supun
On Wed, Feb 3, 2016 at 3:36 PM, Supun Sethunga wrote:
> Hi all,
>
> I have started working on implementing a new "relation" / "relation
> provider", to serve the above requirement. This basically is a modified
> version of the existing "Carbon Analytics" relation provider.
>
> Here I have assumed that the encapsulated data for a single execution flow are
> stored in a single row, and the data about the mediators invoked during the
> flow are stored in a known column of each row (say "data"), as an array
> (say a json array). When each row is read in to spark, this relational
> provider create separate rows for each of the element in the array stored
> in "data" column. I have tested this with some mocked data, and works as
> expected.
>
> Need to test with the real data/data-formats, and modify the mapping
> accordingly. Will update the thread with the details.
>
> Regards,
> Supun
>
>
> On Tue, Feb 2, 2016 at 2:36 AM, Anjana Fernando wrote:
>
>> Hi,
>>
>> In a meeting I'd with Kasun and the ESB team, I got to know that, for
>> their tracing mechanism, they were instructed to publish one event for each
>> of the mediator invocations, where, earlier they had an approach, they
>> publish one event, which encapsulated data of a whole execution flow. I
>> would actually like to support the latter approach, mainly due to
>> performance / resource requirements. And also considering the fact, this is
>> a feature that could be enabled in production. So simply, if we do one
>> event per mediator, this does not scale that well. For example, if the ESB
>> is doing 1k TPS, for a sequence that has 20 mediators, that is 20k TPS for
>> analytics traffic. Combine that with a possible ESB cluster hitting a DAS
>> cluster with a single backend database, this maybe too many rows per second
>> written to the database. Where the main problem here is, one event is, a
>> single row/record in the backend database in DAS, so it may come to a
>> state, where the frequency of row creations by events coming from ESBs
>> cannot be sustained.
>>
>> If we create a single event from the 20 mediators, then it is just 1k TPS
>> for DAS event receivers and the database too, event though the message size
>> is bigger. It is not necessarily same performance, if you publish lots of
>> small events to publishing bigger events. Throughput wise, comparatively
>> bigger events will win (even though if we consider that, small operations
>> will be batched in transport level etc.. still one event = one database
>> row). So I would suggest, we try out a single sequence flow = single event,
>> approach, and from the Spark processing side, we consider one of these big
>> rows as multiple rows in Spark. I was first thinking, if UDFs can help in
>> splitting a single column to multiple rows, and that is not possi
Re: [Architecture] Distributed Coordination in C5 was [Hangout Session] With Kernel Team On MB C5 Plans @ Mon Feb 8, 2016 2pm - 3pm (ram...@wso2.com)
On Tue, Feb 9, 2016 at 9:56 AM, Ramith Jayasinghe wrote: > we are +1 for Hazelcast. we use it main for group communication (and > member discovery). > > On Mon, Feb 8, 2016 at 8:31 PM, Srinath Perera wrote: > > Moving to arch@ > > > > CEP ( for Storm based version), MB ( for base algo), ESB ( for tasks) are > > known cases. For those, we can use Hazelcast ( they can use it directly). > > > Yeah, in ESB we used it for Polling Inbound endpoints (JMS, VFS etc.), Message Processor coordination and Scheduled Task coordination (the underlying implementation is based on ntasks). Regarding the # of nodes, say if we have few hundreds of nodes which requires coordination for aforementioned functionality, I guess Hazelcast still can gracefully handle that use case too. > > Hazelcast works OK with small number of nodes. AFAIK, there is no better > > solution ( we use Zookeeper before) unless there is something new. > > > > --Srinath > > > > > > > > On Mon, Feb 8, 2016 at 8:07 PM, Sameera Jayasoma > wrote: > >> > >> Looks like several products require distributed coordination. We need to > >> evaluate these requirements and come up with a solution. > >> > >> Hazelcast is used in C4 based products to achieve distributed > >> coordination. Not sure whether we should go ahead with Hazelcast after > all > >> the issues we've faced so far with it. > >> > >> Kasun, Ramith and Suho can you guys explain the requirement to use the > >> distributed coordination. > >> > >> Thanks, > >> Sameera. > >> > > > > > > -- > Ramith Jayasinghe > Technical Lead > WSO2 Inc., http://wso2.com > lean.enterprise.middleware > > E: ram...@wso2.com > P: +94 777542851 > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] GW/ESB5 messaging architecture
Yeah, absolutely! Unlike in ESB 4.x, we need to take debugging, tracing and stats as part of the design of the mediation engine/transport layer. On Fri, Jan 22, 2016 at 12:46 AM, Isabelle Mauny wrote: > It will have that Harshana - We are making this part of the engine design. > Isabelle. > > > - > *Isabelle Mauny* > VP, Product Management - WSO2, Inc. - http://wso2.com/ > email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri > Lanka) +94 (0)774777663 > Landline: +1 (650) 745 4499 (USA) or +94 (11) 214 534 (SL) Extension : > 7302 > > On Tue, Jan 19, 2016 at 1:10 PM, Harshana Eranga Martin < > harshan...@gmail.com> wrote: > >> Hi Kasun, >> >> Does the C5 ESB, GW and Carbon Transport has the message debug capability >> similarly what you are building with C4 mediation debugger capability at >> the moment? >> >> If not it would be quite useful to build a mediation debugging capability >> as a core capability so that every product inherently have the capability. >> Once DevS team build the visual debugging interface users can use DevS to >> test and debug the implementations on the fly for any product. >> >> Thanks and Regards, >> Harshana >> >> On Tuesday, 19 January 2016, Kasun Indrasiri wrote: >> >>> >>> >>> On Tue, Jan 19, 2016 at 11:50 AM, Kasun Indrasiri >>> wrote: >>> >>>> Hi, >>>> >>>> This is a summary of how we support messaging with C5 ESB and GW. >>>> >>>> *Carbon Message [1] * >>>> - This is the generic message representation which contains message >>>> headers and reference to extract the message body (fully type-aware and no >>>> canonicalization required) >>>> - The idea is to use this as the generic message representation across >>>> the all the products that uses carbon-transport. >>>> >>>> *Carbon Transports* >>>> - Protocol handling layer that converts the wire msg -> carbon message >>>> (receiving) and carbon-message -> wire msg (sending). >>>> - The objective is to make sure all products can use same transports >>>> with generic message representation (without any canonicalized message such >>>> as SOAP). At the moment with C4, since we don't have a generic message >>>> representation, different products has to implement their own protocol >>>> handlers/transports to cater to their specific needs. (eg: ESB, CEP etc.) >>>> >>>> *Carbon Message Processor* (API) [2] >>>> - Any component that want to consume message from transport has to >>>> implement this and plug that in. >>>> - We use this mechanism to receive messages into the GW message >>>> processor/engine through the Netty transport [3]. >>>> - In addition you can use the TransportSender in case if you want to >>>> send message out from the message processor impl through any protocol. >>>> >>>> *CarbonCallback[4] * >>>> - We don't use in and out flow model any more in the new architecture. >>>> So, both request and response flows work asynchronously with the use of >>>> callbacks. (Idea is to later replace this with RxJava) >>>> >>>> I think all these things are completely independent from ESB/GW and can >>>> be used as the generic messaging architecture for C5. >>>> >>>> [1] >>>> https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonMessage.java >>>> [2] >>>> https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonMessageProcessor.java >>>> >>>> [3] >>>> https://github.com/wso2/product-gw/blob/master/carbon-gw/components/org.wso2.carbon.gateway/src/main/java/org/wso2/carbon/gateway/internal/mediation/camel/CamelMediationEngine.java >>>> >>>> [4] >>> https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonCallback.java >>> >>> >>>> @Shafreen/Senduran : Please add if anything else is missing. >>>> >>>> Thanks, >>>> -- >>>> Kasun Indrasiri >>>> Software Architect >>>> WSO2, Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> cell: +94 77 556 5206 >>>> Blo
Re: [Architecture] GW/ESB5 messaging architecture
On Tue, Jan 19, 2016 at 11:50 AM, Kasun Indrasiri wrote: > Hi, > > This is a summary of how we support messaging with C5 ESB and GW. > > *Carbon Message [1] * > - This is the generic message representation which contains message > headers and reference to extract the message body (fully type-aware and no > canonicalization required) > - The idea is to use this as the generic message representation across the > all the products that uses carbon-transport. > > *Carbon Transports* > - Protocol handling layer that converts the wire msg -> carbon message > (receiving) and carbon-message -> wire msg (sending). > - The objective is to make sure all products can use same transports with > generic message representation (without any canonicalized message such as > SOAP). At the moment with C4, since we don't have a generic message > representation, different products has to implement their own protocol > handlers/transports to cater to their specific needs. (eg: ESB, CEP etc.) > > *Carbon Message Processor* (API) [2] > - Any component that want to consume message from transport has to > implement this and plug that in. > - We use this mechanism to receive messages into the GW message > processor/engine through the Netty transport [3]. > - In addition you can use the TransportSender in case if you want to send > message out from the message processor impl through any protocol. > > *CarbonCallback[4] * > - We don't use in and out flow model any more in the new architecture. So, > both request and response flows work asynchronously with the use of > callbacks. (Idea is to later replace this with RxJava) > > I think all these things are completely independent from ESB/GW and can be > used as the generic messaging architecture for C5. > > [1] > https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonMessage.java > [2] > https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonMessageProcessor.java > > [3] > https://github.com/wso2/product-gw/blob/master/carbon-gw/components/org.wso2.carbon.gateway/src/main/java/org/wso2/carbon/gateway/internal/mediation/camel/CamelMediationEngine.java > > [4] https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonCallback.java > @Shafreen/Senduran : Please add if anything else is missing. > > Thanks, > -- > Kasun Indrasiri > Software Architect > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +94 77 556 5206 > Blog : http://kasunpanorama.blogspot.com/ > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] GW/ESB5 messaging architecture
Hi, This is a summary of how we support messaging with C5 ESB and GW. *Carbon Message [1] * - This is the generic message representation which contains message headers and reference to extract the message body (fully type-aware and no canonicalization required) - The idea is to use this as the generic message representation across the all the products that uses carbon-transport. *Carbon Transports* - Protocol handling layer that converts the wire msg -> carbon message (receiving) and carbon-message -> wire msg (sending). - The objective is to make sure all products can use same transports with generic message representation (without any canonicalized message such as SOAP). At the moment with C4, since we don't have a generic message representation, different products has to implement their own protocol handlers/transports to cater to their specific needs. (eg: ESB, CEP etc.) *Carbon Message Processor* (API) [2] - Any component that want to consume message from transport has to implement this and plug that in. - We use this mechanism to receive messages into the GW message processor/engine through the Netty transport [3]. - In addition you can use the TransportSender in case if you want to send message out from the message processor impl through any protocol. *CarbonCallback[4] * - We don't use in and out flow model any more in the new architecture. So, both request and response flows work asynchronously with the use of callbacks. (Idea is to later replace this with RxJava) I think all these things are completely independent from ESB/GW and can be used as the generic messaging architecture for C5. [1] https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonMessage.java [2] https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonMessageProcessor.java [3] https://github.com/wso2/product-gw/blob/master/carbon-gw/components/org.wso2.carbon.gateway/src/main/java/org/wso2/carbon/gateway/internal/mediation/camel/CamelMediationEngine.java @Shafreen/Senduran : Please add if anything else is missing. Thanks, -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Decoupling API-GW from API Publisher/Store
@Sanjeewa, I think we have to provide an abstraction from API-M (something like GWInterface) so that an implementation of that GWInterface can dynamically register with API-M through OSGi. That implementation contains all the logic required to publish a given API to the GW that we are planning to integrate with. There will be quite a few things that we have to do this to work, but in the long run this will be quite useful. @Shiro: Yes, if we manage to do this, theoretically we can integrate with any GW. But I'm not sure whether its a common requirement at the moment. On Mon, Jan 18, 2016 at 11:39 PM, Shiro Kulatilake wrote: > Hi, > > Are we looking at making it possible to plug in any gateway - i.e. WSO2 or > non-WSO2 ? - If yes that would be great. > However then > - the API definition itself might have to be customizable - or extensible > from a base model > - the "object" that is propagated to the gateway of choice needs to be > anything as well > > Isn't this the same thing that we do with Greg today to publish APIs to > different gateways through registry extensions ? > > Thank you, > Shiro > > On Mon, Jan 18, 2016 at 11:20 PM, Sanjeewa Malalgoda > wrote: > >> Hi kasun, >> If we consider current architecture publisher will call to rest api admin >> service and push api configurations created using velosity template. If we >> are having similar service in new gateway and created velosity template >> according to new definition we can easily push apis to new gateway. >> If need we may provide extension point to api publishing. Then we will >> have complete API object in extesion and we can publish to any custom >> gateway as we need. >> Store do not need direct service access of gateway. >> >> Thanks >> sanjeewa. >> >> sent from my phone >> On Jan 18, 2016 10:59 PM, "Kasun Indrasiri" wrote: >> >>> Hi, >>> >>> When it comes to moving API-M to the new GW in the future, I think >>> having the $subject would be really helpful. This would allow us to plug >>> any arbitrary GW impl along with the required wrappers (implementing the >>> API-GW abstractions). >>> >>> WDYT? >>> >>> Thanks, >>> Kasun. >>> >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > > *Shiroshica Kulatilake | Solutions Architect, WSO2 Inc.+94 776523867 > <%2B94%20776523867> * > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Decoupling API-GW from API Publisher/Store
Hi, When it comes to moving API-M to the new GW in the future, I think having the $subject would be really helpful. This would allow us to plug any arbitrary GW impl along with the required wrappers (implementing the API-GW abstractions). WDYT? Thanks, Kasun. -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Connector Improvements for 2016
Hi, - What's selection process for the connectors listed below? We don't see some of the major connectors that are frequently used are not listed here. - Also, can you please elaborate more on the type of improvements that we are planning? -- Forwarded message -- From: Malaka Silva Date: Mon, Dec 14, 2015 at 5:50 PM Subject: Re: [Architecture] Connector Improvements 2016 To: Elilmatha Sivanesan Cc: architecture Hi Elilmatha, Connectors like GotoWebinar, Concur and Github will be improved when we are using those for internal integration. What we need to focus here is to get some other connectors in batches of 5-10 and improve usability and method coverage. One way to select connectors from pool of 140+ is considering factors like usage, popularity, no of users, usage of enterprise integration use cases or business domain. We need to get that list first. On Mon, Dec 14, 2015 at 2:38 PM, Elilmatha Sivanesan wrote: > > Hi all, > > We are planning to improve the following ESB connectors in Q1 next year. > >- Facebook - Need to improve the existing methods with new api changes. >- GotoWebinar - Need to implement the attendees resources >- Paypal - Need to implement more resources >- Hubspot - Need to implement more resources >- Concur - Need to implement invoice resources >- Github - Need to implement more resources >- Amazon Connectors - Need to verify all amazon connectors >(amazonsqs,amazondb,amazonsns,amazons3,amazonses)with ESB 4.9.0 > > Thanks. > -- > *S.Elilmatha* > Associate Software Engineer, > > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > Mobile 0779842221. > > -- Best Regards, Malaka Silva Senior Tech Lead M: +94 777 219 791 Tel : 94 11 214 5345 Fax :94 11 2145300 Skype : malaka.sampath.silva LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 Blog : http://mrmalakasilva.blogspot.com/ WSO2, Inc. lean . enterprise . middleware http://www.wso2.com/ http://www.wso2.com/about/team/malaka-silva/ <http://wso2.com/about/team/malaka-silva/> https://store.wso2.com/store/ Save a tree -Conserve nature & Save the world for your future. Print this email only if it is absolutely necessary. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] WebSockets support in ESB 4.10
Yes Eranga. That's is a valid use case. AFAIR, we discuss about this use case with Kevin. @Kevin : WDYT? On Tue, Dec 22, 2015 at 12:03 PM, Eranga Perera wrote: > Hi, > > How can we facilitate broadcasting to a web socket channel. If there are > multiple subscribers to that channel can we discriminate what messages > should go to each subscriber. I am thinking how a web socket chat > application be implemented with ESB mediation sequences. > > Eranga. > > On Tue, Dec 22, 2015 at 11:12 AM, Kevin Ratnasekera > wrote: > >> Hi all, >> Here are the main use cases we found with related to WebSockets support >> in 410. >> >> 1. Websocket client to Websocket endpoint via ESB >> >> >> >> 2. Websocket client to HTTP endpoint via ESB >> >> >> >> 3. HTTP client to Websocket endpoint via ESB >> >> >> In each of the main use cases we need to support following sub use cases. >> >> 1. Header based routing scenario. This will be depend on the HTTP header >> specified at the initial handshake stage. >> 2. Content transformation scenario. As Websockets allows two way >> communication, we should be able to support two way mediation. >> >> Configuration should include two dispatching sequences on for >> bidirectional message flows. one for the client to backend mediation other >> for the backend to client mediation. >> >> 3. Support different content types for Websocket frames dynamic way. This >> is handled using Websocket Sub protocol. >> >> Regards >> Kevin >> >> On Tue, Dec 22, 2015 at 10:22 AM, Kasun Indrasiri wrote: >> >>> Hi all, >>> >>> We are working on adding WebSockets support into ESB 4.10. For the >>> default HTTP transport we won't be able to incorporate it as HTTPCore >>> doesn't offer native WebSockets support. However, with the concept of >>> inbound endpoints/connectors we will be able to implement it by leveraging >>> Netty. So that means we have to use a dedicated HTTP port with WebSocket >>> support. >>> >>> Kevin can you please share the main WebSockets use cases that we came up >>> with. >>> >>> Thanks, >>> Kasun. >>> >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Eranga Perera > *Senior Lead Solutions Engineer* > *WSO2, Inc. * > Mobile : +94 72 778 4250 > eran...@wso2.com > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] WebSockets support in ESB 4.10
Hi all, We are working on adding WebSockets support into ESB 4.10. For the default HTTP transport we won't be able to incorporate it as HTTPCore doesn't offer native WebSockets support. However, with the concept of inbound endpoints/connectors we will be able to implement it by leveraging Netty. So that means we have to use a dedicated HTTP port with WebSocket support. Kevin can you please share the main WebSockets use cases that we came up with. Thanks, Kasun. -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10
@Kathees : Can we verify NTLM use cases with Call mediator + blocking behavior? I guess it should work out of box as we also reuse the same blocking sender code? For DB* mediators, I guess we can clearly mention in the docs that these mediators can be only used for very limited kind of DB operations but not for any complex DB integrations we must use DSS. And we won't any such features to DB* mediators. POJO/Spring mediators seems to need more attention :) and we should enhance them with proper use case docs. WDYT? On Fri, Dec 11, 2015 at 1:28 AM, Dulitha Wijewantha wrote: > > > On Thu, Dec 10, 2015 at 1:26 AM, Vidura Gamini Abhaya > wrote: > >> Hi Isuru, >> >> I've used it in a mediation sequence where I use a POJO to generate a >> unique customer id given a couple of parameters and there's a checksum >> added to the end. I already had written this code and it was quite simple >> and straightforward to reuse it with a POJOCommand mediator. I feel the >> simplicity of it is a welcome feature, where reading and setting values in >> MessageContext is automatically handled for me. >> >> I don't know whether a single usage case is enough to make the case to >> keep it. However, if we decide to keep it though, I suggest that we improve >> the documentation on it. I had to dig around to find out how the what the >> different actions mean. It wasn't clear to me in the docs (I believe most >> of the content is carried forward from Syanpse). >> > > +1 for deprecating POJO Mediator. The problem I find with the above > approach is that - there is an alternative way of doing it (using class > mediators). Not having multiple options (to do the same thing) in a > configurational language makes it easier for development, maintenance, > training etc. An example will be - POJOMediator can use expressions where > Class mediators you can't (making things confusing). It's better to push > the point home saying - the way to write custom code in the ESB (if you > have to) is using a class mediator and the message context api. > > Apart from that - I believe in the POJO mediator we create multiple > objects in the heap? Where as in the class mediator we just create once > instance. Am I correct on this observation? > > I am -1 for deprecating Db mediators. Like Malaka said, they are very > useful in scenarios where people want to connect to databases (also can be > used in conjunction with cache mediator for performance). > > >> >> Thanks and Regards, >> >> Vidura >> >> >> >> On 10 December 2015 at 10:57, Isuru Udana wrote: >> >>> Hi Kathees, >>> >>> I think we should do a comparison once more to make sure that we have >>> covered everything before removing Callout. NTLM one which Harshana pointed >>> out may be due to absence of initClientOptions configuration option. >>> >>> Hi Vidura, >>> Point you raised on the POJOCommand mediator is really interesting. We >>> haven't seen any usage of that over years. But now we found at least one >>> user who has found it useful. Thanks for pointing that out. So we should >>> reconsider how useful it is. >>> >>> Thanks. >>> >>> >>> >>> On Thu, Dec 10, 2015 at 10:39 AM, Kathees Rajendram >>> wrote: >>> >>>> +1 to deprecate Callout mediator since we have the Callout mediator >>>> functionalities in Call mediator. >>>> >>>> On Thu, Dec 10, 2015 at 1:18 AM, Vidura Gamini Abhaya >>>> wrote: >>>> >>>>> I've found DBReport / DBLookup to be quite useful for simple DB >>>>> operations as they are easy to do OOTB. While DB Lookup mediator maybe >>>>> limited in it's ability to only being able to return a single row of data, >>>>> DB Report mediator is still quite useful in writing to a database, >>>>> especially when we use a DB as part of the mediation sequences. >>>>> >>>>> I also feel it is worth continuing with POJOCommand, as it is the most >>>>> simplest way of executing some custom code as part of a sequence. Although >>>>> it is possible to do the same with a Class mediator, one doesn't have to >>>>> worry about adding the proper jars, working with MessageContext etc. with >>>>> the POJOCommand. I think we should retain it for the sake of simplicity of >>>>> use. >>>>> >>>>> I'm +1 to deprecate the rest of the mediators. >>>>> >>>
Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10
On Wed, Dec 9, 2015 at 3:32 PM, Malaka Silva wrote: > +1 except DBReport/DBLookup mediators > > DBReport and DBLookup only offer a very limited set of capabilities. IMO, for any real integration scenario, we can't use them. :). > On Wed, Dec 9, 2015 at 2:00 PM, Yumani Ranaweera wrote: > >> Is it possible to provide sufficient documentation to help the customers >> who would be migrating in future. >> >> Thanks, >> Yumani >> >> >> On Wed, Dec 9, 2015 at 1:45 PM, Chanaka Fernando >> wrote: >> >>> *- Callout mediator :* >>> All the callout functionality is supported with 'call' mediator with >>> blocking=true. Having two similar mediators will be create a bit of a >>> confusion. >>> >>> It will make a lot of confusion when we have more than one mediators to >>> do the same thing. Therefore, better to deprecate this mediator. >>> >>> *- DBReport/DBLookup mediator* >>> These mediators offer very limited functionality and we always recommend >>> to integrate with databases with the use of DSS (using a separate DSS or >>> using DSS features inside ESB) >>> >>> Even though this mediator has been used by some customers, they are >>> using that for very limited functionality and we always suggest them to use >>> DSS as Kasun mentioned. If users really want to connect to a database, they >>> can easily write a simple class mediator. >>> >>> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active >>> development happens on these. >>> *- Router* : Same as filter mediator, so no use of having this. >>> *- In, Out * : Rarely used and often not required with the new >>> call/respond mediator approach. >>> >>> +1 for deprecating these mediators. >>> >>> With the new DAS integration, we can deprecate BAM mediator since we >>> have the PublishEvent mediator. >>> >>> On Wed, Dec 9, 2015 at 6:41 AM, Kasun Indrasiri wrote: >>> >>>> Shall we deprecate following mediators in 4.10 release. >>>> >>>> *- Callout mediator :* >>>> All the callout functionality is supported with 'call' mediator with >>>> blocking=true. Having two similar mediators will be create a bit of a >>>> confusion. >>>> >>>> *- DBReport/DBLookup mediator* >>>> These mediators offer very limited functionality and we always >>>> recommend to integrate with databases with the use of DSS (using a separate >>>> DSS or using DSS features inside ESB) >>>> >>>> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active >>>> development happens on these. >>>> *- Router* : Same as filter mediator, so no use of having this. >>>> *- In, Out * : Rarely used and often not required with the new >>>> call/respond mediator approach. >>>> >>>> Any comments on these or any other features that we should deprecate >>>> from 4.10 release? >>>> >>>> Thanks, >>>> Kasun. >>>> >>>> -- >>>> Kasun Indrasiri >>>> Software Architect >>>> WSO2, Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> cell: +94 77 556 5206 >>>> Blog : http://kasunpanorama.blogspot.com/ >>>> >>> >>> >>> >>> -- >>> Thank you and Best Regards, >>> Chanaka Fernando >>> Senior Technical Lead >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: +94 773337238 >>> Blog : http://soatutorials.blogspot.com >>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >>> Twitter:https://twitter.com/chanakaudaya >>> >>> >>> >>> >>> >>> ___ >>> Dev mailing list >>> d...@wso2.org >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> >> >> *Yumani Ranaweera* | Technical Lead >> Technical Support- Colombo >> WSO2 Inc. | http://wso2.com >> Blog: http://yumani.blogspot.com/ >> Mob: + 94 95242 >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > Best Regards, > > Malaka Silva > Senior Tech Lead > M: +94 777 219 791 > Tel : 94 11 214 5345 > Fax :94 11 2145300 > Skype : malaka.sampath.silva > LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 > Blog : http://mrmalakasilva.blogspot.com/ > > WSO2, Inc. > lean . enterprise . middleware > http://www.wso2.com/ > http://www.wso2.com/about/team/malaka-silva/ > <http://wso2.com/about/team/malaka-silva/> > https://store.wso2.com/store/ > > Save a tree -Conserve nature & Save the world for your future. Print this > email only if it is absolutely necessary. > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [ESB] Deprecated features in ESB 4.10
Shall we deprecate following mediators in 4.10 release. *- Callout mediator :* All the callout functionality is supported with 'call' mediator with blocking=true. Having two similar mediators will be create a bit of a confusion. *- DBReport/DBLookup mediator* These mediators offer very limited functionality and we always recommend to integrate with databases with the use of DSS (using a separate DSS or using DSS features inside ESB) *- Bean, POJOCommand, Spring* : Rarely used mediators and no active development happens on these. *- Router* : Same as filter mediator, so no use of having this. *- In, Out * : Rarely used and often not required with the new call/respond mediator approach. Any comments on these or any other features that we should deprecate from 4.10 release? Thanks, Kasun. -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Avoiding Access Token Expiration on ESB Connectors
On Fri, Dec 4, 2015 at 7:57 PM, Malaka Silva wrote: > Well IMO we don't need a new set of connectors to support esb 4.10. What > we need to do is enhance existing connector base. > I meant that we need new versions of connectors that are capable of supporting refresh tokens. But they will be compatible with 4.10 only. > > We are already planning to do this based on automation scnarios/use cases > (Starting with internal operations). > > The idea is to increase method coverage and include method as Kasun > mentions to fully automate the integration. > > On Fri, Dec 4, 2015 at 10:36 AM, Kasun Indrasiri wrote: > >> We need to get started with the new version of connectors (compatible >> with 4.10) that includes refresh token support for most commonly used >> connectors. Can we prioritize all such connectors and come up with a list >> please. They should be released along with 4.10. >> >> On Wed, Dec 2, 2015 at 10:51 AM, Malaka Silva wrote: >> >>> Resolved the jira. Check the functionality on pre release pack and seems >>> to be working. >>> >>> On Wed, Dec 2, 2015 at 10:14 AM, Kasun Indrasiri wrote: >>> >>>> I think all the required changes are already merged into ESB 4.10. If >>>> so can we resolve the jira? >>>> >>>> On Wed, Dec 2, 2015 at 9:45 AM, Rajjaz Mohammed >>>> wrote: >>>> >>>>> Hi Nadeeshan, >>>>> avoiding the access token expiration is really important feature for >>>>> connector's stability. i hope it will work with all kind of connectors >>>>> which are need access tokens not only with Google connectors. >>>>> >>>>> On Wed, Dec 2, 2015 at 9:23 AM, Malaka Silva wrote: >>>>> >>>>>> Yes this is a required feature for many use cases. I guess we have >>>>>> missed it from esb 490 release. >>>>>> >>>>>> Added jira[1] to track this for esb 4.10 release. >>>>>> >>>>>> [1] https://wso2.org/jira/browse/ESBJAVA-4346 >>>>>> >>>>>> On Tue, Dec 1, 2015 at 10:12 PM, Nadeeshaan Gunasinghe < >>>>>> nadeesh...@wso2.com> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> It has become a vital requirement to avoid access tokens being >>>>>>> expired which are used in the connectors. This issue can be avoided at >>>>>>> the >>>>>>> connector level, using the refresh tokens provided by the corresponding >>>>>>> api. In order to have this requirement fulfilled we wanted to use the >>>>>>> persistent property support in WSO2 ESB. Now we have included this >>>>>>> feature >>>>>>> in our latest repository [2], [3]. By implementing this capability of >>>>>>> avoiding the access token expiration on connectors it will improve the >>>>>>> connectors' stability also. >>>>>>> >>>>>>> By using this capability we have done some initial work, which can >>>>>>> be found at [1]. Also you can find details regarding the use of this >>>>>>> persistent property implementation under the mail thread with the >>>>>>> subject "*Persisting >>>>>>> content into registry from the mediation Layer". * >>>>>>> >>>>>>> Please share your thoughts >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> [1] https://github.com/wso2/esb-connectors/pull/144 >>>>>>> [2] https://github.com/wso2/wso2-synapse/pull/214 >>>>>>> [3] https://github.com/wso2/carbon-mediation/pull/198 >>>>>>> >>>>>>> Regards >>>>>>> *Nadeeshaan Gunasinghe* >>>>>>> Software Engineer, WSO2 Inc. http://wso2.com >>>>>>> +94770596754 | nadeesh...@wso2.com | Skype: nadeeshaan.gunasinghe >>>>>>> <#1516d63b9853a8c9_1516b62c59d5b80e_15161244130c85a9_1516101bf2c8c0f3_15160e80973e2006_15160d2fe9432b0d_1515e6cf2887f8f3_> >>>>>>> <http://www.facebook.com/nadeeshaan.gunasinghe> >>>>>>> <http://lk.linkedin.com/in/nadeeshaan> >>>>>>> <http://twitter.com/Nadeeshaan> <http://nadeeshaan.blogspot.com/> >>>>>>> Get a signature like this: Click here! >>>&
Re: [Architecture] Avoiding Access Token Expiration on ESB Connectors
We need to get started with the new version of connectors (compatible with 4.10) that includes refresh token support for most commonly used connectors. Can we prioritize all such connectors and come up with a list please. They should be released along with 4.10. On Wed, Dec 2, 2015 at 10:51 AM, Malaka Silva wrote: > Resolved the jira. Check the functionality on pre release pack and seems > to be working. > > On Wed, Dec 2, 2015 at 10:14 AM, Kasun Indrasiri wrote: > >> I think all the required changes are already merged into ESB 4.10. If so >> can we resolve the jira? >> >> On Wed, Dec 2, 2015 at 9:45 AM, Rajjaz Mohammed wrote: >> >>> Hi Nadeeshan, >>> avoiding the access token expiration is really important feature for >>> connector's stability. i hope it will work with all kind of connectors >>> which are need access tokens not only with Google connectors. >>> >>> On Wed, Dec 2, 2015 at 9:23 AM, Malaka Silva wrote: >>> >>>> Yes this is a required feature for many use cases. I guess we have >>>> missed it from esb 490 release. >>>> >>>> Added jira[1] to track this for esb 4.10 release. >>>> >>>> [1] https://wso2.org/jira/browse/ESBJAVA-4346 >>>> >>>> On Tue, Dec 1, 2015 at 10:12 PM, Nadeeshaan Gunasinghe < >>>> nadeesh...@wso2.com> wrote: >>>> >>>>> Hi all, >>>>> It has become a vital requirement to avoid access tokens being expired >>>>> which are used in the connectors. This issue can be avoided at the >>>>> connector level, using the refresh tokens provided by the corresponding >>>>> api. In order to have this requirement fulfilled we wanted to use the >>>>> persistent property support in WSO2 ESB. Now we have included this feature >>>>> in our latest repository [2], [3]. By implementing this capability of >>>>> avoiding the access token expiration on connectors it will improve the >>>>> connectors' stability also. >>>>> >>>>> By using this capability we have done some initial work, which can be >>>>> found at [1]. Also you can find details regarding the use of this >>>>> persistent property implementation under the mail thread with the subject >>>>> "*Persisting >>>>> content into registry from the mediation Layer". * >>>>> >>>>> Please share your thoughts >>>>> >>>>> Regards >>>>> >>>>> [1] https://github.com/wso2/esb-connectors/pull/144 >>>>> [2] https://github.com/wso2/wso2-synapse/pull/214 >>>>> [3] https://github.com/wso2/carbon-mediation/pull/198 >>>>> >>>>> Regards >>>>> *Nadeeshaan Gunasinghe* >>>>> Software Engineer, WSO2 Inc. http://wso2.com >>>>> +94770596754 | nadeesh...@wso2.com | Skype: nadeeshaan.gunasinghe >>>>> <#15161244130c85a9_1516101bf2c8c0f3_15160e80973e2006_15160d2fe9432b0d_1515e6cf2887f8f3_> >>>>> <http://www.facebook.com/nadeeshaan.gunasinghe> >>>>> <http://lk.linkedin.com/in/nadeeshaan> >>>>> <http://twitter.com/Nadeeshaan> <http://nadeeshaan.blogspot.com/> >>>>> Get a signature like this: Click here! >>>>> <http://ws-promos.appspot.com/r?rdata=eyJydXJsIjogImh0dHA6Ly93d3cud2lzZXN0YW1wLmNvbS9lbWFpbC1pbnN0YWxsP3dzX25jaWQ9NjcyMjk0MDA4JnV0bV9zb3VyY2U9ZXh0ZW5zaW9uJnV0bV9tZWRpdW09ZW1haWwmdXRtX2NhbXBhaWduPXByb21vXzU3MzI1Njg1NDg3Njk3OTIiLCAiZSI6ICI1NzMyNTY4NTQ4NzY5NzkyIn0=> >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Best Regards, >>>> >>>> Malaka Silva >>>> Senior Tech Lead >>>> M: +94 777 219 791 >>>> Tel : 94 11 214 5345 >>>> Fax :94 11 2145300 >>>> Skype : malaka.sampath.silva >>>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >>>> Blog : http://mrmalakasilva.blogspot.com/ >>>> >>>> WSO2, Inc. >>>> lean . enterprise . middleware >>>> http://www.wso2.com/ >>>> http://www.wso2.com/about/team/malaka-silva/ >>>> <http://wso2.com/about/team/malaka-silva/> >>>> https://store.wso2.com/store/ >>>> >>>> Save a tree -Conserve nature & Save the world for your future. Print >>>> this email only if it is absolutely necessary. >>>> >>>> _
Re: [Architecture] Ability to display data in a collapsible graph structure
Hi Dunith, I think one of the other requirement we have is to aggregate (i.e clone/aggregate scenario) the branches in some scenarios. For that we used dagre as an initial PoC. On Thu, Dec 3, 2015 at 8:23 PM, Dunith Dhanushka wrote: > Hi Kasun, > > I think the requirement here is to implement charts with the drill down > capability. > > We have a home grown JS library called VizGrammar[1] (previously known as > igviz.js) which is used to draw charts in DAS. VizGrammar is a wrapper > around d3.js and vega.js and it is capable of drawing a basic bar chart > with drill down support. Currently drill down support is limited only for > bar charts. > > Sample barchart with drilldown support can be found in sample [2] > > VizGrammar has implemented the drill down feature on top of d3.js and > extensible to support interactive visualizations. Library is still in its > early stages and we welcome any contributions to make it sharable across > platform to support interactive visualizations. > > [1] https://github.com/wso2/VizGrammar/ > [2] > https://github.com/wso2/VizGrammar/blob/master/samples/drillDown/index.html > > Thanks, > Dunith > > > > On Thu, Dec 3, 2015 at 6:49 PM, Kasun Indrasiri wrote: > >> Are we planning to support this at framework/DAS level itself. I think >> this will be a common requirement for ESB, CEP and BPS etc. So, we better >> have a common library that caters these requirements. >> >> On Wed, Dec 2, 2015 at 7:01 PM, Viraj Senevirathne >> wrote: >> >>> Hi All, >>> >>> Currently we are working on a new statistic and message tracing features >>> for ESB 4.10.0 release. In both projects we are displaying collected data >>> in a graph structure in the UI. Requirements for the graph library is given >>> below. >>> >>>1. At the start it should only display parent node >>>2. By clicking on a graph node, user can toggle its immediate >>>children. >>>3. The user should be able to see more information about that node >>>such as request count,max time etc. >>> >>> After searching for a suitable graph library we found out following >>> >>>1. Most of the graph data visualizations are done using D3 java >>>script library [1] >>>2. In DAS we are using VizGrammer [2] java script library which is a >>>wrapper written on top of the D3 library. But it doesn't seem to have >>> graph >>>drawing ability yet. >>>3. Dagre java script library [3] can draw directed graphs but these >>>are static digraphs. It also wraps D3 JavaScript library. >>> >>> Currently for both Statistic and Tracing projects we are using Dagre >>> library. Statistic tree [4] generated for proxy configuration [5] and >>> tracing of a message flow can be found in [6]. >>> >>> But the main problem of using this library is that graph is a static one >>> and users cannot interact with it. For example I have written a dynamic >>> tree structure using D3 in [7]. User can use click and double click events >>> to interact with the tree. But since this is tree structure we cannot use >>> it for our requirement. (i.e. in clone and aggregate mediators there are >>> parallel flows which combines at the end). >>> >>> Is there a different way to implement this feature? Can we support this >>> type of dynamic graphs using any of our internal library without using >>> external libraries? >>> >>> [1] http://d3js.org/ >>> >>> [2] https://github.com/wso2/VizGrammar >>> >>> [3] https://github.com/cpettitt/dagre >>> >>> [4] >>> https://drive.google.com/a/wso2.com/file/d/0Byt7F9S8tb-DaU1BeFlxNnJQNkU/view?usp=sharing >>> >>> [5] >>> https://drive.google.com/a/wso2.com/file/d/0Byt7F9S8tb-DWnNDZk5xZGtTRHc/view?usp=sharing >>> >>> [6] >>> https://drive.google.com/a/wso2.com/file/d/0Byt7F9S8tb-DRlFKa2FpMG5fd00/view?usp=sharing >>> >>> [7] http://jsfiddle.net/virajsen/pofy6c7t/embedded/result/ >>> >>> Thank you, >>> >>> -- >>> Viraj Senevirathne >>> Software Engineer; WSO2, Inc. >>> >>> Mobile : +94 71 958 0269 >>> Email : vir...@wso2.com >>> >> >> >> >> -- >> Kasun Indrasiri >> Software Architect >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> cell: +94 77 556 5206 >> Blog : http://kasunpanorama.blogspot.com/ >> > > > > -- > Regards, > > Dunith Dhanushka, > Senior Software Engineer > WSO2 Inc, > > Mobile - +94 71 8615744 > Blog - dunithd.wordpress.com <http://blog.dunith.com> > Twitter - @dunithd <http://twitter.com/dunithd> > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Ability to display data in a collapsible graph structure
Are we planning to support this at framework/DAS level itself. I think this will be a common requirement for ESB, CEP and BPS etc. So, we better have a common library that caters these requirements. On Wed, Dec 2, 2015 at 7:01 PM, Viraj Senevirathne wrote: > Hi All, > > Currently we are working on a new statistic and message tracing features > for ESB 4.10.0 release. In both projects we are displaying collected data > in a graph structure in the UI. Requirements for the graph library is given > below. > >1. At the start it should only display parent node >2. By clicking on a graph node, user can toggle its immediate children. >3. The user should be able to see more information about that node >such as request count,max time etc. > > After searching for a suitable graph library we found out following > >1. Most of the graph data visualizations are done using D3 java script >library [1] >2. In DAS we are using VizGrammer [2] java script library which is a >wrapper written on top of the D3 library. But it doesn't seem to have graph >drawing ability yet. >3. Dagre java script library [3] can draw directed graphs but these >are static digraphs. It also wraps D3 JavaScript library. > > Currently for both Statistic and Tracing projects we are using Dagre > library. Statistic tree [4] generated for proxy configuration [5] and > tracing of a message flow can be found in [6]. > > But the main problem of using this library is that graph is a static one > and users cannot interact with it. For example I have written a dynamic > tree structure using D3 in [7]. User can use click and double click events > to interact with the tree. But since this is tree structure we cannot use > it for our requirement. (i.e. in clone and aggregate mediators there are > parallel flows which combines at the end). > > Is there a different way to implement this feature? Can we support this > type of dynamic graphs using any of our internal library without using > external libraries? > > [1] http://d3js.org/ > > [2] https://github.com/wso2/VizGrammar > > [3] https://github.com/cpettitt/dagre > > [4] > https://drive.google.com/a/wso2.com/file/d/0Byt7F9S8tb-DaU1BeFlxNnJQNkU/view?usp=sharing > > [5] > https://drive.google.com/a/wso2.com/file/d/0Byt7F9S8tb-DWnNDZk5xZGtTRHc/view?usp=sharing > > [6] > https://drive.google.com/a/wso2.com/file/d/0Byt7F9S8tb-DRlFKa2FpMG5fd00/view?usp=sharing > > [7] http://jsfiddle.net/virajsen/pofy6c7t/embedded/result/ > > Thank you, > > -- > Viraj Senevirathne > Software Engineer; WSO2, Inc. > > Mobile : +94 71 958 0269 > Email : vir...@wso2.com > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Avoiding Access Token Expiration on ESB Connectors
I think all the required changes are already merged into ESB 4.10. If so can we resolve the jira? On Wed, Dec 2, 2015 at 9:45 AM, Rajjaz Mohammed wrote: > Hi Nadeeshan, > avoiding the access token expiration is really important feature for > connector's stability. i hope it will work with all kind of connectors > which are need access tokens not only with Google connectors. > > On Wed, Dec 2, 2015 at 9:23 AM, Malaka Silva wrote: > >> Yes this is a required feature for many use cases. I guess we have missed >> it from esb 490 release. >> >> Added jira[1] to track this for esb 4.10 release. >> >> [1] https://wso2.org/jira/browse/ESBJAVA-4346 >> >> On Tue, Dec 1, 2015 at 10:12 PM, Nadeeshaan Gunasinghe < >> nadeesh...@wso2.com> wrote: >> >>> Hi all, >>> It has become a vital requirement to avoid access tokens being expired >>> which are used in the connectors. This issue can be avoided at the >>> connector level, using the refresh tokens provided by the corresponding >>> api. In order to have this requirement fulfilled we wanted to use the >>> persistent property support in WSO2 ESB. Now we have included this feature >>> in our latest repository [2], [3]. By implementing this capability of >>> avoiding the access token expiration on connectors it will improve the >>> connectors' stability also. >>> >>> By using this capability we have done some initial work, which can be >>> found at [1]. Also you can find details regarding the use of this >>> persistent property implementation under the mail thread with the subject >>> "*Persisting >>> content into registry from the mediation Layer". * >>> >>> Please share your thoughts >>> >>> Regards >>> >>> [1] https://github.com/wso2/esb-connectors/pull/144 >>> [2] https://github.com/wso2/wso2-synapse/pull/214 >>> [3] https://github.com/wso2/carbon-mediation/pull/198 >>> >>> Regards >>> *Nadeeshaan Gunasinghe* >>> Software Engineer, WSO2 Inc. http://wso2.com >>> +94770596754 | nadeesh...@wso2.com | Skype: nadeeshaan.gunasinghe >>> <#15160e80973e2006_15160d2fe9432b0d_1515e6cf2887f8f3_> >>> <http://www.facebook.com/nadeeshaan.gunasinghe> >>> <http://lk.linkedin.com/in/nadeeshaan> <http://twitter.com/Nadeeshaan> >>> <http://nadeeshaan.blogspot.com/> >>> Get a signature like this: Click here! >>> <http://ws-promos.appspot.com/r?rdata=eyJydXJsIjogImh0dHA6Ly93d3cud2lzZXN0YW1wLmNvbS9lbWFpbC1pbnN0YWxsP3dzX25jaWQ9NjcyMjk0MDA4JnV0bV9zb3VyY2U9ZXh0ZW5zaW9uJnV0bV9tZWRpdW09ZW1haWwmdXRtX2NhbXBhaWduPXByb21vXzU3MzI1Njg1NDg3Njk3OTIiLCAiZSI6ICI1NzMyNTY4NTQ4NzY5NzkyIn0=> >>> >> >> >> >> -- >> >> Best Regards, >> >> Malaka Silva >> Senior Tech Lead >> M: +94 777 219 791 >> Tel : 94 11 214 5345 >> Fax :94 11 2145300 >> Skype : malaka.sampath.silva >> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >> Blog : http://mrmalakasilva.blogspot.com/ >> >> WSO2, Inc. >> lean . enterprise . middleware >> http://www.wso2.com/ >> http://www.wso2.com/about/team/malaka-silva/ >> <http://wso2.com/about/team/malaka-silva/> >> https://store.wso2.com/store/ >> >> Save a tree -Conserve nature & Save the world for your future. Print this >> email only if it is absolutely necessary. >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thank you > Best Regards > > *Rajjaz HM* > Associate Software Engineer > WSO2 Inc. <http://wso2.com/> > lean | enterprise | middleware > Mobile | +94752833834 > Email | raj...@wso2.com > LinkedIn | Blogger | WSO2 Profile > <http://wso2.com/about/team/mohammer_rajjaz/> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB 4.10 - Revamping mediation statistics and message tracing
Isn't Stats and tracing are two independent tasks? On Wed, Nov 11, 2015 at 9:55 AM, Viraj Senevirathne wrote: > Hi All, > > In a clustered environment should we collect statistics of worker nodes > separately or should we represent them together as a one cluster? > > We probably need both. Once aggregated view and per node view for each worker node. WDYT? > > > On Wed, Nov 11, 2015 at 9:53 AM, Jagath Sisirakumara Ariyarathne < > jaga...@wso2.com> wrote: > >> Hi Inosh, >> >> Will there be two UI configuration sections for above? Both mediation >> stats and message tracing require same set of configurations like, DAS >> receiver URL and user credentials. Wouldn't it be better if we let the user >> to configure this information in single place? >> >> Yes, we can use same window for those. However, I think we will require >> two separate configurations for stat and tracing. >> >> WDYT? >> >> On Wed, Nov 11, 2015 at 12:06 AM, Inosh Goonewardena >> wrote: >> >>> Hi Viraj, >>> >>> On Mon, Nov 9, 2015 at 3:45 PM, Viraj Senevirathne >>> wrote: >>> >>>> Hi All, >>>> >>>> We are planning to removing following features as we are introducing >>>> new improved features that enhance and extend the existing functionality. >>>> >>>> ESB 4.10.0 release will not have following sections in the management >>>> console UI. >>>> >>>> *Monitoring Section* >>>> >>>>- Mediation Statistics >>>>- SOAP Tracer >>>>- Mediation Tracer >>>>- Message Flows >>>> >>>> *Configure Section * >>>> >>>>- Mediation Data Publishing >>>>- BAM Server Profile >>>> >>>> >>>> ESB 4.10.0 release will contain following additions to management >>>> console. >>>> >>>> *Configure Section* >>>> >>>>- Mediation Statistics Publishing Configuration >>>>- Tracing Data Publishing Configuration >>>> >>>> Will there be two UI configuration sections for above? Both mediation >>> stats and message tracing require same set of configurations like, DAS >>> receiver URL and user credentials. Wouldn't it be better if we let the user >>> to configure this information in single place? >>> >>>> >>>>- >>>> >>>> ESB will publish tracing and statistic data to the DAS and users can >>>> monitor mediation statistics and message tracing results from DAS >>>> dashboard. >>>> >>>> Thank you, >>>> >>>> On Mon, Nov 9, 2015 at 3:15 PM, Kasun Indrasiri wrote: >>>> >>>>> Hi, >>>>> >>>>> As part of the ongoing efforts for revamping mediation statistics and >>>>> message tracing in ESB, we have to get rid of most of the existing UIs and >>>>> configurations in the ESB management console. >>>>> >>>>> Jagath/Viraj : Can you please list down the areas that we gonna remove >>>>> from ESB 4.10 and the new additions to support tracing and stats. >>>>> >>>>> Thanks, >>>>> Kasun. >>>>> -- >>>>> Kasun Indrasiri >>>>> Software Architect >>>>> WSO2, Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> cell: +94 77 556 5206 >>>>> Blog : http://kasunpanorama.blogspot.com/ >>>>> >>>> >>>> >>>> >>>> -- >>>> Viraj Senevirathne >>>> Software Engineer; WSO2, Inc. >>>> >>>> Mobile : +94 71 958 0269 >>>> Email : vir...@wso2.com >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> >>> Inosh Goonewardena >>> Associate Technical Lead- WSO2 Inc. >>> Mobile: +94779966317 >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Jagath Ariyarathne >> Technical Lead >> WSO2 Inc. http://wso2.com/ >> Email: jaga...@wso2.com >> Mob : +94 77 386 7048 >> >> > > > -- > Viraj Senevirathne > Software Engineer; WSO2, Inc. > > Mobile : +94 71 958 0269 > Email : vir...@wso2.com > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB 4.10 - New extension point for busy-waiting custom inbounds
> >>>>> https://store.wso2.com/store/ >>>>> >>>>> Save a tree -Conserve nature & Save the world for your future. Print >>>>> this email only if it is absolutely necessary. >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Best Regards, >>>> >>>> Malaka Silva >>>> Senior Tech Lead >>>> M: +94 777 219 791 >>>> Tel : 94 11 214 5345 >>>> Fax :94 11 2145300 >>>> Skype : malaka.sampath.silva >>>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >>>> Blog : http://mrmalakasilva.blogspot.com/ >>>> >>>> WSO2, Inc. >>>> lean . enterprise . middleware >>>> http://www.wso2.com/ >>>> http://www.wso2.com/about/team/malaka-silva/ >>>> <http://wso2.com/about/team/malaka-silva/> >>>> https://store.wso2.com/store/ >>>> >>>> Save a tree -Conserve nature & Save the world for your future. Print >>>> this email only if it is absolutely necessary. >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> -- >>> Chanaka Fernando >>> Senior Technical Lead >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: +94 773337238 >>> Blog : http://soatutorials.blogspot.com >>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >>> Twitter:https://twitter.com/chanakaudaya >>> >>> >>> >>> >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Best Regards, >> >> Malaka Silva >> Senior Tech Lead >> M: +94 777 219 791 >> Tel : 94 11 214 5345 >> Fax :94 11 2145300 >> Skype : malaka.sampath.silva >> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >> Blog : http://mrmalakasilva.blogspot.com/ >> >> WSO2, Inc. >> lean . enterprise . middleware >> http://www.wso2.com/ >> http://www.wso2.com/about/team/malaka-silva/ >> <http://wso2.com/about/team/malaka-silva/> >> https://store.wso2.com/store/ >> >> Save a tree -Conserve nature & Save the world for your future. Print this >> email only if it is absolutely necessary. >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thank you and Best Regards, > Chanaka Fernando > Senior Technical Lead > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 773337238 > Blog : http://soatutorials.blogspot.com > LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 > Twitter:https://twitter.com/chanakaudaya > > > > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] ESB 4.10 - Revamping mediation statistics and message tracing
Hi, As part of the ongoing efforts for revamping mediation statistics and message tracing in ESB, we have to get rid of most of the existing UIs and configurations in the ESB management console. Jagath/Viraj : Can you please list down the areas that we gonna remove from ESB 4.10 and the new additions to support tracing and stats. Thanks, Kasun. -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Fwd: ESB Mediation Debugger Tool for Developer Studio
Hi Nuwan,
Can we do another review sometime this week?
@Kevin : Do we have all the required changes available in the current
version of the ESB pack?
On Fri, Oct 16, 2015 at 3:45 PM, Nuwan Pallewela wrote:
> Hi All,
>
> Following are the key notes taken down in the ESB Debugger Demonstration
> with ESB Team.
>
>
> *Developer Studio Debugger Implementation*
>
>- Implement missing features-(API , Connector)
>- Call Capp admin service from Developer studio to get Capp deployment
>status.
>- Variable names should change for more user friendly names and they
>should list in a more hierarchical structure.
>[Properties->{scope1->(var1),(var2)...},{scope2->(var1),(var2)...},...]
>- Include both ip and port for connection between Developer Studio and
>ESB Server
>
>
>
> *ESB Debugger Implementation*
>
>- Merge Debugger PR for next ESB release
>- Implement other missing features and improvements
>
> *Time lines*
>
>- Working debugger feature should be add to developer studio in mid
>November 2015
>
> Thanks,
>
> Nuwan
>
> On Wed, Oct 14, 2015 at 10:09 AM, Chamara Ariyarathne
> wrote:
>
>> I would also like to join. Please send me the invitation.
>>
>> On Wed, Oct 14, 2015 at 9:55 AM, Nuwan Pallewela wrote:
>>
>>> Hi Kasun,
>>>
>>> Sure. I'll arrange it in this week.
>>>
>>> Thanks,
>>> Nuwan
>>> --
>>> --
>>>
>>> *Nuwan Chamara Pallewela*
>>>
>>>
>>> *Software Engineer*
>>>
>>> *WSO2, Inc. *http://wso2.com
>>> *lean . enterprise . middleware*
>>>
>>> Email *nuw...@wso2.com *
>>> Mobile *+94719079739 <%2B94719079739>@*
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Chamara Ariyarathne*
>> Associate Technical Lead - QA
>> WSO2 Inc; http://www.wso2.com/
>> Mobile; *+94772786766 <%2B94772786766>*
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> --
>
> *Nuwan Chamara Pallewela*
>
>
> *Software Engineer*
>
> *WSO2, Inc. *http://wso2.com
> *lean . enterprise . middleware*
>
> Email *nuw...@wso2.com *
> Mobile *+94719079739 <%2B94719079739>@*
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Kasun Indrasiri
Software Architect
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware
cell: +94 77 556 5206
Blog : http://kasunpanorama.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Need to do a 1.0 release of Carbon-transports
+1. On Mon, Oct 26, 2015 at 6:42 PM, Kishanthan Thangarajah wrote: > We need the carbon-startup coordinator integrated with transports project. > I'm integrating and testing it now. We can merge it, test it and release it. > > On Mon, Oct 26, 2015 at 6:07 PM, Afkham Azeez wrote: > >> This is needed for the GW & MSS releases. Carbon transport currently only >> contains the Netty transport & it seems to be stable and no fixes or >> features have gone into it recently. >> >> So I think we can do a 1.0 release. >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>* >> *email: **az...@wso2.com* >> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >> *http://blog.afkham.org* <http://blog.afkham.org> >> *twitter: **http://twitter.com/afkham_azeez* >> <http://twitter.com/afkham_azeez> >> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >> <http://lk.linkedin.com/in/afkhamazeez>* >> >> *Lean . Enterprise . Middleware* >> > > > > -- > *Kishanthan Thangarajah* > Associate Technical Lead, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* > Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [AF] Adding ESB Applications to App Factory
Hi, Not having 4.9 in the ESB as a service will be a huge drawback.. IMO. There are quite a lot of changes that we specifically did for 4.9 to fix the behavior in MT mode etc. (inbound EP, tasks coordination etc.). So, I don't think going back to 4.8.1 is the best option we have. Anyway, iPaaS work also needs ESB 4.9, so going back to 4.8.1 won't work for iPaaS. thanks, Kasun On Thu, Oct 1, 2015 at 10:04 AM, Manjula Rathnayake wrote: > Hi all, > > I am +1 for #1 due to the simplicity we get in cloud deployment. > > @Nadeeshaan, can we get the car based logging improvement to ESB 4.8.1? > > thank you. > > On Wed, Sep 30, 2015 at 5:32 PM, Danushka Fernando > wrote: > >> Hi All, >> >> I am working on adding ESB Application to App Factory. Currently all >> application type related code is developed and sample code also done. While >> looking into adding ESB container faced an issue. >> >> Currently AF dev setups and App Cloud deployed all the products which are >> based on Carbon 4.2.0. But ESB 4.9.0 contains a feature to add log >> filtering based on Capp names. But AFAIK ESB 4.9.0 is based on carbon >> 4.4.x. So we cannot mount existing databases to ESB 4.9.0. >> >> >> So the possible solutions are as below. >> >> >> >>1. >> >>Go with ESB 4.8.1 for now. (Later we need to upgrade all the products >>to 4.4.x kernel) Backport the fix for logging to 4.8.1 if possible. (@ESB >>team is this possible?) >>2. >> >>Deploy ESB 4.9.0 with new database schemas and when we create tenants >>we will need to create tenants in ESB as well and also when we create >>resources we need to replicate them in ESB as well. >>3. >> >>Add ESB similar to a single tenant cartridge (ESB per version) and >>point it to databases created from 4.4.x database schemas. These databases >>will be per container. Issues with this are we need to replicate the >>resources we create in ESB containers and if container get killed we will >>lose the data. And implementation will be much more complex. >> >> >> I am +1 for the Solution #1 since later in the day we need to upgrade all >> products and it’s less complex in deployment. And also in the worst case if >> we can’t patch with the logging feature then log download function won’t be >> available immediately to ESB application types. >> >> Thanks & Regards >> Danushka Fernando >> Senior Software Engineer >> WSO2 inc. http://wso2.com/ >> Mobile : +94716332729 >> > > > > -- > Manjula Rathnayaka > Associate Technical Lead > WSO2, Inc. > Mobile:+94 77 743 1987 > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Connector versioning
Hi, I think we need to rethink the connector versioning approach. As we have many connectors in the connector store, we should cater the needs to using two different version of the same connector in the same ESB runtime. Any thoughts? -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Retrying faulty CApps
Hi, Is it possible to add this as a new feature at carbon level? I think when a CApp deployment initially fails due to intermittent resources/databases unavailability etc., it may be required to have a re-try mechanism for re-deploying artifacts without user intervention. Thanks. -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Possible issue with the new GW implementation
They recommend not to block the EventLoop thread under any circumstances [1]. So, the application level logic (mediation/services) needs to be handled from a separate thread pool. [1] http://normanmaurer.me/presentations/2014-facebook-eng-netty/slides.html#23.0 On Thu, Jul 30, 2015 at 11:42 PM, Isuru Ranawaka wrote: > Hi all, > > I think there are two aspects, handling connections and handling requests > coming through connections. Basically what happens is Threads in BossGroup > accepts the incoming connections and after accepting it. It creates a > channel pipelines for each connection and handover accepted connections to > handle by netty worker threads. > So here after IO operations are handle by worker threads. each worker is > responsible for handling its pipeline. Requests are coming through that > pipe line and through netty handlers we can access those requests . If we > use same Netty worker IO thread for handle requests then if one requests > takes long processing time then following requests also affected from that > which applies back pressure on IO Threads. So I think we need to handle > incoming requests from separate threads to run netty worker threads > smoothly. For Netty 4 on wards they have mentioned that we can share same > worker pool for boss and worker groups as well. > > thanks > IsuruR > > > On Thu, Jul 30, 2015 at 4:14 AM, Ravi Undupitiya wrote: > >> Netty 5.x is still in alpha and 4.x is current stable. >> >> On Thu, Jul 30, 2015 at 2:32 PM, Afkham Azeez wrote: >> >>> Shouldn't we be using Netty 5? >>> >>> On Thu, Jul 30, 2015 at 2:26 PM, Ravi Undupitiya wrote: >>> >>>> Hi Azeez, >>>> >>>> The reason for using a worker for executing engine tasks is to avoid >>>> using an I/O thread to do the same. AFAIU the pipeline is executed from an >>>> I/O thread. However, we might be able to share the existing netty worker >>>> pool [1] and place our worker in it. We'll update the code to use this. >>>> >>>> >>>> [1] >>>> http://netty.io/4.0/api/io/netty/channel/ChannelHandlerContext.html#executor() >>>> >>>> >>>> Thanks, >>>> Ravi >>>> >>>> On Thu, Jul 30, 2015 at 10:02 AM, Afkham Azeez wrote: >>>> >>>>> I was going through the code, and in addition to the Netty boss & >>>>> worker pools, we have our own worker pool. Why is that? Looks like a >>>>> remnant from the old PT architecture but do we really need that? >>>>> >>>>> Regards >>>>> Azeez >>>>> >>>>> -- >>>>> *Afkham Azeez* >>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>> * <http://www.apache.org/>* >>>>> *email: **az...@wso2.com* >>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>> <http://twitter.com/afkham_azeez> >>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>> >>>>> *Lean . Enterprise . Middleware* >>>>> >>>> >>>> >>>> >>>> -- >>>> *Ravi Undupitiya* >>>> Senior Software Engineer; WSO2 http://wso2.com >>>> >>>> >>>> *E-mail: r...@wso2.com <http://wso2.com>**M: **+94 772 930 712 >>>> <%2B94%C2%A0772%20930%20712>* >>>> >>>> Lean . Enterprise . Middleware >>>> >>> >>> >>> >>> -- >>> *Afkham Azeez* >>> Director of Architecture; WSO2, Inc.; http://wso2.com >>> Member; Apache Software Foundation; http://www.apache.org/ >>> * <http://www.apache.org/>* >>> *email: **az...@wso2.com* >>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>> *http://blog.afkham.org* <http://blog.afkham.org> >>> *twitter: **http://twitter.com/afkham_azeez* >>> <http://twitter.com/afkham_azeez> >>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>> <http://lk.linkedin.com/in/afkhamazeez>* >>> >>> *Lean . Enterprise . Middleware* >>> >> >> >> >> -- >> *Ravi Undupitiya* >> Senior Software Engineer; WSO2 http://wso2.com >> >> >> *E-mail: r...@wso2.com <http://wso2.com>**M: **+94 772 930 712 >> <%2B94%C2%A0772%20930%20712>* >> >> Lean . Enterprise . Middleware >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Best Regards > Isuru Ranawaka > M: +94714629880 > Blog : http://isurur.blogspot.com/ > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] P2 Repository for Carbon 4.4.X based products
Do we have the doc available now? We need to test the ESB with p2-repo before the beta release. @Malaka : Can you please work with the kernel team to get this done. On Fri, Jul 17, 2015 at 4:55 PM, Niranjan Karunanandham wrote: > Hi Chanaka, > > For the p2 repo, we already have the carbon-feature-repository [1], which > will have all the features in the main pom.xml. We had a review [2] with > regard to this and during the review it was suggested whether we need to > have the nested-categories within the product or should it be platform-wise > and be mentioned in the carbon-feature-repository. Sample of the above to > are available in [3] and [4]. I will be sending an invite with regard to > this on Tuesday to all the product leads to discuss finalize whether we are > going to have the nested-categories within the product or should it be > platform-wise and mentioned in carbon-feature-repository. > > [1] - https://github.com/wso2/carbon-feature-repository > [2] - Invitation: Discussion on Categories in AS and Feature Categories @ > Thu Jun 4, 2015 11am - 12pm (niran...@wso2.com) > [3] - https://github.com/Niranjan-K/carbon-feature-repository > [4] - https://github.com/Niranjan-K/carbon-feature-repository > /tree/nested-categories > > Regards, > Nira > > > On Fri, Jul 17, 2015 at 2:57 PM, Chanaka Fernando > wrote: > >> Hi All, >> >> Since we have not released a single product with Carbon 4.4.X version, we >> need to think about creating a P2 repository for the products which are >> going to be released with the same carbon version. What should be the >> methodology to create a P2 repository for ESB 4.9.0 version which is based >> on the carbon 4.4.X? >> >> >> Thanks, >> Chanaka >> >> -- >> -- >> Chanaka Fernando >> Senior Technical Lead >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 773337238 >> Blog : http://soatutorials.blogspot.com >> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >> Twitter:https://twitter.com/chanakaudaya >> Wordpress:http://chanakaudaya.wordpress.com >> >> >> >> >> _______ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > *Niranjan Karunanandham* > Senior Software Engineer - WSO2 Inc. > WSO2 Inc.: http://www.wso2.com > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [GSoC] WSO2 ESB - Netty Transport Enhancements
What's the current status of the project? There are no updates for weeks :(. On Tue, Jul 7, 2015 at 4:39 PM, Kasun Indrasiri wrote: > Hi Achintha, > > As we are behind the schedule, we need to complete the end to end message > flow for content aware scenarios. We expect you to finish this by end of > this week. If not we won't be able to cover the proposed scope for this > project. > > On Fri, Jun 26, 2015 at 9:35 PM, Achintha Reemal > wrote: > >> Hi >> >> After meeting with Isuru Ranawaka on 25th June, we discussed on the >> following proceedings for the coming week. >> >> - Implement means to read from the queue(while allowing write >> operations), which is being currently implemented for the content-non aware >> scenario. >> - Identify means to extract HttpContent once converted into an input >> stream, to be fed to mediation. >> - Debug and identify the message building implementation, which would >> build the message for content aware scenarios. >> - Validate the message flow for content aware scenario. >> >> Regards, >> >> On Fri, Jun 12, 2015 at 9:05 AM, Achintha Reemal >> wrote: >> >>> Hi, >>> >>> After meeting with Isuru on 11th June, we discussed on the following >>> proceedings for the coming week. >>> >>> - Further look into the current implementation with respect to the >>> adaptation for with chunking and without chunking in HTTP Content >>> - Debug and identify the message flow within the current implementation. >>> - Identify how chunked content are being held in the current >>> implementation. >>> - Research on means to write the chunked content to the current Pipe >>> implementation as an input stream, which would enable the content aware >>> scenario. >>> - Try to implement the above task by 18th June. >>> >>> Regards, >>> >>> On Sun, May 24, 2015 at 3:00 PM, Achintha Reemal >>> wrote: >>> >>>> Hi, >>>> >>>> During the week, I have looked into the following aspects of the project >>>> >>>> - Observed the current implementation of Netty-PassThru transport >>>> provided by, and special attention was given to the current Pipe >>>> implementation as instructed by Isuru. Further observation was done to >>>> identify Netty specific parts in the implementation (like the use of >>>> classes like ChannelInboundHandlerAdapter, ChannelHandlerContext etc.) >>>> >>>> - Identifying the usage of different Encoders / Decoders in netty. >>>> >>>> - Getting to know the current layout of WSO2 ESB transport layer and >>>> Mediation Layer, in order to identify the correlation of these two layers, >>>> which would be required when decoupling them. >>>> >>>> Regards, >>>> -- >>>> *G.H.Achintha Reemal* >>>> *BSc Eng Undergraduate| Department of Computer Science & Engineering | >>>> University of Moratuwa* >>>> *Intern Software Engineer**| WSO2 Lanka (Pvt) Ltd.* >>>> *Blog|** rimmythepaperclip.blogspot.com >>>> <http://rimmythepaperclip.blogspot.com>* >>>> *Twitter|* @rimmynuts(A.Reemal) >>>> *LinkedIn|* lk.linkedin.com/in/achinthareemal/ >>>> *Mobile| *0715471301 >>>> >>> >>> >>> >>> -- >>> *G.H.Achintha Reemal* >>> *BSc Eng Undergraduate| Department of Computer Science & Engineering | >>> University of Moratuwa* >>> *Intern Software Engineer**| WSO2 Lanka (Pvt) Ltd.* >>> *Blog|** rimmythepaperclip.blogspot.com >>> <http://rimmythepaperclip.blogspot.com>* >>> *Twitter|* @rimmynuts(A.Reemal) >>> *LinkedIn|* lk.linkedin.com/in/achinthareemal/ >>> *Mobile| *0715471301 >>> >> >> >> >> -- >> *G.H.Achintha Reemal* >> *BSc Eng Undergraduate| Department of Computer Science & Engineering | >> University of Moratuwa* >> *Intern Software Engineer**| WSO2 Lanka (Pvt) Ltd.* >> *Blog|** rimmythepaperclip.blogspot.com >> <http://rimmythepaperclip.blogspot.com>* >> *Twitter|* @rimmynuts(A.Reemal) >> *LinkedIn|* lk.linkedin.com/in/achinthareemal/ >> *Mobile| *0715471301 >> > > > > -- > Kasun Indrasiri > Software Architect > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +94 77 556 5206 > Blog : http://kasunpanorama.blogspot.com/ > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [GSoC] ESB - End-to-end Message Tracing Support
Hi Chanka, Can you please provide a status update on the project? On Tue, Jun 30, 2015 at 1:06 PM, Chanaka Sampath Cooray < chanakasampat...@gmail.com> wrote: > Hi Kasun, > > Added to the doc. > > Thanks, > > On Tue, Jun 30, 2015 at 12:44 PM, Kasun Indrasiri wrote: > >> Hi Chanaka, >> >> I think we have agreed on adding call/respond mediator based samples too. >> Can you include use cases including those mediators too. >> >> On Tue, Jun 30, 2015 at 12:31 PM, Chanaka Sampath Cooray < >> chanakasampat...@gmail.com> wrote: >> >>> Hi, >>> >>> Here is the progress so far. >>> >>> According to the last discussion, I stored the flow in the message >>> context and persist that when the flow is finished. And also I have created >>> a separate thread to persist the data asynchronously to the database. To >>> identify each mediator, I have added an id for each mediator. >>> >>> I am using two tables, one for store the message flow and other one to >>> store the mediator details. When building the message flow, I am using a >>> separate data structure in which one node maps to another node set. In that >>> way, I can store the message flows when the message is cloning, iterating >>> and etc. I have explained the data structure using an example in [1]. And >>> the current implementations are in the repository [2] and [3]. >>> >>> [1]. >>> https://docs.google.com/document/d/1k0vrAbzQZyD7PDSHyKntEmqoflyH-iSjC_eo9gAxdoM/edit?usp=sharing >>> [2]. >>> https://github.com/ChanakaCooray/carbon-mediation/tree/MessageFlowTrace >>> [3]. https://github.com/ChanakaCooray/wso2-synapse/tree/MessageFlowTrace >>> >>> Thanks, >>> >>> On Thu, Jun 18, 2015 at 10:11 PM, Isuru Udana wrote: >>> >>>> Hi Cryril, >>>> >>>> Thanks for the idea. >>>> >>>> Message context is the entity which flows through the mediation flow >>>> (both request/response path). We thought of saving trace details in the >>>> message context itself will ease the correlation. However we cannot save >>>> all the information in the message context, as it will increase the memory >>>> usage. >>>> Information like message payload, property values can be written to the >>>> db in an asynchronous manner (not blocking the mediation flow) and we can >>>> keep a reference to those db entries in the message context. >>>> >>>> We need to decide on a suitable data structure (probably a stack) which >>>> can hold these information. >>>> >>>> When we have flow branching mediators like Filter, Clone, we may need a >>>> parent message id to correlate as well. >>>> >>>> Now the challenge is to decide a suitable data structure to hold these >>>> trace information in the message context. >>>> >>>> Thanks. >>>> >>>> >>>> >>>> On Thu, Jun 18, 2015 at 1:54 PM, Cyril Rognon >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> would it be too expensive or difficult to have a parent Message id if >>>>> the original Message id is to be changed ? This would allow us to >>>>> correlate >>>>> flows later. >>>>> >>>>> thanks, >>>>> Cyril >>>>> >>>>> On Wed, Jun 10, 2015 at 1:26 PM, Chanaka Sampath Cooray < >>>>> chanakasampat...@gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Here are the points we have discussed in the last meeting. >>>>>> >>>>>>- Building a proper data structure to store and process the >>>>>>Message Flow >>>>>>- Persist the collected data after the Message Flow has >>>>>>completely finished - Store the data from the data collection points >>>>>> in >>>>>>memory until the message flow finished >>>>>>- Store the first generated Message Id as a property in the >>>>>>Message Context - message id will be changed in some situations, so we >>>>>>can't be able to track the message flow >>>>>>- Pay special attention to the mediators extends >>>>>>from FlowContinuableMediator - Mediators those have branch
Re: [Architecture] Deploying an ESB Connector with a cApp?
Good progress Shakila. Lets get the end-to-end use case working. On Thu, Jul 9, 2015 at 5:27 PM, Shakila Sivagnanarajah wrote: > Hi Malaka, > > I have tested the scenarios [1] and [2]. [1] is working fine and to test > [2], I am unable to bundle connector and proxy-service in a CApp. If I add > those two in to the config project, the CApp will contain proxy-service > only. > > [1] Including more than one connector in CApp. > [2] Use the connector inside a proxy service, Api and sequence that are > included in the same CApp. > > Thank you. > > On Thu, Jul 9, 2015 at 10:20 AM, Shakila Sivagnanarajah > wrote: > >> Hi Malaka, >> >> As you noted, I will test for possible scenarios. >> >> Thank you. >> >> On Thu, Jul 9, 2015 at 10:10 AM, Malaka Silva wrote: >> >>> Hi Shakila, >>> >>> Good Progress on this. >>> >>> Let's verify some scenario similar to following, >>> >>>1. Include more that one connector. >>>2. Use the connector inside a proxy service, Api and sequence that >>>are included in the same capp. >>> >>> >>> On Wed, Jul 8, 2015 at 6:23 PM, Shakila Sivagnanarajah >> > wrote: >>> >>>> Hi all, >>>> >>>> I have done the connector deployment from CApp. >>>> >>>> Thank you >>>> >>>> On Wed, Jul 8, 2015 at 10:25 AM, Shakila Sivagnanarajah < >>>> shak...@wso2.com> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Please find the CApp [1]. >>>>> >>>>> This is my progress: >>>>> >>>>> 1. I added the connector zip in to the CApp as an artifact and >>>>> specified the artifact type as "zip". >>>>> 2. As the same way to deploy the artifact, I have implemented a method >>>>> to deploy the synapse library in [2] (Still testing). >>>>> 3. I have added some constants in [3]. >>>>> >>>>> I am following the way that Dushan noted. Initially I am doing this >>>>> with a single connector. As the first step, Now I am doing the connector >>>>> deployment (CAR -- > upload -- > deploy connector). >>>>> >>>>> [1] >>>>> https://drive.google.com/a/wso2.com/file/d/0B3SvJgvWs9I_eWY5UEJhM3pzb0k/view?usp=sharing >>>>> >>>>> [2] >>>>> /components/application-deployers/org.wso2.carbon.application.deployer.synapse/src/main/java/org/wso2/carbon/application/deployer/synapse/SynapseAppDeployer.java >>>>> >>>>> [3] >>>>> /components/application-deployers/org.wso2.carbon.application.deployer.synapse/src/main/java/org/wso2/carbon/application/deployer/synapse/SynapseAppDeployerConstants.java >>>>> >>>>> >>>>> Thank you. >>>>> >>>>> On Wed, Jul 8, 2015 at 6:02 AM, Dushan Abeyruwan >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 7, 2015 at 8:07 AM, Jasintha Dasanayake < >>>>>> jasin...@wso2.com> wrote: >>>>>> >>>>>>> @viraj >>>>>>> >>>>>>> Shall we enable this in ESB project level , since there is a option >>>>>>> already in ESB project , that we can improve to pack connector into capp >>>>>>> when adding the ESB project into Capp ? >>>>>>> >>>>>> +1 this should be feasible with ESB Project level as its already >>>>>> there in DevS >>>>>> >>>>>> Shashika, could please provide more detail (design and implementation >>>>>> detail/changes you have done) how you planned to integrate this ? >>>>>> >>>>>> however, please note that we need manage depdenencies correctly >>>>>> >>>>>> CAR -- > upload -- > deploy connector/s --- >[[*critical:* monitor >>>>>> the status of connector deployment]] -- if success ---> execute >>>>>> connector-meta-import --> if success -- > then deploy other >>>>>> synapse-artifacts >>>>>> >>>>>> *guess, the difficulty can be holding synapse artifact deployment >>>>>> till connector's uploaded successfully and import connector meta data, >>>>>> have >>>>>> found sol
Re: [Architecture] [GSoC] WSO2 ESB - Netty Transport Enhancements
Hi Achintha, As we are behind the schedule, we need to complete the end to end message flow for content aware scenarios. We expect you to finish this by end of this week. If not we won't be able to cover the proposed scope for this project. On Fri, Jun 26, 2015 at 9:35 PM, Achintha Reemal wrote: > Hi > > After meeting with Isuru Ranawaka on 25th June, we discussed on the > following proceedings for the coming week. > > - Implement means to read from the queue(while allowing write operations), > which is being currently implemented for the content-non aware scenario. > - Identify means to extract HttpContent once converted into an input > stream, to be fed to mediation. > - Debug and identify the message building implementation, which would > build the message for content aware scenarios. > - Validate the message flow for content aware scenario. > > Regards, > > On Fri, Jun 12, 2015 at 9:05 AM, Achintha Reemal > wrote: > >> Hi, >> >> After meeting with Isuru on 11th June, we discussed on the following >> proceedings for the coming week. >> >> - Further look into the current implementation with respect to the >> adaptation for with chunking and without chunking in HTTP Content >> - Debug and identify the message flow within the current implementation. >> - Identify how chunked content are being held in the current >> implementation. >> - Research on means to write the chunked content to the current Pipe >> implementation as an input stream, which would enable the content aware >> scenario. >> - Try to implement the above task by 18th June. >> >> Regards, >> >> On Sun, May 24, 2015 at 3:00 PM, Achintha Reemal >> wrote: >> >>> Hi, >>> >>> During the week, I have looked into the following aspects of the project >>> >>> - Observed the current implementation of Netty-PassThru transport >>> provided by, and special attention was given to the current Pipe >>> implementation as instructed by Isuru. Further observation was done to >>> identify Netty specific parts in the implementation (like the use of >>> classes like ChannelInboundHandlerAdapter, ChannelHandlerContext etc.) >>> >>> - Identifying the usage of different Encoders / Decoders in netty. >>> >>> - Getting to know the current layout of WSO2 ESB transport layer and >>> Mediation Layer, in order to identify the correlation of these two layers, >>> which would be required when decoupling them. >>> >>> Regards, >>> -- >>> *G.H.Achintha Reemal* >>> *BSc Eng Undergraduate| Department of Computer Science & Engineering | >>> University of Moratuwa* >>> *Intern Software Engineer**| WSO2 Lanka (Pvt) Ltd.* >>> *Blog|** rimmythepaperclip.blogspot.com >>> <http://rimmythepaperclip.blogspot.com>* >>> *Twitter|* @rimmynuts(A.Reemal) >>> *LinkedIn|* lk.linkedin.com/in/achinthareemal/ >>> *Mobile| *0715471301 >>> >> >> >> >> -- >> *G.H.Achintha Reemal* >> *BSc Eng Undergraduate| Department of Computer Science & Engineering | >> University of Moratuwa* >> *Intern Software Engineer**| WSO2 Lanka (Pvt) Ltd.* >> *Blog|** rimmythepaperclip.blogspot.com >> <http://rimmythepaperclip.blogspot.com>* >> *Twitter|* @rimmynuts(A.Reemal) >> *LinkedIn|* lk.linkedin.com/in/achinthareemal/ >> *Mobile| *0715471301 >> > > > > -- > *G.H.Achintha Reemal* > *BSc Eng Undergraduate| Department of Computer Science & Engineering | > University of Moratuwa* > *Intern Software Engineer**| WSO2 Lanka (Pvt) Ltd.* > *Blog|** rimmythepaperclip.blogspot.com > <http://rimmythepaperclip.blogspot.com>* > *Twitter|* @rimmynuts(A.Reemal) > *LinkedIn|* lk.linkedin.com/in/achinthareemal/ > *Mobile| *0715471301 > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Deploying an ESB Connector with a cApp?
Any progress on this task? On Thu, Jul 2, 2015 at 11:09 PM, Malaka Silva wrote: > Hi All, > > Shakila will be starting to implement this functionality from ESB side. > > @Shakila - Any blockers user this mail thread to discuss. > > On Tue, Jun 30, 2015 at 5:57 PM, Jasintha Dasanayake > wrote: > >> From tooling perspective, this is similar to class mediator deployment >> using Capp , Since Capp class mediator deployment now working fine with >> Capp so this can be done , However this is also kind of sever extension so >> we have to educate the users to use this properly. >> >> Thanks and Regards >> /Jasintha >> >> On Tue, Jun 30, 2015 at 5:11 PM, Kasun Indrasiri wrote: >> >>> Hi, >>> >>> AFAIR, this was discussed several times. But in the context of ESB as a >>> service, I think this will be quite useful. I don't think we have any >>> technical difficulty in doing this. >>> >>> Use case : >>> - We want to invoke a twitter operation. >>> - Import the twitter connector from connector-store( into DevS) and use >>> the twitter connector operation in our mediation logic. >>> - Now we want to deploy the artifact into ESB but it is required to >>> deploy/enable the connector beforehand. (If the connector is not deployed >>> in the ESB instance, this config deployment will fail.) >>> - If we can include the connector as part of the cApp, then the >>> connector deployment is completely transparent to the users. >>> >>> WDYT? >>> >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >> >> >> >> -- >> >> *Jasintha Dasanayake* >> >> *Senior Software EngineerWSO2 Inc. | http://wso2.com >> <http://wso2.com/>lean . enterprise . middleware* >> >> >> *mobile :- 0711368118 <0711368118>* >> > > > > -- > > Best Regards, > > Malaka Silva > Senior Tech Lead > M: +94 777 219 791 > Tel : 94 11 214 5345 > Fax :94 11 2145300 > Skype : malaka.sampath.silva > LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 > Blog : http://mrmalakasilva.blogspot.com/ > > WSO2, Inc. > lean . enterprise . middleware > http://www.wso2.com/ > http://www.wso2.com/about/team/malaka-silva/ > <http://wso2.com/about/team/malaka-silva/> > > Save a tree -Conserve nature & Save the world for your future. Print this > email only if it is absolutely necessary. > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Deploying an ESB Connector with a cApp?
Hi, AFAIR, this was discussed several times. But in the context of ESB as a service, I think this will be quite useful. I don't think we have any technical difficulty in doing this. Use case : - We want to invoke a twitter operation. - Import the twitter connector from connector-store( into DevS) and use the twitter connector operation in our mediation logic. - Now we want to deploy the artifact into ESB but it is required to deploy/enable the connector beforehand. (If the connector is not deployed in the ESB instance, this config deployment will fail.) - If we can include the connector as part of the cApp, then the connector deployment is completely transparent to the users. WDYT? -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [GSoC] ESB - End-to-end Message Tracing Support
2015 at 3:27 PM, Manuranga Perera >>>>>> wrote: >>>>>> >>>>>>> Does this data publishing goes through the same log4j flow? Is the >>>>>>> data collector written as a log4j appender ? >>>>>>> >>>>>>> ___ >>>>>>> Architecture mailing list >>>>>>> Architecture@wso2.org >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Chanaka Sampath Cooray* >>>>>> Undergraduate | Department of Computer Science and >>>>>> Engineering,University of Moratuwa >>>>>> Mobile: +94 71 361 4884 >>>>>> E-Mail: chanakasampat...@gmail.com >>>>>> Linked-In: https://lk.linkedin.com/pub/chanaka-sampath/65/221/102 >>>>>> <https://lk.linkedin.com/pub/chanaka-sampath/65/221/102> >>>>>> >>>>>> ___ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Isuru Udana* >>>>> Associate Technical Lead >>>>> WSO2 Inc.; http://wso2.com >>>>> email: isu...@wso2.com cell: +94 77 3791887 >>>>> blog: http://mytecheye.blogspot.com/ >>>>> >>>> >>>> >>>> >>>> -- >>>> *Chanaka Sampath Cooray* >>>> Undergraduate | Department of Computer Science and >>>> Engineering,University of Moratuwa >>>> Mobile: +94 71 361 4884 >>>> E-Mail: chanakasampat...@gmail.com >>>> Linked-In: https://lk.linkedin.com/pub/chanaka-sampath/65/221/102 >>>> <https://lk.linkedin.com/pub/chanaka-sampath/65/221/102> >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >> >> >> -- >> *Isuru Udana* >> Associate Technical Lead >> WSO2 Inc.; http://wso2.com >> email: isu...@wso2.com cell: +94 77 3791887 >> blog: http://mytecheye.blogspot.com/ >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Chanaka Sampath Cooray* > Undergraduate | Department of Computer Science and Engineering,University > of Moratuwa > Mobile: +94 71 361 4884 > E-Mail: chanakasampat...@gmail.com > Linked-In: https://lk.linkedin.com/pub/chanaka-sampath/65/221/102 > <https://lk.linkedin.com/pub/chanaka-sampath/65/221/102> > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] HTTP Inbound Endpoint - Dispatching logic
Hi, In the current HTTP Inbound EP impl, the message dispatching occurs as follows. - All proxy services and APIs are exposed on default HTTP port (8280). - We can create a HTTP inbound EP that listens for request on a given port (say 6060). Once we do that, all the proxy services and APIs are also available via that port (i.e.: You can access the same proxy service via 8280 or 6060). - Likewise as you keep on creating inbound EPs, the existing proxies and APIs will be exposed on those ports. - Using a service parameter (inbound.only=true), we block any request that comes to a proxy service and only expose that through inbound endpoints. IMO, above behavior may be useful in certain use cases, but there can be a requirement which the user doesn't want to expose all proxy services/api through all the available HTTP endpoints. Hence, it is required to control the dispatching logic at Inbound EP level, so that we can specify the allowed services and APIs (as a pattern matching expression) when we define an inbound EP. Any thoughts? Thanks, -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Dynamic parameters with inbound endpoints
In the current impl, the engine and the UI seems to be bit disconnected. (config translates to "key:conf:/repository/esb/esb-configurations/test" in the UI (This will be complicated when it comes to dev studio perspective) How about using the following config, so that the UI and engine is using the same semantics. *$registry:* conf:/repository/esb/esb-configurations/test On Tue, Jun 16, 2015 at 10:50 AM, Kasun Indrasiri wrote: > Great. Must be very useful when we deal with multiple environments. > > On Tue, Jun 16, 2015 at 10:50 AM, Malaka Silva wrote: > >> Hi Kasun, >> >> Yes it's available for all the inbound protocols and functionality is >> available since esb 4.9.0 alpha release. >> >> On Tue, Jun 16, 2015 at 10:44 AM, Kasun Indrasiri wrote: >> >>> Hi Malaka, >>> >>> Do we support this capability in the current inbound implementation? >>> >>> On Mon, May 11, 2015 at 8:34 PM, Malaka Silva wrote: >>> >>>> Hi, >>>> >>>> This will cover the following requirement. >>>> >>>> *Use Case:* >>>> User should be able to use the same CAPP across all the environments. >>>> However some parameters like file urls, endpoints etc are different in each >>>> environment. >>>> Solution with the improvement: Environment specific values can be >>>> maintained in registry and can be used in inbound configuration. >>>> >>>> Following is the new configuration to support parameter values from >>>> registry entries. >>>> >>>> http://ws.apache.org/ns/synapse"; >>>> name="wso2File" sequence="request" onError="fault" protocol="file" >>>>suspend="false"> >>>> >>>> 1000 >>>> NONE >>>> >>> name="transport.vfs.LockReleaseSameNode">false >>>> false >>>> >>> name="transport.vfs.ActionAfterFailure">NONE >>>> >>> name="transport.vfs.ActionAfterProcess">NONE >>>> false >>>> >>> *key="conf:/repository/esb/esb-configurations/test"*/> >>>> false >>>> enable >>>> >>>> >>>> >>>> When entering from UI need to prefix the value with key: >>>> >>>> eg:- *key:conf:/repository/esb/esb-configurations/test* >>>> >>>> >>>> [image: Inline image 1] >>>> >>>> >>>> >>>> >>>> >>>> On Mon, May 11, 2015 at 9:57 AM, Malaka Silva wrote: >>>> >>>>> Hi, >>>>> >>>>> I am planning to add the dynamic parameter support for Inbound >>>>> Endpoints. >>>>> >>>>> Currently with polling inbound transport configurations (VFS/JMS), we >>>>> are specifying parameters in the configuration level. But it is a painful >>>>> scenario when moving these artifacts among different environments, since >>>>> the defined parameters for these inbound endpoints services are specific >>>>> to >>>>> the deployed environment. >>>>> >>>>> With the change we can use the registry to store the parameters like >>>>> bellow. >>>>> >>>>> http://ws.apache.org/ns/synapse"; >>>>> name="wso2File" sequence="request" onError="fault" protocol="file" >>>>>suspend="false"> >>>>> >>>>> 1000 >>>>> >>>> name="transport.vfs.ActionAfterErrors">NONE >>>>> >>>> name="transport.vfs.LockReleaseSameNode">false >>>>> false >>>>> >>>> name="transport.vfs.ActionAfterFailure">NONE >>>>> >>>> name="transport.vfs.ActionAfterProcess">NONE >>>>> false >>>>> >>>>> *conf:/repository/esb/esb-configurations/tes*t >>>>> false >>>>> enable >>>>> >>>>> >>>>> >>>>> Related Jira [1] >>>>> >>>>> [1] https://wso2.org/jira/browse/ESBJAVA-3595 >>>>> >>>>> >>>>&
[Architecture] [ESB] Can we get rid of the usage of get-property function?
Hi, It seems we can get rid of the usage of get-property and stick to the usage of scope variable declarations only (the current impl of get-property function always triggers a call to ESB registry interface, which can be a performance hit). For example we can use: $ctx, $trp etc to get required property values from the context. @Nadeeshan : we need to include $registry: as well. Any other use cases that we need to cover? -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Dynamic parameters with inbound endpoints
Great. Must be very useful when we deal with multiple environments. On Tue, Jun 16, 2015 at 10:50 AM, Malaka Silva wrote: > Hi Kasun, > > Yes it's available for all the inbound protocols and functionality is > available since esb 4.9.0 alpha release. > > On Tue, Jun 16, 2015 at 10:44 AM, Kasun Indrasiri wrote: > >> Hi Malaka, >> >> Do we support this capability in the current inbound implementation? >> >> On Mon, May 11, 2015 at 8:34 PM, Malaka Silva wrote: >> >>> Hi, >>> >>> This will cover the following requirement. >>> >>> *Use Case:* >>> User should be able to use the same CAPP across all the environments. >>> However some parameters like file urls, endpoints etc are different in each >>> environment. >>> Solution with the improvement: Environment specific values can be >>> maintained in registry and can be used in inbound configuration. >>> >>> Following is the new configuration to support parameter values from >>> registry entries. >>> >>> http://ws.apache.org/ns/synapse"; >>> name="wso2File" sequence="request" onError="fault" protocol="file" >>>suspend="false"> >>> >>> 1000 >>> NONE >>> >> name="transport.vfs.LockReleaseSameNode">false >>> false >>> NONE >>> NONE >>> false >>> >> *key="conf:/repository/esb/esb-configurations/test"*/> >>> false >>> enable >>> >>> >>> >>> When entering from UI need to prefix the value with key: >>> >>> eg:- *key:conf:/repository/esb/esb-configurations/test* >>> >>> >>> [image: Inline image 1] >>> >>> >>> >>> >>> >>> On Mon, May 11, 2015 at 9:57 AM, Malaka Silva wrote: >>> >>>> Hi, >>>> >>>> I am planning to add the dynamic parameter support for Inbound >>>> Endpoints. >>>> >>>> Currently with polling inbound transport configurations (VFS/JMS), we >>>> are specifying parameters in the configuration level. But it is a painful >>>> scenario when moving these artifacts among different environments, since >>>> the defined parameters for these inbound endpoints services are specific to >>>> the deployed environment. >>>> >>>> With the change we can use the registry to store the parameters like >>>> bellow. >>>> >>>> http://ws.apache.org/ns/synapse"; >>>> name="wso2File" sequence="request" onError="fault" protocol="file" >>>>suspend="false"> >>>> >>>> 1000 >>>> NONE >>>> >>> name="transport.vfs.LockReleaseSameNode">false >>>> false >>>> >>> name="transport.vfs.ActionAfterFailure">NONE >>>> >>> name="transport.vfs.ActionAfterProcess">NONE >>>> false >>>> >>>> *conf:/repository/esb/esb-configurations/tes*t >>>> false >>>> enable >>>> >>>> >>>> >>>> Related Jira [1] >>>> >>>> [1] https://wso2.org/jira/browse/ESBJAVA-3595 >>>> >>>> >>>> Best Regards, >>>> >>>> Malaka Silva >>>> Senior Tech Lead >>>> M: +94 777 219 791 >>>> Tel : 94 11 214 5345 >>>> Fax :94 11 2145300 >>>> Skype : malaka.sampath.silva >>>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >>>> Blog : http://mrmalakasilva.blogspot.com/ >>>> >>>> WSO2, Inc. >>>> lean . enterprise . middleware >>>> http://www.wso2.com/ >>>> http://www.wso2.com/about/team/malaka-silva/ >>>> <http://wso2.com/about/team/malaka-silva/> >>>> >>>> Save a tree -Conserve nature & Save the world for your future. Print >>>> this email only if it is absolutely necessary. >>>> >>> >>> >>> >>> -- >>> >>> Best Regards, >>> >>> Malaka Silva >>> Senior Tech Lead >>> M: +94 777 219 791 >>> Tel : 94 11 214 5345 >>> Fax :94 11
Re: [Architecture] Dynamic parameters with inbound endpoints
Hi Malaka, Do we support this capability in the current inbound implementation? On Mon, May 11, 2015 at 8:34 PM, Malaka Silva wrote: > Hi, > > This will cover the following requirement. > > *Use Case:* > User should be able to use the same CAPP across all the environments. > However some parameters like file urls, endpoints etc are different in each > environment. > Solution with the improvement: Environment specific values can be > maintained in registry and can be used in inbound configuration. > > Following is the new configuration to support parameter values from > registry entries. > > http://ws.apache.org/ns/synapse"; name="wso2File" > sequence="request" onError="fault" protocol="file" > suspend="false"> > > 1000 > NONE > false > false > NONE > NONE > false >*key="conf:/repository/esb/esb-configurations/test"*/> > false > enable > > > > When entering from UI need to prefix the value with key: > > eg:- *key:conf:/repository/esb/esb-configurations/test* > > > [image: Inline image 1] > > > > > > On Mon, May 11, 2015 at 9:57 AM, Malaka Silva wrote: > >> Hi, >> >> I am planning to add the dynamic parameter support for Inbound Endpoints. >> >> Currently with polling inbound transport configurations (VFS/JMS), we are >> specifying parameters in the configuration level. But it is a painful >> scenario when moving these artifacts among different environments, since >> the defined parameters for these inbound endpoints services are specific to >> the deployed environment. >> >> With the change we can use the registry to store the parameters like >> bellow. >> >> http://ws.apache.org/ns/synapse"; >> name="wso2File" sequence="request" onError="fault" protocol="file" >>suspend="false"> >> >> 1000 >> NONE >> > name="transport.vfs.LockReleaseSameNode">false >> false >> NONE >> NONE >> false >> >> *conf:/repository/esb/esb-configurations/tes*t >> false >> enable >> >> >> >> Related Jira [1] >> >> [1] https://wso2.org/jira/browse/ESBJAVA-3595 >> >> >> Best Regards, >> >> Malaka Silva >> Senior Tech Lead >> M: +94 777 219 791 >> Tel : 94 11 214 5345 >> Fax :94 11 2145300 >> Skype : malaka.sampath.silva >> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >> Blog : http://mrmalakasilva.blogspot.com/ >> >> WSO2, Inc. >> lean . enterprise . middleware >> http://www.wso2.com/ >> http://www.wso2.com/about/team/malaka-silva/ >> <http://wso2.com/about/team/malaka-silva/> >> >> Save a tree -Conserve nature & Save the world for your future. Print this >> email only if it is absolutely necessary. >> > > > > -- > > Best Regards, > > Malaka Silva > Senior Tech Lead > M: +94 777 219 791 > Tel : 94 11 214 5345 > Fax :94 11 2145300 > Skype : malaka.sampath.silva > LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 > Blog : http://mrmalakasilva.blogspot.com/ > > WSO2, Inc. > lean . enterprise . middleware > http://www.wso2.com/ > http://www.wso2.com/about/team/malaka-silva/ > <http://wso2.com/about/team/malaka-silva/> > > Save a tree -Conserve nature & Save the world for your future. Print this > email only if it is absolutely necessary. > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Using Refresh token in ESB connectors
time. So after expiration time, the >>>>> connector >>>>> will not be usable. >>>>> >>>>> *Explanation:* >>>>> After a successful OAuth flow we receive an Access Token & a Refresh >>>>> Token from the service. But within the current implementation of >>>>> connectors >>>>> the Refresh Token is not being used. According to OAuth 2 Authorization >>>>> Framework Spec. (RFC 6749), at section "Refreshing an Access Token" >>>>> following type of request can be used to obtain a new Access Token. >>>>> >>>>> POST /token HTTP/1.1 >>>>> Host: server.example.com >>>>> Authorization: Basic czZCaGRSa3FnWDFmQmF0M2JW >>>>> Content-Type: application/x-www-form-urlencoded >>>>> >>>>> grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA >>>>> >>>>> >>>>> >>>>> Also, it is noted that server MAY issue a new Refresh token in the >>>>> response and client should renew the Refresh Token too. >>>>> >>>>> Since refreshing Access Token implementation is not in connector >>>>> implementation, connectors will not be usable for long running production >>>>> environment. >>>>> >>>> >>>> Your concern is 100% correct and we have already taken this into >>>> consider after our first released of the connectors. The most of the >>>> connectors that are implemented in recent past contain the Oauth flow. If >>>> you can point out the connectors that need to be improve. That would be >>>> helpful us to prioritize development process. >>>> >>>> >>>>> >>>>> So, your thoughts on this would be highly appreciated. >>>>> >>>>> Thank you! >>>>> >>>>> -- >>>>> Buddhima Wijeweera >>>>> Software Engineer; WSO2 Inc.; http://wso2.com , >>>>> >>>>> Mobile: +94 71 427 9966 >>>>> Email: buddh...@wso2.com >>>>> Blog: https://buddhimawijeweera.wordpress.com >>>>> GitHub Profile: https://github.com/Buddhima >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Sivajothy Vanjikumaran >>>> *Senior Software Engineer* >>>> *Integration Technologies Team* >>>> *WSO2 Inc. http://wso2.com <http://wso2.com/>* >>>> *Mobile:(+94)777219209* >>>> [image: Facebook] <https://www.facebook.com/vanjikumaran> [image: >>>> Twitter] <https://twitter.com/vanjikumaran> [image: LinkedIn] >>>> <http://www.linkedin.com/pub/vanjikumaran-sivajothy/25/b31/293> [image: >>>> Blogger] <http://vanjikumaran.blogspot.com/> [image: SlideShare] >>>> <http://www.slideshare.net/vanjikumaran> >>>> >>>> This communication may contain privileged or other >>>> confidential information and is intended exclusively for the addressee/s. >>>> If you are not the intended recipient/s, or believe that you may >>>> have received this communication in error, please reply to the >>>> sender indicating that fact and delete the copy you received and in >>>> addition, you should not print, copy, re-transmit, disseminate, or >>>> otherwise use the information contained in this communication. >>>> Internet communications cannot be guaranteed to be timely, secure, error >>>> or virus-free. The sender does not accept liability for any errors >>>> or omissions >>>> >>> >>> >>> >>> -- >>> Buddhima Wijeweera >>> Software Engineer; WSO2 Inc.; http://wso2.com , >>> >>> Mobile: +94 71 427 9966 >>> Email: buddh...@wso2.com >>> Blog: https://buddhimawijeweera.wordpress.com >>> GitHub Profile: https://github.com/Buddhima >>> >> >> >> >> -- >> Sivajothy Vanjikumaran >> *Senior Software Engineer* >> *Integration Technologies Team* >> *WSO2 Inc. http://wso2.com <http://wso2.com/>* >> *Mobile:(+94)777219209* >> [image: Facebook] <https://www.facebook.com/vanjikumaran> [image: >> Twitter] <https://twitter.com/vanjikumaran> [image: LinkedIn] >> <http://www.linkedin.com/pub/vanjikumaran-sivajothy/25/b31/293> [image: >> Blogger] <http://vanjikumaran.blogspot.com/> [image: SlideShare] >> <http://www.slideshare.net/vanjikumaran> >> >> This communication may contain privileged or other >> confidential information and is intended exclusively for the addressee/s. >> If you are not the intended recipient/s, or believe that you may >> have received this communication in error, please reply to the >> sender indicating that fact and delete the copy you received and in >> addition, you should not print, copy, re-transmit, disseminate, or >> otherwise use the information contained in this communication. >> Internet communications cannot be guaranteed to be timely, secure, error >> or virus-free. The sender does not accept liability for any errors >> or omissions >> > > > > -- > Buddhima Wijeweera > Software Engineer; WSO2 Inc.; http://wso2.com , > > Mobile: +94 71 427 9966 > Email: buddh...@wso2.com > Blog: https://buddhimawijeweera.wordpress.com > GitHub Profile: https://github.com/Buddhima > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Persisting content into registry from the mediation layer
Looks good. Please proceed with the fix and update the documentation.
On Mon, Jun 1, 2015 at 10:44 AM, Nadeeshaan Gunasinghe
wrote:
> Hi all,
> In order to persist content in to mediation layer I added an initial
> implementation and via that we can use the following mediation logic to
> store new persistent content in the registry,
>
> scope="registry"/> and
> scope="registry"/>
>
> In this implementation it uses scope to determine whether the content need
> to be stored persistently or not. Then a new registry entry is created to
> store the content either as a resource or as a new resource property. Name
> attribute include the registry location to store the content
>
> Initial implementation can be found bellow.
>
> [1]
> https://github.com/wso2/wso2-synapse/compare/master...nadeeshaan:Persistant_Property_Impl
> [2]
> https://github.com/wso2/carbon-mediation/compare/master...nadeeshaan:Persistant_Property_Impl
>
> Regards
>
>
>
> On Tue, May 26, 2015 at 10:03 AM, Malaka Silva wrote:
>
>> Hi,
>>
>> Yes this make sense if the provider does not support password grant type.
>>
>> But my concern is security. If we save the access tokens and refresh
>> token it's visible to all parties.
>>
>> Can we do the same with secure-vault instead. WDYT?
>>
>> eg:-
>>
>> wso2:vault-lookup('UserManager.AdminUser.Password')
>>
>> wso2:vault-set('UserManager.AdminUser.Password','');
>>
>> On Tue, May 26, 2015 at 9:51 AM, Kasun Indrasiri wrote:
>>
>>> Hi,
>>>
>>> It is often required to persist content into the underlying registry
>>> impl during message mediation (in stateful mediation scenarios). For
>>> example, with connector we need to keep the access token/refresh token
>>> persisted. Therefore a generic mechanism of persisting content from
>>> mediation flow will be useful.
>>>
>>> At the moment, we do support retrieving content from the registry with
>>> following mediation logic.
>>>
>>> >>
>>> expression="get-property('registry', 'conf:/Resource/bar')"
>>>
>>> Similarly, we can implement the content persistent capability with
>>> property mediator using its scope concept.
>>>
>>> >> scope="registry"/>
>>>
>>> Please share your thoughts.
>>> @Nadeeshan/Buddhima : Will this design fits into solving access
>>> token/refresh token handling limitations with Connectors?
>>>
>>> --
>>> Kasun Indrasiri
>>> Software Architect
>>> WSO2, Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> cell: +94 77 556 5206
>>> Blog : http://kasunpanorama.blogspot.com/
>>>
>>
>>
>>
>> --
>>
>> Best Regards,
>>
>> Malaka Silva
>> Senior Tech Lead
>> M: +94 777 219 791
>> Tel : 94 11 214 5345
>> Fax :94 11 2145300
>> Skype : malaka.sampath.silva
>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
>> Blog : http://mrmalakasilva.blogspot.com/
>>
>> WSO2, Inc.
>> lean . enterprise . middleware
>> http://www.wso2.com/
>> http://www.wso2.com/about/team/malaka-silva/
>> <http://wso2.com/about/team/malaka-silva/>
>>
>> Save a tree -Conserve nature & Save the world for your future. Print this
>> email only if it is absolutely necessary.
>>
>
>
--
Kasun Indrasiri
Software Architect
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware
cell: +94 77 556 5206
Blog : http://kasunpanorama.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Persisting content into registry from the mediation layer
Hi, It is often required to persist content into the underlying registry impl during message mediation (in stateful mediation scenarios). For example, with connector we need to keep the access token/refresh token persisted. Therefore a generic mechanism of persisting content from mediation flow will be useful. At the moment, we do support retrieving content from the registry with following mediation logic. Please share your thoughts. @Nadeeshan/Buddhima : Will this design fits into solving access token/refresh token handling limitations with Connectors? -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Tooling support for ESB Inbound Endpoint
Hi Viraj, An inbound endpoint can also deliver the messages to a proxy service or API too. That will complicate the graphical representation. Any thought on supporting that? On Tue, May 5, 2015 at 4:53 PM, Viraj Rajaguru wrote: > Hi Isuru, > > We have added left side bar to indicate that it is an Inbound endpoint. > > Thanks, > Viraj. > > On Wed, Feb 11, 2015 at 2:43 PM, Isuru Udana wrote: > >> Hi Viraj, >> >> We need to have a left side bar indicating that it is an Inbound Endpoint >> (Similar to what we have in APIs, proxy services). >> >> Thanks. >> >> On Tue, Feb 10, 2015 at 8:57 PM, Viraj Rajaguru wrote: >> >>> Hi, >>> >>> We have started the implementation of tooling support for Inbound >>> endpoint in Developer Studio, targeting Developer Studio 3.8.0 release. >>> >>> As a result of the discussion we had with the ESB team, we have come up >>> with a design for representing Inbound endpoints graphically. Please see >>> the attached image (InboundEndpoint.png) which depicts the proposed design. >>> >>> Users will be able to drag and drop already defined(or new) sequences >>> for "sequence" and "onError" values for InboundEndpoint from the tool >>> palette.(See the "sequence" and "onError" attributes in sample Inbound >>> endpoint config[1]). Users can double click on sequence mediators in >>> inbound endpoint diagram to go to the actual sequence diagram. Other >>> attributes/properties in Inbound Endpoint will be shown using the Eclipse's >>> default "Properties view". >>> >>> Your feedback and suggestions are welcome. >>> >>> [1] >>> http://ws.apache.org/ns/synapse"; >>> name="MyInboundEndpoint" >>> sequence="MyInjectionSequence" >>> onError="MyOnErrorSequence" >>> protocol="http" >>> suspend="false"> >>> >>> 8000 >>> >>> >>> >>> >>> Thanks, >>> Viraj. >>> -- >>> Viraj Rajaguru >>> Senior Software Engineer >>> WSO2 Inc. : http://wso2.com >>> >>> Mobile: +94 77 3683068 >>> >>> >>> >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Isuru Udana* >> Senior >> *Software Engineer* >> WSO2 Inc.; http://wso2.com >> email: isu...@wso2.com cell: +94 77 3791887 >> blog: http://mytecheye.blogspot.com/ >> twitter: http://twitter.com/isudana >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Viraj Rajaguru > Senior Software Engineer > WSO2 Inc. : http://wso2.com > > Mobile: +94 77 3683068 > > > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [GSoC] WSO2 ESB - Netty Transport Enhancements
Hi Achintha, Please start looking into the current implementation of Netty-PassThru transport. Few points to consider when you are designing the new transport: - Decouple transport, protocol and mediation layers. (in the current impl everything is sort of mixed). - Transport code should be reusable in Netty inbond ( have a look at new HTTPCore based PT impl that support inbound HTTP) On Sat, May 9, 2015 at 12:09 AM, Achintha Reemal wrote: > As per the initial discussion we had on the GSoC projects related to WSO2 > ESB, We have commenced initial preparations for the project. I have started > reading on different Netty implementations and how Netty operates, as > instructed by the mentors. Final design plan and the architecture, and how > the work should progress would be discussed and finalized with the help of > my mentor in the following week. > > Regards, > -- > *G.H.Achintha Reemal* > *BSc Eng Undergraduate| Department of Computer Science & Engineering | > University of Moratuwa* > *Intern Software Engineer**| WSO2 Lanka (Pvt) Ltd.* > *Blog|** rimmythepaperclip.blogspot.com > <http://rimmythepaperclip.blogspot.com>* > *Twitter|* @rimmynuts(A.Reemal) > *LinkedIn|* lk.linkedin.com/in/achinthareemal/ > *Mobile| *0715471301 > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Feedback: Improve Payload Factory and Improving Enrich
Hi Srinath,
Regarding enrich mediator, I think we can get rid of most of the redundant
attributes and support them through xpath only. For instance most of the
operations that you do with enrich can be done using xpath attribute in
both source and target. So, we will fully verify and fix these use cases
while keeping support for existing syntax for backward compatibility.
http://services.samples"/>
http://services.samples"/>
On Wed, May 6, 2015 at 9:46 AM, Srinath Perera wrote:
> Hi Kasun,
>
> I have been working on ESB script last week, and two comments.
>
> 1. If we use payload factory mediator, and if Xpath matches more than one
> results, what do we do? It is a valid usecase if someone want to copy N
> elements from request to response via payload factory.
>
> 2. Enrich has too many parameters, and some combinations does not work. (
> see below).
>
>
> xpath="" property="" />
> [type=custom|envelope|body|property|inline] xpath="" property="" />
>
>
> I think we can remove "type" and "property" and support both via Xpath
> only. We can break Xpath to /foo/bar where source can be $envelope,
> $body $header $getProperty("bar") etc ( $envelope etc is already there).
>
> If we do this correct, we can refer to anything in ESB environment via
> Xpath of the format /foo/bar. Then we can make this consistent
> across the language.
>
> WDYT?
>
> --Srinath
>
> --
>
> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
> Site: http://people.apache.org/~hemapani/
> Photos: http://www.flickr.com/photos/hemapani/
> Phone: 0772360902
>
--
Kasun Indrasiri
Software Architect
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware
cell: +94 77 556 5206
Blog : http://kasunpanorama.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Adding Throttling support in ESB and APIM products
This will be used by several products. Hence I think we need to have it in a common repo such as carbon-commons or something. Sameera any thoughts on this? On Tue, Apr 7, 2015 at 9:46 AM, Chanaka Fernando wrote: > Hi Sanjeewa, > > AFAIR we haven't modified throttle code(dependency 3.3.0-wso2v2 and core > 4.2.1) for long time and we are using it as it is. > We may use the same component version as its already available on repos. > If we need to do any development or fix/improve anything we may need to > get it to git with other version and continue. > WDYT? > > I think it would be better if we get this code to git and maintain it > there. That will allow us to develop/fix the code in the future. > > @Sagara: Once we have the API-Everywhere story implemented, we can use the > API Manager level throttling for other products as well. We are currently > implementing an improved throttle mediator by using the existing throttle > core implementation. That is the reason we need this code to be taken in to > Git repository. > > AFAIK, in either case, it would be better to have this code in the Git > repository. > > WDYT? > > Thanks, > Chanaka > > > On Mon, Apr 6, 2015 at 5:31 PM, Sagara Gunathunga wrote: > >> >> >> On Mon, Apr 6, 2015 at 5:03 PM, Chanaka Fernando >> wrote: >> >>> Hi All, >>> >>> With the latest refactoring of carbon platform source, throttling core >>> implementation has been removed from the platform. But inside APIM and ESB, >>> we need this feature to be supported. AFAIU, even services deployed in AS >>> require this throttling capability. What would be the best way forward for >>> supporting throttling functionality at product level? >>> >> >> What we have removed is old implementation of throttling used with AS/ESB >> due to lot of issues, AFAIK APIM don't use this old implementation, APIM >> already have new throttling implementation. Original plan was to enable >> APIM throttling implementation to AS/DSS/ESB through API- Everywhere. >> >> Thanks ! >> >>> >>> >>> Thanks, >>> Chanaka >>> >>> -- >>> -- >>> Chanaka Fernando >>> Technical Lead >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: +94 773337238 >>> Blog : http://soatutorials.blogspot.com >>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >>> Twitter:https://twitter.com/chanakaudaya >>> Wordpress:http://chanakaudaya.wordpress.com >>> >>> >>> >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sagara Gunathunga >> >> Senior Technical Lead; WSO2, Inc.; http://wso2.com >> V.P Apache Web Services;http://ws.apache.org/ >> Linkedin; http://www.linkedin.com/in/ssagara >> Blog ; http://ssagara.blogspot.com >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > -- > Chanaka Fernando > Technical Lead > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 773337238 > Blog : http://soatutorials.blogspot.com > LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 > Twitter:https://twitter.com/chanakaudaya > Wordpress:http://chanakaudaya.wordpress.com > > > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] How to release a milestone product pack ?
Hi Shankar, Yeah, IMO releasing milestones with release plugin would immensely help our continuos delivery objectives. That helps us to minimize the release overhead when we do a GA (if we don't use release plugin, then some of the issues will be only discovered during the GA release time). And, since our objective is to make sure that the milestone releases are stable (and not half-baked), contains a set of features which are don-done and no any major integration test failures, releasing the upstream components is meaningful I guess. WDYT? On Wed, Mar 11, 2015 at 4:45 AM, Srinath Perera wrote: > In my view, based on what we have discussed so far, we can live with > SNAPSHOT dependancies for milestone releases. > > But we can decide to do more > >1. If we can align milestone releases with component releases, IMO it >is a good thing to encourage frequent releases of components. >2. However, it is not good if we need to fork maven release plugin. >3. One potential solution is to make it optional and ask teams to >release only components they feel are stable in milestone releases and >others can stay as SNAPSHOTs. > > > --Srinath > > > > > On Tue, Mar 10, 2015 at 8:47 PM, Sameera Jayasoma > wrote: > >> I also believe that for milestone releases we can live with SNAPSHOT >> dependencies as Shankar explained. I don't think we should follow the >> proper release process for milestone releases. >> >> Thanks, >> Sameera. >> >> On Tue, Mar 10, 2015 at 5:36 PM, Selvaratnam Uthaiyashankar < >> shan...@wso2.com> wrote: >> >>> Sameera/Kishanthan/KasunG/Srinath, >>> >>> Can you guys comment on this please? >>> >>> On Tue, Mar 10, 2015 at 5:33 PM, Sagara Gunathunga >>> wrote: >>> >>>> >>>> >>>> On Tue, Mar 10, 2015 at 5:12 PM, Selvaratnam Uthaiyashankar < >>>> shan...@wso2.com> wrote: >>>> >>>>> Why do we have to use the release plugin for the milestone releases? I >>>>> don't think it is correct to use the release plugin for milestone release. >>>>> >>>> >>>> Maven release plugin was already used by some other teams during >>>> milestone releases and I also under impression that we should use release >>>> plugin for all releases. If we are not suppose to use release plugin, >>>> shall we agree on following procedure. >>>> >>>> 1. Create a tag in product repo. >>>> 2. Create tags in SNAPSHOT dependency repos. >>>> 3. RM locally build the pack, test and release. >>>> >>>> >>>> Thanks ! >>>> >>>> >>>>> >>>>> We chat yesterday, but I didn't realize we talked about Maven release >>>>> plugin. It shouldn't be forked. >>>>> >>>>> @Kasun, it is similar to ESB depends on carbon-mediation. It is >>>>> developed and maintained by same team. It is valid to depend on SNAPSHOT >>>>> for a milestone release. However, you can't depend on SNAPSHOT components >>>>> developed by some other team (again, there are exceptions, but team has to >>>>> justify that). For example, ESB can't depend on corbon-governance >>>>> SNAPSHOT. >>>>> >>>>> >>>>> On Tue, Mar 10, 2015 at 8:10 AM, Sagara Gunathunga >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Mar 10, 2015 at 12:34 AM, Kasun Indrasiri >>>>>> wrote: >>>>>> >>>>>>> How about depending only on released components for a given product >>>>>>> milestone? Because a given milestone is a stable pack that depends on >>>>>>> the >>>>>>> stables upstream components. >>>>>>> >>>>>> >>>>>> If I reiterate the problem, ATM carbon-governance/carbon-registry >>>>>> are stable in terms of set of completed features but not yet production >>>>>> ready as whole hence IMHO we should avoid proper release numbers (e.g >>>>>> carbon-registry-4.3.2 ) for something not yet production ready, we >>>>>> should use either post-fix like SNAPSHOT or M2, M3 etc. >>>>>> >>>>>> If we just use proper release numbers for milestone versions it will >>>>>> make disaster for end users (both
Re: [Architecture] How to release a milestone product pack ?
How about depending only on released components for a given product milestone? Because a given milestone is a stable pack that depends on the stables upstream components. On Mon, Mar 9, 2015 at 2:06 PM, Sagara Gunathunga wrote: > > We are about to release G-Reg 5.0.0 M3 pack but found an issue when > releasing a milestone version. Let me take G-Reg as an example, G-Reg > 5.0.0-M3 version is depends on carbon-governance SNAPSHOT version and that > is a legitimate use as well ( As G-Reg 5.0.0-M3 version, we actually > release some of the completed features of carbon-governance/carbon-registry > repos.) but Maven release plug-in does not support to release any project > with SNAPSHOT dependencies [1] [4], so we have 2 options to solve this > issue. > > > > *1. ) Modify Maven release plug-in to allow SNAPSHOT dependencies.* > > Pros > - > - Fix is relatively straightforward, we just have to remove validation in > code and allow SNAPSHOT dependencies. > > - No change to release process. > > > Cons > - > - We have to fork and maintain Maven release plug-in locally and will lose > new changes from Apache. > > - If we consider G-Reg-5.0.0-M3 pack, technically it's a milestone version > not a snapshot version so as a principle 'creation process of the pack' > should be repeatable but if we allow SNAPSHOT dependencies inside product > packs 'creation process of the pack' is not repeatable. This is not > something standard, if we decided to go with this approach at least we > should not call them as milestone packs instead SNAPSHOT packs (like > nightly builds) e.g - G-Reg-5.0.0-SNAPSHOT-08-03-15 pack etc. > > > > > > > *2.) Instead of SNAPSHOT dependencies, first release own dependencies with > M-'X' (e.g - carbon-governance-4.4.0-M1 ) and then use these released > versions within the milestone product pack. * > > Example - G-Reg 5.0.0-M3 pack can have carbon-governance-4.4.0-M2 and > carbon-registry-4.3.2-M5 but NOT carbon-identity-4.3.1-M2 > > Pros > - > - Again relatively straightforward, we don't need to fork and maintain > Maven release plug-in. > > - AFAIK adding post-fix to distinguish Milestone, Alpha, Beta versions is > a standard practise [2] , [3] hence end users already aware not to use > milestone versions in production. > > > Cons > - > - There is a chance that other teams can use M-X packs in there milestone > releases, we need a proper governance and disciplines not to do that (e.g > - carbon-governance-4.4.0-M1 should be only use by G-Reg team within WSO2 > other than special permissions) > > > WDYT ? > > > > > [1] - > http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html > > [2] - Spring releases - > http://repo1.maven.org/maven2/org/springframework/spring-core/ > > [3] - Hibernate releases - > http://repo1.maven.org/maven2/org/hibernate/hibernate-search/ > > [4] - When I tied for above, build was stopped with following error. > > [INFO] > > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) > on project carbon-governance: Can't release project due to non released > dependencies : > > [ERROR] > org.wso2.carbon.registry:org.wso2.carbon.registry.admin.api:jar:4.3.1-SNAPSHOT:compile > > [ERROR] > org.wso2.carbon.registry:org.wso2.carbon.registry.common:jar:4.3.1-SNAPSHOT:compile > > [ERROR] > org.wso2.carbon.registry:org.wso2.carbon.registry.extensions:jar:4.3.1-SNAPSHOT:compile > > [ERROR] > org.wso2.carbon.registry:org.wso2.carbon.registry.indexing:jar:4.3.1-SNAPSHOT:compile > > [ERROR] in project 'WSO2 Carbon - Governance' > (org.wso2.carbon.governance:org.wso2.carbon.governance.api:bundle:4.3.1-SNAPSHOT) > > > > Thanks ! > -- > Sagara Gunathunga > > Senior Technical Lead; WSO2, Inc.; http://wso2.com > V.P Apache Web Services;http://ws.apache.org/ > Linkedin; http://www.linkedin.com/in/ssagara > Blog ; http://ssagara.blogspot.com > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Nest ESB connector
s Team* >> *WSO2 Inc. http://wso2.com <http://wso2.com/>* >> *Mobile:(+94)777219209* >> [image: Facebook] <https://www.facebook.com/vanjikumaran> [image: >> Twitter] <https://twitter.com/vanjikumaran> [image: LinkedIn] >> <http://www.linkedin.com/pub/vanjikumaran-sivajothy/25/b31/293> [image: >> Blogger] <http://vanjikumaran.blogspot.com/> [image: SlideShare] >> <http://www.slideshare.net/vanjikumaran> >> >> This communication may contain privileged or other >> confidential information and is intended exclusively for the addressee/s. >> If you are not the intended recipient/s, or believe that you may >> have received this communication in error, please reply to the >> sender indicating that fact and delete the copy you received and in >> addition, you should not print, copy, re-transmit, disseminate, or >> otherwise use the information contained in this communication. >> Internet communications cannot be guaranteed to be timely, secure, error >> or virus-free. The sender does not accept liability for any errors >> or omissions >> > > > > -- > Shakila Sivagnanarajah > Associate Software Engineer > Mobile :+94 (0) 770 760240 > shak...@wso2.com > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Can we define more than one ServerRole in the artifact.xml file of a CAR?
The ServerRole is not designed for distinguish workers/manager, rather distinguish product behaviors (ESB, GReg etc.). And architecturally pinned servers is also not a suitable approach too(but that's the workaround that we have at the moment). Each artifacts needs to have the intelligence to determine whether it should run on worker or manager (or even on all workers or selected workers). In ESB 4.9, the polling inbound endpoints for JMS/VFS has that capability. On Thu, Dec 4, 2014 at 11:41 AM, Chanaka Fernando wrote: > Hi Isuru, > > I agree with what you are saying. We need to have the same artifacts > deployed in both worker and manager nodes. This is a requirement which came > with the JMS listener proxy use case. I think the best solution for this > kind of scenario would be to use the management node as both worker/manager > profile. That would make sure that it will serve the requests as well as > capable of doing the management tasks. > > WDYT? > > Thanks, > Chanaka > > On Thu, Dec 4, 2014 at 11:33 AM, Isuru Udana wrote: > >> Hi Chanaka, >> >> I think we may able to achieve your this particular requirement using the >> pinned server concept. >> >> IMO we should not make differences to artifact deployment in worker nodes >> vs manager node. If we do that, we won't be able to clearly see what is >> actually deployed in workers by looking at the manager node. It will add an >> extra overhead when it comes to troubleshooting. So deployment wise all the >> artifacts should be identical and we need some other mechanism to prevent >> execution in the manager. >> >> Thanks. >> >> >> >> >> >> >> On Thu, Dec 4, 2014 at 10:51 AM, Imesh Gunaratne wrote: >> >>> Hi Chanaka, >>> >>> This looks like a valid requirement. >>> May be we could achieve this by defining two different server roles in >>> manager and worker nodes (in carbon.xml file): >>> >>> In management nodes: >>> >>> EnterpriseServiceBusManager >>> >>> >>> In worker nodes: >>> >>> EnterpriseServiceBusWorker >>> >>> >>> Afterwards we could define the role EnterpriseServiceBusWorker to all >>> the artifacts that should only be deployed in workers. WDYT? >>> >>> Thanks >>> >>> On Thu, Dec 4, 2014 at 7:53 AM, Chanaka Fernando >>> wrote: >>> >>>> Hi, >>>> >>>> Is it possible to do $subject? Requirement is to deploy the same >>>> artifact in 2 different servers with the same CAR file. >>>> >>>> As an example, when we have a JMS listener proxy in our CAR file and we >>>> have a worker/manager separated cluster with dep-sync enabled, once we >>>> deploy this CAR file in the manager node, It would be deployed there and >>>> synced to the worker node. But in this scenario, we do not need the JMS >>>> listener proxy in the management node to listen to the JMS queue. But If we >>>> have the same "ServerRole" in both worker/manager nodes, they will be >>>> deployed and we have to manually stop the proxy service from management >>>> node. >>>> >>>> If we have a capability like defining multiple server roles in >>>> artifact.xml file, we can avoid this behavior by having two different >>>> "ServerRoles" for worker and manager and then defining both ServerRoles in >>>> the required artifacts and defining only one server role for JMS listener >>>> proxy. >>>> >>>> >>>> Thanks, >>>> Chanaka >>>> >>>> >>>> -- >>>> -- >>>> Chanaka Fernando >>>> Technical Lead >>>> WSO2, Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> mobile: +94 773337238 >>>> Blog : http://soatutorials.blogspot.com >>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >>>> Twitter:https://twitter.com/chanakaudaya >>>> Wordpress:http://chanakaudaya.wordpress.com >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> *Imesh Gunaratne* >>> Technical Lead >>> WSO2 Inc: http://wso2.com >>> T: +94 11 214 5345 M: +94 77 374 2057 >>> W: http://imesh.gunaratne.org >>> Lean . Enterprise . Middleware >>> >>> >> >> >> -- >> *Isuru Udana* >> Senior >> *Software Engineer* >> WSO2 Inc.; http://wso2.com >> email: isu...@wso2.com cell: +94 77 3791887 >> blog: http://mytecheye.blogspot.com/ >> twitter: http://twitter.com/isudana >> > > > > -- > -- > Chanaka Fernando > Technical Lead > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 773337238 > Blog : http://soatutorials.blogspot.com > LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 > Twitter:https://twitter.com/chanakaudaya > Wordpress:http://chanakaudaya.wordpress.com > > > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Supporting blocking calls in Call mediator
Hi, At the moment 'Call' mediator offers a blocking messaging behavior on top of non-blocking architecture (i.e. - Request and responses are handled in different threads). However, there are requirements where we need to support pure blocking messaging such as JMS transaction scenarios (which we use Callout mediator at the moment). However, having 'Call' and 'Callout' mediators is very confusing for the users and we need to have a single mediator with both capabilities. Hence we can add the blocking support as part of the Call mediator and deprecate Callout mediator. Thanks, -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Inbound Endpoint support for ESB
Hi all, In the current implementation of JMS and File inbound EPs all the parameter are prefixed with transport.jms or transport.vfs. I think we should get rid of this. On Fri, Jul 18, 2014 at 11:19 PM, Malaka Silva wrote: > After the fixes by Ishan coordination seems to be working fine with > inbound eps. > > > On Mon, Jul 14, 2014 at 4:35 PM, Kasun Indrasiri wrote: > >> +1. Basic UI should be sufficient. >> >> >> On Mon, Jul 14, 2014 at 8:58 PM, Malaka Silva wrote: >> >>> Shall we also do a simple UI for inbound Endpoints? >>> >>> >>> On Thu, Jul 10, 2014 at 1:32 PM, Malaka Silva wrote: >>> >>>> +1 since users can write vendor specific code. eg: IBM Mainframe MQ >>>> >>>> So basically either protocol or class will become mandatory. >>>> >>>> Also CustomPollingTrp should implement PollingConsumer.java [1] >>>> >>>> eg:- >>>> >>>> http://ws.apache.org/ns/synapse"; >>>> name="MyJMSListenerEP" class="org.wso2.carbon.CustomPollingTrp" >>>> sequence="requestHandlerSeq" >>>> onError="inFalte" interval="5" suspend="false"> >>>> >>>> >>> name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory >>>> >>> name="java.naming.provider.url">tcp://localhost:61616 >>>> >>> name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactory >>>> >>> name="transport.jms.ConnectionFactoryType">queue >>>> >>>> wso2.com/ordersQueue >>>> >>> name="transport.jms.SessionAcknowledgement">AUTO_ACKNOWLEDGE >>>> >>>> >>>> >>>> [1] >>>> https://github.com/wso2-dev/wso2-synapse/blob/master/modules/core/src/main/java/org/apache/synapse/inbound/PollingConsumer.java >>>> >>>> >>>> On Wed, Jul 9, 2014 at 7:44 PM, Kasun Indrasiri wrote: >>>> >>>>> One other improvement is to make the inbound endpoints dynamically >>>>> plugable so that the users can write their own inbound EPs (i.e: >>>>> class="org.wso2.carbon.CustomPollingTrp") >>>>> >>>>> >>>>> On Thu, Jun 19, 2014 at 10:09 PM, Kishanthan Thangarajah < >>>>> kishant...@wso2.com> wrote: >>>>> >>>>>> To check whether clustering is enabled, you can acquire the >>>>>> axisConfig instance and check for clustering agent's availability. >>>>>> >>>>>> >>>>>> On Thu, Jun 19, 2014 at 2:18 PM, Ishan Jayawardena >>>>>> wrote: >>>>>> >>>>>>> Is there a way to check whether the current carbon instance is a >>>>>>> stand alone (ie. non clustered) instance or a management node? >>>>>>> >>>>>>> I tried CarbonUtils.isWorkerNode() but it returns false for both >>>>>>> manager node and single instance. It is important to identify if a given >>>>>>> node is a management node to implement the coordination feature of the >>>>>>> ESB >>>>>>> task that is used in schedule tasks and inbound endpoint >>>>>>> implementations. >>>>>>> Therefore what are the possible ways to check this condition? Can we >>>>>>> introduce a new isManagementNode method to the CarbonUtils class? >>>>>>> >>>>>>> Thanks, >>>>>>> Ishan. >>>>>>> >>>>>>> >>>>>>> On Wed, Jun 18, 2014 at 8:15 PM, Kasun Indrasiri >>>>>>> wrote: >>>>>>> >>>>>>>> We need to test the coordination behavior of inbound endpoints and >>>>>>>> make sure it executes only on manager and an elected worker node. >>>>>>>> @Ishan : Please update the thread once we are done with the >>>>>>>> implementation/verification. >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Apr 28, 2014 at 8:01 AM, Kasun Indrasiri >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>
Re: [Architecture] RM Inbound Endpoint for the ESB using Apache CFX
On Fri, Jul 25, 2014 at 12:02 PM, Sandamal Weerasinghe wrote: > Hi all, > > Following the is the high level design of the RM-Inbound-Endpoint that I'm > developing for the WSO2 ESB. This is to be used in a scenario where the > client supports RM, but the back-end service does not. > > RM-IE Overview > <https://docs.google.com/a/wso2.com/drawings/d/1WrVsRqtzG_fKHvyt_v3YAovgvKaLoVGvlLm55qlmXbg/edit?usp=drive_web> > > *Operation* > >- Configure the inbound endpoint in synapse.xml >- Start the ESB and it will listen for the http port configured in the >inbound configuration. > > > *Request Path * > >- An endpoint that supports RM is created using a dummy service class >- An Invoker intercepts and suspends requests that come to the >endpoint >- InboundSourceRequest objects are created for each request message >received. >- Those objects are sent to a ServerWorker in order create Synapse >Message Contexts out of HttpRequests and to be injected to the insequence >specified by the user. > > Why do we need a ServerWorker here? I guess its not something related to CXF. We should be able to create the ctx and inject to the specified sequence straight away. > > * Response Path* > >- The responses are injected to the out sequence specified by the user >- The received responses are intercepted at the Axis2Sender >- The response is set in its respective request message that was >suspended earlier. >- The suspended request is resumed. > > >- > > Thanks. > > Sandamal Weerasinghe | Software Engineer | WSO2 Lanka (Pvt) Ltd > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Implementing Http Inbound Endpoint Using Netty-IO
On Fri, Jul 25, 2014 at 11:43 AM, Isuru Ranawaka wrote: > hi all, > Implementation of the HTTP Inbound using Netty has been externalized as a > separate component in carbon mediation and now working on developing HTTP > Default Inbound Implementation using HTTP Core .We can register request > handlers for different inbound endpoints using single IO Reactor.SO same > reactor is capable of listening different ports and dispatch requests to > relevant handlers. > > +1 It is really good to have all these inbound EPs externalized from synapse. In addition, when we are implementing this with HTTPCore, we should be able to cater to PTT architecture, where we create the source pipe from the inbound EP and later consumed by axis2 based PT sender. > thanks > isurur > > > On Mon, Jul 21, 2014 at 1:41 PM, Sanjiva Weerawarana > wrote: > >> Oleg's reply below (forwarding with permission). >> >> So we should not just configuring HttpCore to listen on the new ports - I >> presume it has a way of registering different callbacks for different ports >> (which is what we need in order to handle them outside of the normal >> Synapse path). >> >> Sanjiva. >> >> On Mon, Jul 21, 2014 at 1:24 PM, Oleg Kalnichevski < >> o...@ok2consulting.com> wrote: >> >>> On Mon, 2014-07-21 at 13:00 +0530, Sanjiva Weerawarana wrote: >>> > Good point about the need to have different IO threads .. but that's >>> > then because of a limitation in HTTPCore .. at a C level you can >>> > listen for IO on multiple sockets at once. So ideally HTTPCore can be >>> > improved to support that .. or maybe it does already? Oleg? >>> > >>> >>> HttpCore was capable of listening on multiple ports while utilizing the >>> same I/O reactor and the same number of I/O dispatch threads since very >>> beginning (~ 2006). >>> >>> Oleg >>> >>> >>> > >>> > +1 for dropping Netty :-). >>> > >>> > >>> > Sanjiva. >>> > >>> > >>> > On Mon, Jul 21, 2014 at 8:31 AM, Kasun Indrasiri >>> > wrote: >>> > Hi Sanjiva, >>> > >>> > >>> > I think the problem we have with inbound HTTP and existing >>> > HTTP transport is that, they are completely isolated. So, even >>> > if we implement the new InboundEP implementation with >>> > HTTPCore, we cannot share the same listening IO reactor as >>> > with axis2 based PTT. So, each HTTP inbound EP have its own >>> > reactor running with its own config. >>> > >>> > >>> > The reason for start the initial implementation with Netty is >>> > to verify the Inbound synchronous behavior with an external >>> > HTTP library (for instance we may do something similar when >>> > implementing WS-RM Inbound EP with CXF). However, we better >>> > switch back to HTTPCore as the default HTTP Inbound endpoint >>> > as it is the default non-blocking HTTP library used across the >>> > board. >>> > >>> > >>> > Thanks, >>> > Kasun >>> > >>> > >>> > On Sat, Jul 19, 2014 at 3:55 PM, Sanjiva Weerawarana >>> > wrote: >>> > Isuru I assume you looked at using HttpCore itself to >>> > add this - can you point me to the discussion please? >>> > Having multiple NIO listeners affects the scaling >>> > config right - because normally you have n IO handling >>> > threads if you have n cores .. now you need to watch >>> > that across multiple libraries. >>> > >>> > >>> > Sanjiva. >>> > >>> > >>> > On Wed, Jul 16, 2014 at 10:37 AM, Isuru Ranawaka >>> > wrote: >>> > Hi Ravi, >>> > >>> > >>> > In Netty-IO, Server Bootstrap uses two >>> > EventLoopGroups one for accept connections and >>> > other for handle accepted connections. >>> > Accepted connections has one to one mapping >>> > with EventLoop. EventLoop is li
Re: [Architecture] Fwd: Kafka transport for WSO2 ESB
The inbound endpoint injects the message to sequence, but not a proxy service. With respective to ESB layer design, I think we are good to go ahead. Please start the parallel development of Kafka Inbound EP and connector. On Mon, Jul 7, 2014 at 2:38 PM, Ishara Cooray wrote: > Please refer the updated document. Kafka Transport for ESB > <https://docs.google.com/a/wso2.com/document/d/19Eq9JSynneAcwIrBfshP_S6qr0l6ydNjQp_tVMt3xTo/edit> > Thanks. > > Ishara Cooray > Senior Software Engineer > > +9477 262 9510 > > > On Mon, Jul 7, 2014 at 10:03 AM, Ishara Cooray wrote: > >> Hi Mohan, >> >> Thanks for the reply. >> >> Here KAFKA Connector publishes events to brokers where as Inbound >> transport consumes through zookeeper. >> >> >> >> >> Ishara Cooray >> Senior Software Engineer >> >> +9477 262 9510 >> >> >> On Sun, Jul 6, 2014 at 10:47 PM, Mohanadarshan Vivekanandalingam < >> mo...@wso2.com> wrote: >> >>> Hi Ishara, >>> >>> I believe you have gone through the Kafka documentation. AFAIK, to >>> consume events from kafka we communicate with zookeeper and to publish >>> events we dealt with brokers. Here ESB connector does both consuming and >>> publishing right ? .Then kafka connector needs to connect with zookeeper to >>> consume events isn't it ? Then it should reflect in the diagram right. >>> Please correct me if i am wrong.. >>> >>> Thanks, >>> Mohan >>> >>> >>> >>> >>> On Sun, Jul 6, 2014 at 12:57 PM, Ishara Cooray wrote: >>> >>>> >>>> Sending to architecture group >>>> >>>> Ishara Cooray >>>> Senior Software Engineer >>>> >>>> +9477 262 9510 >>>> >>>> >>>> -- Forwarded message -- >>>> From: Ishara Cooray >>>> Date: Sun, Jul 6, 2014 at 12:39 PM >>>> Subject: [Architecture] Kafka transport for WSO2 ESB >>>> To: >>>> Cc: Kasun Indrasiri , Srinath Perera , >>>> Samisa Abeysinghe , Kathees Rajendram < >>>> kath...@wso2.com> >>>> >>>> >>>> Hi, >>>> >>>> we have come up with a high level architecture design for the kafka >>>> transport, which is attached here with for your kind review. >>>> >>>> Architecture - kafka transport for ESB >>>> <https://docs.google.com/a/wso2.com/document/d/19Eq9JSynneAcwIrBfshP_S6qr0l6ydNjQp_tVMt3xTo/edit> >>>> >>>> >>>> Your feedback is highly appreciated. >>>> >>>> >>>> Thanks & Regards, >>>> Ishara Cooray >>>> Senior Software Engineer >>>> >>>> +9477 262 9510 >>>> >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *V. Mohanadarshan* >>> *Software Engineer,* >>> *Data Technologies Team,* >>> *WSO2, Inc. http://wso2.com <http://wso2.com> * >>> *lean.enterprise.middleware.* >>> >>> email: mo...@wso2.com >>> phone:(+94) 771117673 >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Fixing CApp story for Carbon 4.3.0
On Tue, Jul 1, 2014 at 8:03 PM, Kishanthan Thangarajah wrote: > Hi All, > > We recently had a meeting on $subject. Our current story for CApp (Carbon > Application) development approach is broken when including application of > QoS for services. This was mainly due to the issues we faced with, > > - the file-based metadata persistence layer for services. > - the possibility to change/apply QoS via mgt console. > - clustering and deployment synchronization. > > To fix these, as the first step, we have removed the file based > persistence layer from platform. This layer was mainly used to persist QoS > related settings of the axis2services. This can be replaced by using > services.xml file for each service. All types of axis2services (other than > proxy-services) has support for services.xml currently. For proxy services, > the application of some QoS (Ex: security) can be defined inline by > referring the relevant policies from registry. > > We need a meeting to discuss about the following next steps. > - How this will affect ESB (proxy-services) and how to fix those. > - Removing the current way of applying QoS via mgt console and providing a > different approach, which will not be part of the CApp development process. > > For security, we already have enable sec in the proxy configuration. For other QoS aspects such as throttling, tracing etc., AFAIR the plan is to completely remove that functionality and if some user needs it he has to do that through the API management layer. > Thanks, > Kishanthan. > > -- > *Kishanthan Thangarajah* > Senior Software Engineer, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* > Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Coordination support for Message Store and Processors
Hi, We need to support $subject. As we support coordination for ESB tasks through ntask integration, we can use the same concept to execute the message processor tasks too. The main objective is to execute a message processor on an elected worker node in a given cluster deployment. @Shafreen/Ishan : Any thoughts on the complexities involved with this. Thanks, -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Inbound Endpoint support for ESB
We need to test the coordination behavior of inbound endpoints and make sure it executes only on manager and an elected worker node. @Ishan : Please update the thread once we are done with the implementation/verification. On Mon, Apr 28, 2014 at 8:01 AM, Kasun Indrasiri wrote: > > > > On Mon, Apr 28, 2014 at 7:20 AM, Malaka Silva wrote: > >> Hi Kasun, >> >> Is there any reason why sequence is added as a different entry? >> >> Initially I thought about having inline message flows with in an inbound > config itself. May be it is more clear to have it as a reference. > I'm +1 for the syntax with the injecting sequence and fault sequence as > attributes. > > On a separate note, IMO we should use 'file' as the protocol instead of > 'vfs' (that's an implementation detail). > >> Current >> >> http://ws.apache.org/ns/synapse"; >> name="MyVFSListenerEP" >> protocol="vfs" interval="5" suspend="false"> >> >> > name="transport.vfs.FileURI">/home/malaka/work/vfs/files >> >> ftp://malaka:malaka@127.0.0.1/home/malaka/work/vfs/pro >> text/xml >> true >> >> * * >> >> >> Why not following? >> >> http://ws.apache.org/ns/synapse"; >> name="MyVFSListenerEP" >> protocol="vfs" >> *injectingSeq="requestHandlerSeq" onErrorSeq="inFalte"* >> interval="5" suspend="false"> >> >> > name="transport.vfs.FileURI">/home/malaka/work/vfs/files >> >> ftp://malaka:malaka@127.0.0.1/home/malaka/work/vfs/pro >> text/xml >> true >> >> >> >> Best Regards, >> Malaka >> >> >> On Fri, Apr 25, 2014 at 9:07 PM, Sriskandarajah Suhothayan > > wrote: >> >>> Great :) >>> >>> Thanks >>> Suho >>> >>> >>> On Fri, Apr 25, 2014 at 8:33 PM, Malaka Silva wrote: >>> >>>> Hi Suho, >>>> >>>> That is the main idea. We are moving the message build and sequence >>>> injection part to a handle for VFS and Inbound. >>>> >>>> Anyone can reuse this and get the raw output. >>>> >>>> Best Regards, >>>> Malaka >>>> >>>> >>>> On Fri, Apr 25, 2014 at 5:44 PM, Sriskandarajah Suhothayan < >>>> s...@wso2.com> wrote: >>>> >>>>> Thanks, This code reuse is very useful. >>>>> CEP team will start integrating when this its ready. >>>>> >>>>> Regards >>>>> Suho >>>>> >>>>> >>>>> On Fri, Apr 25, 2014 at 4:24 PM, Kasun Indrasiri >>>>> wrote: >>>>> >>>>>> Hi Suho, >>>>>> >>>>>> As per the offline chat we had, we did change the design so that we >>>>>> can obtain the native format and we can register a handler which can >>>>>> build >>>>>> the message in to any required format. Malaka is working on applying >>>>>> these >>>>>> changes and lets do a review once we have it up and running. >>>>>> >>>>>> >>>>>> On Mon, Apr 21, 2014 at 10:07 AM, Sriskandarajah Suhothayan < >>>>>> s...@wso2.com> wrote: >>>>>> >>>>>>> Great :) >>>>>>> Please make then to work in their native form. >>>>>>> i.e When using the JMS Utils they will return the message received >>>>>>> in the native format itself (XML, JSON, Map) and it will not auto >>>>>>> convert >>>>>>> all messages to XML like what axis2 JMS transport was doing etc. >>>>>>> >>>>>>> We'll work with you on the integration >>>>>>> >>>>>>> Thanks >>>>>>> Suho >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 21, 2014 at 9:56 AM, Kasun Indrasiri >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Suho, >>>>>>>> >>>>>>>> We are not dependent on any axis2 related transport. The generic >>>>>>>> functionalit
Re: [Architecture] Type-aware mediators for ESB
In addition, all the connectors that are having interfaces other than XML needs to be modified so that connector accepts the same message type(i.e. json) as the backend API. On Wed, May 21, 2014 at 6:17 PM, Jeewantha Dharmaparakrama < jeewan...@wso2.com> wrote: > Hi All, > > We should be able to add the input/output types into the connector.xml > file for all connectors. Since DevS does not instantiate anything for > connectors we cant take use of the invoke mediator. For all other type > aware mediators DevS can use the getInputType() getOutputType() methods > WDYT?. > > Jeewantha > > > On Wed, May 21, 2014 at 11:22 AM, Kasun Indrasiri wrote: > >> Hi Viraj, >> >> When generating a connector invoke mediator out of a connector, we can >> extract the supported data format from the connector and set that as the >> input and output type of that mediator. The idea is to use single api to >> extract the input and output type across all mediators. Lets have a review, >> once we are done with the modifications from the ESB side. >> >> >> On Wed, May 21, 2014 at 2:56 AM, Viraj Rajaguru wrote: >> >>> Hi, >>> >>> When we consider putting Data mapper mediator in between two connector >>> operations in Developer Studio, we can use following steps to deduce input >>> and output types for Data mapper mediator without asking user to provide >>> them. >>> >>>1. Since we are going to include the supported message type or media >>>type for a certain connector in connector.xml or component.xml (in >>>connector archive), we can automatically set input and output types for >>> the >>>connector operation upon the dragging and dropping an connector operation >>>into the canvas. >>>2. When we add a Data Mapper mediator in between two connectors in >>>DevS, we can traverse back and forth to retrieve data types of two >>> adjacent >>>connectors and can set correct input and output types for the Data Mapper >>>mediator without asking user to set input and output datatypes. >>> >>> >>> *Implementation details for 'type aware' concept in Developer Studio.* >>> >>> We are maintaining a similar object model as ESB for mediators, >>> endpoints etc within Developer Studio using EMF. So that we also need to >>> introduce 'inputType' and 'outputType' attributes at Abstract Mediator >>> level in DevS model. Then type aware mediators can use those attributes to >>> persist input and output types(user provided type or automatically derived >>> type from adjacent type aware mediators) and can use them while generating >>> the required ESB configuration. >>> >>> >>> Thanks, >>> Viraj. >>> >>> >>> On Tue, May 20, 2014 at 10:53 PM, Kasun Indrasiri wrote: >>> >>>> DM between Connector invocations is the prime candidate for the >>>> application of this concept. As we are quite certain on what needs to be >>>> done from ESB level, we have to work closely with the DevS to get the story >>>> right. >>>> >>>> >>>> On Tue, May 20, 2014 at 5:18 PM, Jeewantha Dharmaparakrama < >>>> jeewan...@wso2.com> wrote: >>>> >>>>> As we discussed we will be adding getInputType() getOutputType() >>>>> methods in the AbstractMediator which can be overridden by the Type aware >>>>> mediators. Type aware mediators can be >>>>> >>>>> * All connectors >>>>> * All transformation mediators >>>>> * Enrich >>>>> * Property (When xpath, json path is used) >>>>> etc >>>>> >>>>> There are non-type aware mediators like >>>>> *** send >>>>> * property with no xpaths/json paths. >>>>> etc >>>>> >>>>> Also there is a third category where the input/output types are not >>>>> defined or can change dynamically. For example >>>>> * switch >>>>> * filter >>>>> etc >>>>> >>>>> So when Data Mapper mediator is used within DevS in-between two type >>>>> aware mediators, it can figure out the correct input output types by >>>>> callling the corresponding methods of the two adjacent mediators in the >>>>> sequence. If it cannot figure out the input/output types, the user will >>>>&
Re: [Architecture] Mediation Debugger For WSO2 ESB GSoC 2014
>>> >>>>> Past few weeks I have been following working examples of debuggers >>>>> written using eclipse debug framework in order to get good understanding >>>>> of >>>>> how debug framework can be used to develop custom debuggers.[1][2][3] Also >>>>> I have covered to some extent of eclipse debug API documentation. >>>>> >>>>> As mentioned in my proposal, I have implemented to some extent >>>>> deliverable 1 ESB extension point to plug ESB to a debug plugin as >>>>> according to the communication protocol defined. During the community >>>>> bonding period I would like to continue working on the deliverable 1 with >>>>> WSO2 coding standards and test it s functionality using a Simple Java TCP >>>>> client with ESB server runtime without testing it s integration with the >>>>> eclipse debug as it is not completed yet. >>>>> >>>>> Also I have studied Eclipse launching framework and documentation to >>>>> some extent and I would like to continue studying on them more during the >>>>> community >>>>> bonding period. Also I have gathered some background knowledge on how to >>>>> instantiate WSO2 ESB instance inside a java program so that it would help >>>>> me to write the launch delegate class which is the core of the ESB >>>>> launcher >>>>> for debug plugin. I also encountered some problems I would like to share >>>>> them with you too.[4] >>>>> >>>>> Without Integrating the debug plugin to be working with DevStudio >>>>> graphical editor, as a starting point I would like to work towards, to set >>>>> break points using the the eclipse default AbstractTextEditor for synapse >>>>> configuration xml. As this would help me test the full functionality and >>>>> also it is convenient as there is default implementation is available for >>>>> line based/oriented breakpoints in the debug framework it self. This may >>>>> be >>>>> further extended to set breakpoints using devStudio graphical editor. >>>>> >>>> >>>> In ESB graphical editor plugin we have a source editor which is >>>> extended by "org.eclipse.wst.sse.ui.StructuredTextEditor". This >>>> 'StructuredTextEditor' class has been extended by >>>> "org.eclipse.ui.texteditor.AbstractTextEditor". You can use ESB graphical >>>> editor's source view/editor to set breakpoints for synapse configuration >>>> xml at the initial stage. >>>> >>>> Thanks, >>>> Viraj. >>>> >>>>> >>>>> These are the things I am working within this community bonding >>>>> period before the GSoC coding period starts.Comments and suggestions >>>>> are really appreciated. I have presented them briefly and I would like to >>>>> discuss them more with you. If you want anything further to clarify just >>>>> please let me know. I would like to start work on them early so it that it >>>>> spare enough time for me to complete the project. >>>>> >>>>> [1]eclipse debugger for perl interpreter >>>>> http://www.eclipse.org/articles/Article-Debugger/how-to.html >>>>> [2]eclipse debugger for Embedded systems Software >>>>> http://fmt.cs.utwente.nl/files/sprojects/22.pdf >>>>> [3]eclipse debugger for text interpreter >>>>> >>>>> http://codeandme.blogspot.com/2013/11/debugger-3-tale-of-debuggers-processes.html >>>>> [4]Launcher for JAVA applets. >>>>> http://www.eclipse.org/articles/Article-Launch-Framework/launch.html >>>>> >>>>> Regards >>>>> Kevin >>>>> >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Viraj Rajaguru >>>> Software Engineer >>>> WSO2 Inc. : http://wso2.com >>>> >>>> Mobile: +94 77 3683068 >>>> >>>> >>>> >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Isuru Udana* >>> Senior >>> * Software Engineer* >>> WSO2 Inc.; http://wso2.com >>> email: isu...@wso2.com cell: +94 77 3791887 >>> blog: http://mytecheye.blogspot.com/ >>> twitter: http://twitter.com/isudana >>> >> >> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Type-aware mediators for ESB
Hi Viraj, When generating a connector invoke mediator out of a connector, we can extract the supported data format from the connector and set that as the input and output type of that mediator. The idea is to use single api to extract the input and output type across all mediators. Lets have a review, once we are done with the modifications from the ESB side. On Wed, May 21, 2014 at 2:56 AM, Viraj Rajaguru wrote: > Hi, > > When we consider putting Data mapper mediator in between two connector > operations in Developer Studio, we can use following steps to deduce input > and output types for Data mapper mediator without asking user to provide > them. > >1. Since we are going to include the supported message type or media >type for a certain connector in connector.xml or component.xml (in >connector archive), we can automatically set input and output types for the >connector operation upon the dragging and dropping an connector operation >into the canvas. >2. When we add a Data Mapper mediator in between two connectors in >DevS, we can traverse back and forth to retrieve data types of two adjacent >connectors and can set correct input and output types for the Data Mapper >mediator without asking user to set input and output datatypes. > > > *Implementation details for 'type aware' concept in Developer Studio.* > > We are maintaining a similar object model as ESB for mediators, endpoints > etc within Developer Studio using EMF. So that we also need to introduce > 'inputType' and 'outputType' attributes at Abstract Mediator level in DevS > model. Then type aware mediators can use those attributes to persist input > and output types(user provided type or automatically derived type > from adjacent type aware mediators) and can use them while generating > the required ESB configuration. > > > Thanks, > Viraj. > > > On Tue, May 20, 2014 at 10:53 PM, Kasun Indrasiri wrote: > >> DM between Connector invocations is the prime candidate for the >> application of this concept. As we are quite certain on what needs to be >> done from ESB level, we have to work closely with the DevS to get the story >> right. >> >> >> On Tue, May 20, 2014 at 5:18 PM, Jeewantha Dharmaparakrama < >> jeewan...@wso2.com> wrote: >> >>> As we discussed we will be adding getInputType() getOutputType() methods >>> in the AbstractMediator which can be overridden by the Type aware >>> mediators. Type aware mediators can be >>> >>> * All connectors >>> * All transformation mediators >>> * Enrich >>> * Property (When xpath, json path is used) >>> etc >>> >>> There are non-type aware mediators like >>> *** send >>> * property with no xpaths/json paths. >>> etc >>> >>> Also there is a third category where the input/output types are not >>> defined or can change dynamically. For example >>> * switch >>> * filter >>> etc >>> >>> So when Data Mapper mediator is used within DevS in-between two type >>> aware mediators, it can figure out the correct input output types by >>> callling the corresponding methods of the two adjacent mediators in the >>> sequence. If it cannot figure out the input/output types, the user will >>> manually have to specify the corresponding types. >>> >>> Thanks, >>> Jeewantha >>> >>> >>> On Fri, May 16, 2014 at 7:47 AM, Malaka Silva wrote: >>> >>>> Hi, >>>> >>>> With related to connectors I guess main idea here is to have different >>>> connectors in a flow which can integrate with each other. I think recipes >>>> will definitely benefit from this. >>>> >>>> In the case of connectors both input and output will always be same. We >>>> can specific this in init method of the connector definition. >>>> >>>> >>>> On Tue, May 13, 2014 at 5:07 PM, Kasun Indrasiri wrote: >>>> >>>>> Hi, >>>>> >>>>> We been working on the initial design of the type-aware mediator >>>>> concept for ESB. The main objective of this is to have an input and output >>>>> type for the mediators so that transformation mediators(such as DataMapper >>>>> mediator) can decide its input and output type dynamically. >>>>> >>>>> - One of the common use case of this is that data mapping between two >>>>> connectors operations . >>>>> >>>&g
Re: [Architecture] Type-aware mediators for ESB
DM between Connector invocations is the prime candidate for the application of this concept. As we are quite certain on what needs to be done from ESB level, we have to work closely with the DevS to get the story right. On Tue, May 20, 2014 at 5:18 PM, Jeewantha Dharmaparakrama < jeewan...@wso2.com> wrote: > As we discussed we will be adding getInputType() getOutputType() methods > in the AbstractMediator which can be overridden by the Type aware > mediators. Type aware mediators can be > > * All connectors > * All transformation mediators > * Enrich > * Property (When xpath, json path is used) > etc > > There are non-type aware mediators like > *** send > * property with no xpaths/json paths. > etc > > Also there is a third category where the input/output types are not > defined or can change dynamically. For example > * switch > * filter > etc > > So when Data Mapper mediator is used within DevS in-between two type aware > mediators, it can figure out the correct input output types by callling the > corresponding methods of the two adjacent mediators in the sequence. If it > cannot figure out the input/output types, the user will manually have to > specify the corresponding types. > > Thanks, > Jeewantha > > > On Fri, May 16, 2014 at 7:47 AM, Malaka Silva wrote: > >> Hi, >> >> With related to connectors I guess main idea here is to have different >> connectors in a flow which can integrate with each other. I think recipes >> will definitely benefit from this. >> >> In the case of connectors both input and output will always be same. We >> can specific this in init method of the connector definition. >> >> >> On Tue, May 13, 2014 at 5:07 PM, Kasun Indrasiri wrote: >> >>> Hi, >>> >>> We been working on the initial design of the type-aware mediator concept >>> for ESB. The main objective of this is to have an input and output type for >>> the mediators so that transformation mediators(such as DataMapper mediator) >>> can decide its input and output type dynamically. >>> >>> - One of the common use case of this is that data mapping between two >>> connectors operations . >>> >>> .. input and output : json >>> ---> Deduce the input and output message type by inspecting >>> the successor and the predecessor mediators. >>> .. input and output : soap >>> >>> >>> - In scenarios such as PayloadFactory the user provides the input type >>> and the output type >>> >>> e.g : .. input - JSON, output - XML etc. >>> >>> >>> - Some mediators won't have an input or output type and they are >>> non-type aware : eg: send, property etc. >>> >>> - All connectors should have the supported message/media type as an >>> attribute and that should be the same as the original API. (If the backend >>> API is JSON then the connector's input and output types will be JSON). The >>> supported message type or media-type will be an attribute of a given >>> connector and we can specific that in component.xml(in connector archive) >>> of a specific connector. >>> >>> Taks list: >>> >>> Mediation Engine : >>> - Introduce inputType and outputType at abstract mediator level. >>> - Message flow verification based on input and output types. This >>> includes verification of connector invocations (call-templates for >>> connectors). >>> - Review/refactor mediators such as Payload factory to incorporate type >>> aware concept. >>> >>> Connectors : >>> - Introduce type concept in to connectors (new versions of existing >>> connectors) >>> - Connector invocation (call-template) deployment should verify input >>> and output types during the deployment time. >>> >>> We have started working on a poc on type-aware mediation concept and >>> please share your thoughts too. >>> >>> Thanks. >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Best Regards, >> >> Malaka Silva >> Senior T
[Architecture] Type-aware mediators for ESB
Hi, We been working on the initial design of the type-aware mediator concept for ESB. The main objective of this is to have an input and output type for the mediators so that transformation mediators(such as DataMapper mediator) can decide its input and output type dynamically. - One of the common use case of this is that data mapping between two connectors operations . .. input and output : json ---> Deduce the input and output message type by inspecting the successor and the predecessor mediators. .. input and output : soap - In scenarios such as PayloadFactory the user provides the input type and the output type e.g : .. input - JSON, output - XML etc. - Some mediators won't have an input or output type and they are non-type aware : eg: send, property etc. - All connectors should have the supported message/media type as an attribute and that should be the same as the original API. (If the backend API is JSON then the connector's input and output types will be JSON). The supported message type or media-type will be an attribute of a given connector and we can specific that in component.xml(in connector archive) of a specific connector. Taks list: Mediation Engine : - Introduce inputType and outputType at abstract mediator level. - Message flow verification based on input and output types. This includes verification of connector invocations (call-templates for connectors). - Review/refactor mediators such as Payload factory to incorporate type aware concept. Connectors : - Introduce type concept in to connectors (new versions of existing connectors) - Connector invocation (call-template) deployment should verify input and output types during the deployment time. We have started working on a poc on type-aware mediation concept and please share your thoughts too. Thanks. -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Inbound Endpoint support for ESB
On Mon, Apr 28, 2014 at 7:20 AM, Malaka Silva wrote: > Hi Kasun, > > Is there any reason why sequence is added as a different entry? > > Initially I thought about having inline message flows with in an inbound config itself. May be it is more clear to have it as a reference. I'm +1 for the syntax with the injecting sequence and fault sequence as attributes. On a separate note, IMO we should use 'file' as the protocol instead of 'vfs' (that's an implementation detail). > Current > > http://ws.apache.org/ns/synapse"; > name="MyVFSListenerEP" > protocol="vfs" interval="5" suspend="false"> > > name="transport.vfs.FileURI">/home/malaka/work/vfs/files > > ftp://malaka:malaka@127.0.0.1/home/malaka/work/vfs/pro > text/xml > true > > * * > > > Why not following? > > http://ws.apache.org/ns/synapse"; > name="MyVFSListenerEP" > protocol="vfs" > *injectingSeq="requestHandlerSeq" onErrorSeq="inFalte"* > interval="5" suspend="false"> > > name="transport.vfs.FileURI">/home/malaka/work/vfs/files > > ftp://malaka:malaka@127.0.0.1/home/malaka/work/vfs/pro > text/xml > true > > > > Best Regards, > Malaka > > > On Fri, Apr 25, 2014 at 9:07 PM, Sriskandarajah Suhothayan > wrote: > >> Great :) >> >> Thanks >> Suho >> >> >> On Fri, Apr 25, 2014 at 8:33 PM, Malaka Silva wrote: >> >>> Hi Suho, >>> >>> That is the main idea. We are moving the message build and sequence >>> injection part to a handle for VFS and Inbound. >>> >>> Anyone can reuse this and get the raw output. >>> >>> Best Regards, >>> Malaka >>> >>> >>> On Fri, Apr 25, 2014 at 5:44 PM, Sriskandarajah Suhothayan < >>> s...@wso2.com> wrote: >>> >>>> Thanks, This code reuse is very useful. >>>> CEP team will start integrating when this its ready. >>>> >>>> Regards >>>> Suho >>>> >>>> >>>> On Fri, Apr 25, 2014 at 4:24 PM, Kasun Indrasiri wrote: >>>> >>>>> Hi Suho, >>>>> >>>>> As per the offline chat we had, we did change the design so that we >>>>> can obtain the native format and we can register a handler which can build >>>>> the message in to any required format. Malaka is working on applying >>>>> these >>>>> changes and lets do a review once we have it up and running. >>>>> >>>>> >>>>> On Mon, Apr 21, 2014 at 10:07 AM, Sriskandarajah Suhothayan < >>>>> s...@wso2.com> wrote: >>>>> >>>>>> Great :) >>>>>> Please make then to work in their native form. >>>>>> i.e When using the JMS Utils they will return the message received in >>>>>> the native format itself (XML, JSON, Map) and it will not auto convert >>>>>> all >>>>>> messages to XML like what axis2 JMS transport was doing etc. >>>>>> >>>>>> We'll work with you on the integration >>>>>> >>>>>> Thanks >>>>>> Suho >>>>>> >>>>>> >>>>>> On Mon, Apr 21, 2014 at 9:56 AM, Kasun Indrasiri wrote: >>>>>> >>>>>>> Hi Suho, >>>>>>> >>>>>>> We are not dependent on any axis2 related transport. The generic >>>>>>> functionalities related to protocols such as JMS and VFS are >>>>>>> implemented as >>>>>>> Utils. >>>>>>> So, we should be able to reuse them with in CEP too. >>>>>>> >>>>>>> >>>>>>> On Sat, Apr 19, 2014 at 10:37 AM, Sriskandarajah Suhothayan < >>>>>>> s...@wso2.com> wrote: >>>>>>> >>>>>>>> @Kasun >>>>>>>> >>>>>>>> Can you elaborate a bit on the backend. >>>>>>>> Are we reusing/improving the Axis2 JMS transport or will this be a >>>>>>>> new implementation or module ? >>>>>>>> >>>>>>>> This is because CEP a
Re: [Architecture] Inbound Endpoint support for ESB
Hi Suho, As per the offline chat we had, we did change the design so that we can obtain the native format and we can register a handler which can build the message in to any required format. Malaka is working on applying these changes and lets do a review once we have it up and running. On Mon, Apr 21, 2014 at 10:07 AM, Sriskandarajah Suhothayan wrote: > Great :) > Please make then to work in their native form. > i.e When using the JMS Utils they will return the message received in the > native format itself (XML, JSON, Map) and it will not auto convert all > messages to XML like what axis2 JMS transport was doing etc. > > We'll work with you on the integration > > Thanks > Suho > > > On Mon, Apr 21, 2014 at 9:56 AM, Kasun Indrasiri wrote: > >> Hi Suho, >> >> We are not dependent on any axis2 related transport. The generic >> functionalities related to protocols such as JMS and VFS are implemented as >> Utils. >> So, we should be able to reuse them with in CEP too. >> >> >> On Sat, Apr 19, 2014 at 10:37 AM, Sriskandarajah Suhothayan < >> s...@wso2.com> wrote: >> >>> @Kasun >>> >>> Can you elaborate a bit on the backend. >>> Are we reusing/improving the Axis2 JMS transport or will this be a new >>> implementation or module ? >>> >>> This is because CEP also has use-cases on working with JMS Brokers so >>> its good if CEP can also reuse this implementation. >>> >>> Regards >>> Suho >>> >>> >>> On Wed, Apr 16, 2014 at 2:08 PM, Kasun Indrasiri wrote: >>> >>>> We need to finalize the tooling aspect of this too. Ideally this is >>>> another entry point to ESB, which is very similar to a proxy service or a >>>> REST api. Any thoughts on how we should proceed with the tooling aspect of >>>> this? >>>> >>>> >>>> On Wed, Apr 9, 2014 at 3:01 PM, Kasun Indrasiri wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Mon, Apr 7, 2014 at 10:18 PM, Sanjiva Weerawarana >>>> > wrote: >>>>> >>>>>> I don't understand what doesn't support MT means in this case. Lets >>>>>> take SMTP- each inbound endpoint will give its own email address and poll >>>>>> from that. Where's MTness involved? >>>>>> >>>>>> Isn't the same true or JMS? You just give a queue - its someone >>>>>> else's problem to make sure queues are properly allocated and protected. >>>>>> >>>>>> Yeah, I think if we consider a scenario where ESB and MB are >>>>> involved. A given user can create a queue in MB and MB will take care of >>>>> adding required info( such as appending tenant domain etc) in to the queue >>>>> name (similar logic should apply when we create a subscription too). Then >>>>> we create the inbound endpoint, we should give the exact same destination. >>>>> If we are using any other broker, then it is up to the broker to handle >>>>> security etc. >>>>> >>>>>> Sanjiva. >>>>>> >>>>>> >>>>>> On Fri, Apr 4, 2014 at 10:51 AM, Kasun Indrasiri wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We have been working on the initial design for the Inbound Endpoint >>>>>>> support for ESB. >>>>>>> >>>>>>> - Inbound endpoint is a dynamically configured message source for >>>>>>> ESB. >>>>>>> - The current axis2 based transports other than HTTP/S doesn't work >>>>>>> in multitenant mode. The main idea is to supporting all transport (not >>>>>>> only >>>>>>> HTTP) in multi-tenant mode with the introduction of inbound endpoints. >>>>>>> - The inbound endpoints will have multiple behavior based on >>>>>>> implementation: polling, busy wait or listening. >>>>>>> - In W/M separated setups, the coordination requirements for polling >>>>>>> behavior is handled by taks which is based on ntasks. >>>>>>> >>>>>>> This is the initial syntax we came up with: >>>>>>> >>>>>>> >>>>>> >>>>>>>protocol="jms" >>>>>&g
Re: [Architecture] Inbound Endpoint support for ESB
Hi Suho, We are not dependent on any axis2 related transport. The generic functionalities related to protocols such as JMS and VFS are implemented as Utils. So, we should be able to reuse them with in CEP too. On Sat, Apr 19, 2014 at 10:37 AM, Sriskandarajah Suhothayan wrote: > @Kasun > > Can you elaborate a bit on the backend. > Are we reusing/improving the Axis2 JMS transport or will this be a new > implementation or module ? > > This is because CEP also has use-cases on working with JMS Brokers so its > good if CEP can also reuse this implementation. > > Regards > Suho > > > On Wed, Apr 16, 2014 at 2:08 PM, Kasun Indrasiri wrote: > >> We need to finalize the tooling aspect of this too. Ideally this is >> another entry point to ESB, which is very similar to a proxy service or a >> REST api. Any thoughts on how we should proceed with the tooling aspect of >> this? >> >> >> On Wed, Apr 9, 2014 at 3:01 PM, Kasun Indrasiri wrote: >> >>> >>> >>> >>> On Mon, Apr 7, 2014 at 10:18 PM, Sanjiva Weerawarana >>> wrote: >>> >>>> I don't understand what doesn't support MT means in this case. Lets >>>> take SMTP- each inbound endpoint will give its own email address and poll >>>> from that. Where's MTness involved? >>>> >>>> Isn't the same true or JMS? You just give a queue - its someone else's >>>> problem to make sure queues are properly allocated and protected. >>>> >>>> Yeah, I think if we consider a scenario where ESB and MB are involved. >>> A given user can create a queue in MB and MB will take care of adding >>> required info( such as appending tenant domain etc) in to the queue name >>> (similar logic should apply when we create a subscription too). Then we >>> create the inbound endpoint, we should give the exact same destination. If >>> we are using any other broker, then it is up to the broker to handle >>> security etc. >>> >>>> Sanjiva. >>>> >>>> >>>> On Fri, Apr 4, 2014 at 10:51 AM, Kasun Indrasiri wrote: >>>> >>>>> Hi, >>>>> >>>>> We have been working on the initial design for the Inbound Endpoint >>>>> support for ESB. >>>>> >>>>> - Inbound endpoint is a dynamically configured message source for ESB. >>>>> - The current axis2 based transports other than HTTP/S doesn't work in >>>>> multitenant mode. The main idea is to supporting all transport (not only >>>>> HTTP) in multi-tenant mode with the introduction of inbound endpoints. >>>>> - The inbound endpoints will have multiple behavior based on >>>>> implementation: polling, busy wait or listening. >>>>> - In W/M separated setups, the coordination requirements for polling >>>>> behavior is handled by taks which is based on ntasks. >>>>> >>>>> This is the initial syntax we came up with: >>>>> >>>>> >>>> >>>>>protocol="jms" >>>>> >>>>>interval="1000" suspend="false"> >>>>> >>>>> >>>>> >>>>> >>>> name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory >>>>> >>>>>>>>> name="java.naming.provider.url">tcp://localhost:61616 >>>>> >>>>>>>>> name="jms.ConnectionFactoryJNDIName">QueueConnectionFactory >>>>> >>>>>queue >>>>> >>>>>ordersQueue >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The inbound endpoint will be a new construct in ESB which goes at the >>>>> top level as with proxy services, APIs etc. >>>>> >>>>> I have completed the initial work related to inbound EP and >>>>> implemented a basic JMS inbound EP. Also I've verified the functionality >>>>> in >>>>> super tenant and tenant mode as well. >>>>> Ravi is working on getting the end to end scenario working for JMS >>>>> Inbound EP. >>>>> >>>>> Please review the design and share your thoughts. >>>>> >&
Re: [Architecture] Inbound Endpoint support for ESB
We need to finalize the tooling aspect of this too. Ideally this is another entry point to ESB, which is very similar to a proxy service or a REST api. Any thoughts on how we should proceed with the tooling aspect of this? On Wed, Apr 9, 2014 at 3:01 PM, Kasun Indrasiri wrote: > > > > On Mon, Apr 7, 2014 at 10:18 PM, Sanjiva Weerawarana wrote: > >> I don't understand what doesn't support MT means in this case. Lets take >> SMTP- each inbound endpoint will give its own email address and poll from >> that. Where's MTness involved? >> >> Isn't the same true or JMS? You just give a queue - its someone else's >> problem to make sure queues are properly allocated and protected. >> >> Yeah, I think if we consider a scenario where ESB and MB are involved. A > given user can create a queue in MB and MB will take care of adding > required info( such as appending tenant domain etc) in to the queue name > (similar logic should apply when we create a subscription too). Then we > create the inbound endpoint, we should give the exact same destination. If > we are using any other broker, then it is up to the broker to handle > security etc. > >> Sanjiva. >> >> >> On Fri, Apr 4, 2014 at 10:51 AM, Kasun Indrasiri wrote: >> >>> Hi, >>> >>> We have been working on the initial design for the Inbound Endpoint >>> support for ESB. >>> >>> - Inbound endpoint is a dynamically configured message source for ESB. >>> - The current axis2 based transports other than HTTP/S doesn't work in >>> multitenant mode. The main idea is to supporting all transport (not only >>> HTTP) in multi-tenant mode with the introduction of inbound endpoints. >>> - The inbound endpoints will have multiple behavior based on >>> implementation: polling, busy wait or listening. >>> - In W/M separated setups, the coordination requirements for polling >>> behavior is handled by taks which is based on ntasks. >>> >>> This is the initial syntax we came up with: >>> >>> >> >>>protocol="jms" >>> >>>interval="1000" suspend="false"> >>> >>> >>> >>> >> name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory >>> >>>>> name="java.naming.provider.url">tcp://localhost:61616 >>> >>>>> name="jms.ConnectionFactoryJNDIName">QueueConnectionFactory >>> >>>queue >>> >>>ordersQueue >>> >>> >>> >>> >>> >>> >>> >>> >>> The inbound endpoint will be a new construct in ESB which goes at the >>> top level as with proxy services, APIs etc. >>> >>> I have completed the initial work related to inbound EP and implemented >>> a basic JMS inbound EP. Also I've verified the functionality in super >>> tenant and tenant mode as well. >>> Ravi is working on getting the end to end scenario working for JMS >>> Inbound EP. >>> >>> Please review the design and share your thoughts. >>> >>> Thanks, >>> Kasun >>> >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >> >> >> >> -- >> Sanjiva Weerawarana, Ph.D. >> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >> email: sanj...@wso2.com; office: (+1 650 745 4499 | +94 11 214 5345) >> x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311 >> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >> >> Lean . Enterprise . Middleware >> > > > > -- > Kasun Indrasiri > Software Architect > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +94 77 556 5206 > Blog : http://kasunpanorama.blogspot.com/ > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Integrating ntask component into ESB
Did you check whether the required packages are osgi imported properly? On a separate note, what's the ETA of a working deliverable of this? On Sun, Apr 13, 2014 at 12:43 PM, Anjana Fernando wrote: > Obviously, check if that class is available and where it is referred from > in the code. As I remember, there isn't a package called "ntaskint", so > check where this is coming from. > > Cheers, > Anjana. > > > On Sat, Apr 12, 2014 at 6:46 AM, Ishan Jayawardena wrote: > >> We developed the quartz task manager and we are currently working on the >> ntask task manager. While developing the task handling component that uses >> ntask, we observed that we cannot schedule a task in it due to a class not >> found error. See the below error message. The ntask component (which is >> used by the component that we are currently writing) cannot load the actual >> task implementation. Does anyone know how to get rid of this? >> >> java.lang.ClassNotFoundException: class org.wso2.carbon.ntaskint.core.Task >> at >> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501) >> at >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421) >> at >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412) >> at >> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) >> at java.lang.ClassLoader.loadClass(ClassLoader.java:247) >> at >> org.wso2.carbon.ntask.core.impl.TaskQuartzJobAdapter.execute(TaskQuartzJobAdapter.java:58) >> at org.quartz.core.JobRunShell.run(JobRunShell.java:213) >> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) >> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) >> at java.util.concurrent.FutureTask.run(FutureTask.java:138) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) >> at java.lang.Thread.run(Thread.java:662) >> Thanks, >> Ishan. >> >> >> >> On Mon, Apr 7, 2014 at 9:11 AM, Anjana Fernando wrote: >> >>> Hi Paul, >>> >>> Task Server is actually another server itself. NTask component is the >>> task scheduling component we put to all our Carbon server when we need >>> distributed task scheduling functionality. That component support >>> scheduling tasks in a standalone manner (in a single server), or in a >>> clustered mode for the distributed nature (it does the coordination using >>> Hazelcast), or else, also a "remote" mode where it can interface with an >>> external Task Server. >>> >>> So basically the full required functionality of distributed tasks can be >>> achieved with the ntask component working in the clustered mode, where it >>> identifies all the participating servers in the cluster and do the proper >>> fail-over/load balanced scheduling of scheduled tasks. And they schedule >>> the tasks themselves using their internal Quartz functionality. With TS, >>> all the task triggering is offloaded to TS, where it will be sending HTTP >>> messages to each server saying to execute the tasks. This should happen >>> through the LB as I explained in the earlier mail. >>> >>> So basically Task Server = ntask component + remote tasks component. >>> What any other Carbon server will need is just the ntask component for full >>> task scheduling functionality. >>> >>> Cheers, >>> Anjana. >>> >>> >>> On Sat, Apr 5, 2014 at 1:43 PM, Paul Fremantle wrote: >>> >>>> Can someone clarify? I'm lost but I really don't understand why we are >>>> creating any other approach than task server. It is the only approach that >>>> scales clearly. Is our task server code too heavyweight? >>>> >>>> Paul >>>> >>>> >>>> On 5 April 2014 08:47, Chanaka Fernando wrote: >>>> >>>>> Hi Kasun/Anjana, >>>>> >>>>> I think what Anjana mentioned and Ishan mentioned are somewhat >>>>> converge to same idea (even though they looks different). >>>>> >>>>> What we have discussed and agreed was that we are developing a >>>>> separate carbon-component which is used for executing the ntask component. >>>>> Since we need a common interface to support both the existing quartz based
