This was proposed to support both WSO2 Event mediator in ESB(read about Publish subscribe ) and publishing to BAM and CEP via the same mediator because we felt there is lot of synergy.
Discussion notes are in thread "Mediator for publishing event from ESB to BAM and CEP and Event Model" , please read that. 1) There was a meeting to discuss this changes before this was done and BAM team was part of it 2) Tharindu, you were not there, but you responded to my notes We also did some changes to mediator syntax, which clarify its use (or we felt so) I will schedule a meeting. --Srinath On Mon, Jun 17, 2013 at 12:27 PM, Sriskandarajah Suhothayan <[email protected]>wrote: > > > > On Sun, Jun 16, 2013 at 6:08 PM, Nirmal Fernando <[email protected]> wrote: > >> 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. >> > +1 > >> >> >> On Sun, Jun 16, 2013 at 5:56 PM, Maninda Edirisooriya >> <[email protected]>wrote: >> >>> >>> On Sun, Jun 16, 2013 at 3:21 PM, Sriskandarajah Suhothayan < >>> [email protected]> wrote: >>> >>>> >>>> >>>> >>>> On Sun, Jun 16, 2013 at 12:11 PM, Maninda Edirisooriya < >>>> [email protected]> wrote: >>>> >>>>> >>>>> On Sun, Jun 16, 2013 at 11:08 AM, Tharindu Mathew >>>>> <[email protected]>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? >>> >> "Publish Mediator" is too generic, what are we going to publish? > Why dont we go for "Data Publish Mediator" or "Publish Data Mediator"? > so in the synapse config it will be as <PublishData> > > 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. >>> >> These field should be available in the UI by default and there should be > an option to drop that if the user wishes. > That way we can solve this with out any hacks. > > 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. >>> >> This makes the simple case very difficult, I'm not against storing > configurations in the registry, if you are storing in registry then the > resource path should be provided in the synapse xml like the other > mediators > And we also need to support adding configurations to the synapse xml, you > can reuse some code from the new mediator to do this, this is very straight > forward > > 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. :-) >>> >> Sure when requirements pops up will send you guys, currently we need the > simple case simple and it should just work :) > > > So I'm taking it as you are improving the current module, > Please fix a review when its done :) > > Suho > > > >>>> Suho >>>> >>>> >>>> >>>> >>>>>> >>>>>> On Fri, Jun 14, 2013 at 9:34 PM, Sriskandarajah Suhothayan < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 14, 2013 at 5:11 PM, Maninda Edirisooriya < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Fri, Jun 14, 2013 at 10:59 AM, Srinath Perera >>>>>>>> <[email protected]>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 < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Jun 13, 2013 at 12:02 PM, Sriskandarajah Suhothayan < >>>>>>>>>> [email protected]> 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 >>>>>>>>>> [email protected] >>>>>>>>>> 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 >>>>>>> [email protected] >>>>>>> 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 >>> [email protected] >>> 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/ >> >> > > > -- > *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 > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- ============================ Srinath Perera, Ph.D. Director, Research, WSO2 Inc. Visiting Faculty, University of Moratuwa Member, Apache Software Foundation Research Scientist, Lanka Software Foundation Blog: http://srinathsview.blogspot.com/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
