I'm not familiar with the subjected mediator, but I read the whole thread and I'm too -1 on reinventing the wheel without any strong valid reason. It's a violation of basic Software Engineering principles.
On Sun, Jun 16, 2013 at 5:56 PM, Maninda Edirisooriya <mani...@wso2.com>wrote: > > On Sun, Jun 16, 2013 at 3:21 PM, Sriskandarajah Suhothayan > <s...@wso2.com>wrote: > >> >> >> >> On Sun, Jun 16, 2013 at 12:11 PM, Maninda Edirisooriya >> <mani...@wso2.com>wrote: >> >>> >>> On Sun, Jun 16, 2013 at 11:08 AM, Tharindu Mathew <thari...@wso2.com>wrote: >>> >>>> Re-writing is fine if there is a sufficient reason to do so. But, I >>>> went through your XML definition and there's no magic there. I don't see >>>> anything in your configuration that is not possible now and if there are >>>> any gaps (namespaces? we used property mediator as a workaround for this >>>> until now) it can be fixed. Saying what you have presented is more usable >>>> and more configurable "is" a religious argument without any measurable >>>> proof. >>>> >>>> And, moreover there are additional features like definable BAM Server >>>> Profiles that's possible with the current mediator. This is extremely >>>> useful when the users have multiple stream definitions to publish. If there >>>> is any consolation, the UI is also pretty comprehensive to support this >>>> (but this is irrelevant once, DevS support is done). >>>> >>>> If there are any improvements then we can merge it. Re-writing should >>>> be done if there is something that is so completely wrong that it cannot be >>>> fixed (Ex: BAM2 vs BAM1). >>> >>> >>> +1. This is exactly what I tried to say. We can merge the changes if >>> there are any. If any issues we can fix. Writing a new one may not be the >>> solution unless there is a significant issue that cannot be fixed. Hope you >>> would agree with me. >>> >> >> I totally agree, IMHO in BAM mediator the BAM Server Profiles are more >> confusing and the mediator also additionally adds some correlation fields >> without user knowledge. Due to this BAM mediator is currently not suitable >> as an eventing solution. >> >> I'm +1 to drop the new mediator if >> >> 1. Name of the BAM mediator is changed to either to activity mediator or >> data publisher mediator or any other common eventing name, >> Reason: BAM mediator name is wrong as it has to be generic for CEP and >> BAM and to other WSO2 products >> > Yes. I agree. Now I think we give it the name "Publish Mediator" or "Pub > mediator" as publishing is what actually it does. WDYT? > >> 2. Should be able to drop the correlation fields added by default >> Reason: For most of the use-cases correlation fields are unnecessary, >> this also introduces errors as they are added without user knowledge, and >> it also increases the amount of data transferred >> > That seems to be valid too. I too think we should give the user the option > to select the correlation field. And it will be better if we can set > correlation data fields in message in a customisable manner in future. I > think this should be a separate discussion. For now we can give the option > for the user to select to enable the Activity ID. > >> 3. Should support xml based configurations >> Reason: Currently we are bound to the UI and there is no way to automate >> this process >> > We already have a XML configuration for BAM Server Profiles in config > registry. So we can automate the configuration without UI at the moment. > But cannot agree with XML config in Synapse XML itself, as it will lose the > centralised configuration capability and as it will too complicate the > Synapse XML. We have discussed about this earlier in that BAM mediator > mailing thread. > >> 4. Improve the usability in UI and configurations >> > Yeah. It is possible and will do in next release. > >> >> I might be wrong, sometime eventing might not fall under BAM mediator at >> all, in that case we can have two mediators solving two scenarios. >> > It is better if we can use the same mediator as the maintenance cost can > be reduced. I see do not any problem when eventing is considered with BAM. > But if you are planning to go to a very sophisticated eventing mechanism > for CEP in future, a dedicated mediator will be required for CEP. On the > other hand if CEP is moving to that mechanism, please tell us, as we should > upgrade BAM to that standard as well. :-) > >> >> Suho >> >> >> >> >>>> >>>> On Fri, Jun 14, 2013 at 9:34 PM, Sriskandarajah Suhothayan < >>>> s...@wso2.com> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jun 14, 2013 at 5:11 PM, Maninda Edirisooriya < >>>>> mani...@wso2.com> wrote: >>>>> >>>>>> >>>>>> On Fri, Jun 14, 2013 at 10:59 AM, Srinath Perera <srin...@wso2.com>wrote: >>>>>> >>>>>>> Hi Maninda, >>>>>>> >>>>>>> Reason for the new mediator is here "Mediator for publishing event >>>>>>> from ESB to BAM and CEP and Event Model". Above mediator was done so >>>>>>> that >>>>>>> it can be used to publish to BAM/ CEP/ and pub/sub brokers. >>>>>>> >>>>>> Do you mean Loadbalancingdatapublisher? In BAM mediator too we >>>>>> support publishing to both BAM and CEP at once via >>>>>> Loadbalancingdatapublisher. >>>>>> >>>>>> Suho, is there any new feature for pub/sub brokers in new mediator? >>>>>> >>>>> Its the usability & configurabiliy >>>>> The new mediator has all the features that the BAM mediator has but in >>>>> a lean way, >>>>> Its very easy for the user to configure in this even without the UI >>>>> >>>>> I dont wanted to get into religious arguments, we need to look at the >>>>> big picture and fix that, >>>>> either by fixing/rewriting the BAM mediator or by adopting the new >>>>> mediator instead of the current one >>>>> >>>>> Regards >>>>> Suho >>>>> >>>>> >>>>>>> Tharindu and BuddikaC was part of this chat, so BAM team knows. >>>>>>> >>>>>>> We cannot have two mediators to publish events out of ESB. Could >>>>>>> Suho and you can have a chat? >>>>>>> >>>>>>> If it has all functionalities of the other, then it can replace. >>>>>>> Otherwise, we have to merge. >>>>>>> >>>>>>> --Srinath >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 13, 2013 at 12:45 PM, Maninda Edirisooriya < >>>>>>> mani...@wso2.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Thu, Jun 13, 2013 at 12:02 PM, Sriskandarajah Suhothayan < >>>>>>>> s...@wso2.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Currently there are lots of usability issues with BAM mediator, >>>>>>>>> hence as an alternative we came up with the Data Publisher >>>>>>>>> Mediator[1] as >>>>>>>>> part of a client engagement. >>>>>>>>> >>>>>>>> We will fix most of the issues in BAM Mediator in the next release. >>>>>>>> If we are moving to new mediator, what are the new features available >>>>>>>> in >>>>>>>> the new one? >>>>>>>> >>>>>>>>> >>>>>>>>> Data Publisher Mediator uses LoadBalancingDataPublisher to send >>>>>>>>> events to BAM/CEP endpoints and it also supports XML configuration. >>>>>>>>> >>>>>>>> Present mediator also uses LoadBalancingDataPublisher to send >>>>>>>> events to BAM/CEP endpoints. Supporting XML configurations directly >>>>>>>> from >>>>>>>> the Synapse XML was the first plan we had when designing the BAM >>>>>>>> mediator. >>>>>>>> But as we wanted to configure all the server credential related >>>>>>>> configurations and stream definition related configuration related >>>>>>>> configuration in a one place. We have discussed about this topic in the >>>>>>>> mail thread "BAM mediator for ESB". The future plan is to move all >>>>>>>> the stream related configuration into a single centralised server >>>>>>>> something >>>>>>>> like WSO2 Store. So supporting configuration inline in the synapse XML >>>>>>>> will >>>>>>>> ease the process in few mediators but will reduce the configurability >>>>>>>> as a >>>>>>>> whole. >>>>>>>> >>>>>>>>> >>>>>>>>> The only drawback is that the Data Publisher Mediator doesn’t have >>>>>>>>> a UI. I believe writing a UI to this mediator will enhance data >>>>>>>>> publishing >>>>>>>>> and solve the current usability issues that we are facing now. >>>>>>>>> >>>>>>>>> A sample XML configuration is as follows >>>>>>>>> >>>>>>>>> <dataPublisher> >>>>>>>>> <receiverUrl>tcp://localhost:7612</receiverUrl> >>>>>>>>> >>>>>>>>> <authenticatorUrl>ssl://localhost:7712</authenticatorUrl> >>>>>>>>> <userName>admin</userName> >>>>>>>>> <password>admin</password> >>>>>>>>> <streamName>AllLocationEvents</streamName> >>>>>>>>> <streamVersion>1.6.4</streamVersion> >>>>>>>>> <attributes> >>>>>>>>> <!-- <meta> >>>>>>>>> <attribute name="price" type="string" >>>>>>>>> value="//m:price"/> >>>>>>>>> </meta>--> >>>>>>>>> >>>>>>>>> <payload> >>>>>>>>> <attribute name="latitude" >>>>>>>>> type="double" default="2.2" value="//m:latitude"/> >>>>>>>>> <attribute name="longitude" >>>>>>>>> type="double" default="67.78" value="//m:longitude"/> >>>>>>>>> <attribute name="accuracy" >>>>>>>>> type="double" value="//m:accuracy"/> >>>>>>>>> <attribute name="updatedTime" >>>>>>>>> type="long" value="//m:timestamp"/> >>>>>>>>> <attribute name="device_uuid" >>>>>>>>> type="string" value="//m:device-uuid"/> >>>>>>>>> </payload> >>>>>>>>> </attributes> >>>>>>>>> <namespaces> >>>>>>>>> <namespace prefix="m" uri=" >>>>>>>>> http://schemas.google.com/latitude/2010"/> >>>>>>>>> </namespaces> >>>>>>>>> </dataPublisher> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Suho >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://svn.wso2.org/repos/wso2/people/suho/data-publisher-mediator >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *S. Suhothayan >>>>>>>>> * >>>>>>>>> Associate Technical Lead, >>>>>>>>> Management Committee Member, Data Technologies Team, >>>>>>>>> *WSO2 Inc. *http://wso2.com * >>>>>>>>> <http://wso2.com/>* >>>>>>>>> lean . enterprise . middleware >>>>>>>>> >>>>>>>>> *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ >>>>>>>>> twitter: http://twitter.com/suhothayan | linked-in: >>>>>>>>> http://lk.linkedin.com/in/suhothayan* >>>>>>>>> * >>>>>>>>> * >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> Dev@wso2.org >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ============================ >>>>>>> Srinath Perera, Ph.D. >>>>>>> http://people.apache.org/~hemapani/ >>>>>>> http://srinathsview.blogspot.com/ >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *S. Suhothayan >>>>> * >>>>> Associate Technical Lead, >>>>> Management Committee Member, Data Technologies Team, >>>>> *WSO2 Inc. *http://wso2.com * >>>>> <http://wso2.com/>* >>>>> lean . enterprise . middleware >>>>> >>>>> *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ >>>>> twitter: http://twitter.com/suhothayan | linked-in: >>>>> http://lk.linkedin.com/in/suhothayan* >>>>> * >>>>> * >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> Dev@wso2.org >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> Tharindu >>> >>> >>> >> >> >> -- >> *S. Suhothayan >> * >> Associate Technical Lead, >> Management Committee Member, Data Technologies Team, >> *WSO2 Inc. *http://wso2.com * >> <http://wso2.com/>* >> lean . enterprise . middleware >> >> *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ >> twitter: http://twitter.com/suhothayan | linked-in: >> http://lk.linkedin.com/in/suhothayan* >> * >> * >> > > > _______________________________________________ > Architecture mailing list > architect...@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & regards, Nirmal Senior Software Engineer- Platform Technologies Team, WSO2 Inc. Mobile: +94715779733 Blog: http://nirmalfdo.blogspot.com/
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
