Hi Sanjiva, On Sat, Oct 18, 2014 at 9:44 PM, Sanjiva Weerawarana <[email protected]> wrote:
> On Fri, Oct 17, 2014 at 6:47 PM, Lahiru Chandima <[email protected]> wrote: > >> Hi all, >> >> We (Vijitha<[email protected]> 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: [email protected]; 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 > [email protected] > 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
