Hi All, We had a discussion sometime back (last year) on this.. Please check the mail thread [1] for more info..
[1] [Architecture] Improving Data Publisher Mediator to replace BAM Mediator Thanks, Mohan On Mon, Oct 20, 2014 at 12:55 PM, Anjana Fernando <anj...@wso2.com> wrote: > Hi Sanjiva, > > On Sat, Oct 18, 2014 at 9:44 PM, Sanjiva Weerawarana <sanj...@wso2.com> > wrote: > >> On Fri, Oct 17, 2014 at 6:47 PM, Lahiru Chandima <lahi...@wso2.com> >> wrote: >> >>> Hi all, >>> >>> We (Vijitha<vijit...@wso2.com> and myself) are going to develop an ESB >>> Connector which can publish events to BAM and CEP. >>> >> >> We're currently using the words "ESB Connector" to mean something that >> becomes a set of mediators to access (primarily) HTTP APIs. This is not >> that right?? If so lets not use the same words please. >> > > Yeah, I guess, this is simply a mediator, just like what we have now. It > was just Kasun has mentioned to Suho, to create this as an ESB Connector, > where we haven't actually gone into what it means to create a connector. > @Kasun, maybe you can shed some light on this, on what you meant earlier. > > >> >> Currently, BAM mediator is used for sending events from ESB to BAM. BAM >>> Mediator needs to be configured with server details and streams need to be >>> defined prior to using them in sequences of ESB Synapse configuration. >>> >>> With new ESB connector, it will be possible to add all configurations >>> needed to publish events to BAM or CEP in the ESB Synapse configuration >>> itself. This brings the configuration to a single place unlike when using >>> the BAM mediator. >>> >> >> Is this a real requirement? Do we expect different ESB configs (running >> on the same server) to want to send data to different BAM/CEP endpoints? I >> understand the multitenancy usecase - is it only for that? >> > > Actually, the idea here is, what we have now for defining the target for > events, "BAM Profiles", to replace that. Basically in a BAM Profile, we put > all the information such as the event receiver details, and the stream > definition, and how the properties are mapped using properties from a > sequence. We want to clean this up by, simply having something equivalent > to a message store we have now, where we named is "data sink" for now, to > be the target for events, and the actual stream mapping will be done by the > mediator itself, in the sequence. And the motivation for having this as an > artifact in the synapse configuration is, where from a place like DevStudio > or any development environment, we can create these deployment artifacts > can directly deploy them, without going to the admin console and adding > them through the UI. > > >> >> *High level architecture - components.* >>> >>> 1) New Synapse construct will be introduced to configure details related >>> to the data sink (ie. CEP or BAM). >>> >>> Eg. >>> >>> <dataSink name=”bam_thrift_server”> >>> <url>tcp://localhost:7611<url> >>> <username>admin</username> >>> <password>admin</password> >>> </dataSink> >>> >> >> What do we call this now? The term "dataSink" doesn't work for me but >> that could be just me. >> > > Yeah, we had a meeting sometime back to discuss this, and that day also, > we couldn't decide on the name :) .. basically something related to a > dataSink, any suggestions? :) .. > > >> >> 2) An ESB connector will be developed which can be used to publish events >>> to a data sink. Connector will use data-bridge API (Thrift) for publishing >>> events (It will be possible to introduce new transports other than Thrift >>> later). >>> >> >> Once again, what are the operations? Why do we want to write a connector >> instead of using / improving the current "BAM mediator"? >> > > So yeah, it will basically be improving/re-writing the current mediator, > with a name like "dataPublish" or something, without any "BAM" part, and > with the stream property mapping part added there itself, rather than > having it in another place. > > >> >> Thrift stream related data (stream name, version and stream properties) >>> will be configured in the ESB connector configuration (in Synapse config), >>> which is more logical compared to configuring it separately as done in the >>> BAM mediator. >>> >> >> Can you give a specific example to illustrate the difference please? >> > > So basically in the current BAM mediator, we do not give the direct > mapping to the stream properties there, we simply populate some message > context properties and call the mediator. And the mediator simply looks up > the information provided by the BAM Profile to do the actual mapping, where > in our profile, we have given like Xpath expressions to say, what are the > values in a specific target stream event. > > Cheers, > Anjana. > > >> >> Thanks, >> >> Sanjiva. >> -- >> 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 >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Anjana Fernando* > Senior Technical Lead > WSO2 Inc. | http://wso2.com > lean . enterprise . middleware > > _______________________________________________ > 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
