The eventSink should ideally end up like datasources, so i believe the local entry will not work
Hence +1 for Maninda's suggestions we'll fix the eventSink in the next iteration. Suho On Tue, Nov 4, 2014 at 2:00 AM, Lahiru Chandima <[email protected]> wrote: > Hi All, > > How about using an ESB local entry for storing eventSink config? We asked > ESB team and they told it supports MT and also it is a deployable artifact. > > Thanks. > > On Tue, Nov 4, 2014 at 12:00 PM, Maninda Edirisooriya <[email protected]> > wrote: > >> >> On Mon, Nov 3, 2014 at 9:27 PM, Sriskandarajah Suhothayan <[email protected]> >> wrote: >> >>> >>> >>> On Mon, Nov 3, 2014 at 6:49 AM, Vijitha Ekanayake <[email protected]> >>> wrote: >>> >>>> Hi All, >>>> >>>> Following is the mediator xml format we are going to use. >>>> >>>> <publishEvent> >>>> <eventSink>bam_event_sink</eventSink> >>>> <streamName>stream_2</streamName> >>>> <streamVersion>1.7.6</streamVersion> >>>> <attributes> >>>> <meta> >>>> <attribute name="method" type="string" default="" >>>> value="get-property('axis2', 'HTTP_METHOD')" /> >>>> <attribute name="to" type="string" default="" >>>> value="get-property('To')" /> >>>> </meta> >>>> <correlation> >>>> <attribute name="date" type="string" default="" >>>> value="get-property('SYSTEM_DATE')" /> >>>> </correlation> >>>> <payload> >>>> <attribute xmlns:m0="http://services.samples"; >>>> name="symbol" type="string" default="IBM" >>>> value="$body/m0:getQuote/m0:request/m0:symbol" /> >>>> </payload> >>>> </attributes> >>>> </publishEvent> >>>> >>>> >>>> Each attribute here is treated as an XPath expression by default. if >>>> user wants to send a constant text value as in bam mediator, he can set >>>> "expression" attribute to "false"(default value of expression attribute is >>>> "true") >>>> >>>> Over all it looks great ! >>> >>> Few suggestions, >>> I think we have to use value or expression like in property mediator, >>> so that it will give a uniform user experience. >>> and in that case I'll suggest you to use defaultValue because the >>> default can only be a value. >>> >> We are following the Property mediator's syntax for the attribute as much >> as possible. >> >>> >>> eventSink artifact(event-sinks.xml) format is as follows. >>>> >>>> <?xml version="1.0" encoding="UTF-8"?> >>>> <eventSinks> >>>> <eventSink name="bam_event_sink"> >>>> <receiverUrl>tcp://localhost:7612</receiverUrl> >>>> <authenticatorUrl>ssl://localhost:7712</authenticatorUrl> >>>> <userName>admin</userName> >>>> <password>encrypted_password</password> >>>> </eventSink> >>>> <eventSink name="cep_event_sink"> >>>> <receiverUrl>tcp://localhost:7614</receiverUrl> >>>> <authenticatorUrl>ssl://localhost:7714</authenticatorUrl> >>>> <userName>admin</userName> >>>> <password>encrypted_password</password> >>>> </eventSink> >>>> </eventSinks> >>>> >>>> This will be place in repository/conf directory. >>>> >>> >>> Want the eventSink will get dep-synced ? >>> How does this work in MT situations? >>> Is there also a way to add this from UI ? and in that case where it will >>> be stored? >>> >> >> For the first iteration of development we decided to go with a config >> file. Then we hope to develop as this config as a deployable artifact which >> can be dep-synced across the Carbon platform which will enable the MT. But >> as discussed above with Lasantha when we are going to this artifact we have >> to include the thrift related configurations like queue size timeouts etc. >> in this eventSink element. >> >>> >>> Regards >>> Suho >>> >>> >>>> Any suggestions are welcome. >>>> >>>> Thank you. >>>> >>>> >>>> >>>> >>>> On Thu, Oct 30, 2014 at 1:52 PM, Sriskandarajah Suhothayan < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Oct 27, 2014 at 8:58 PM, Lahiru Chandima <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> We need to finalize the names for the mediator and artifact for >>>>>> storing data receiver endpoint data. Following are the current >>>>>> candidates. >>>>>> >>>>>> *Mediator* >>>>>> publishData vs publishEvent >>>>>> >>>>>> +1 publishEvent, because the user should know that he is publishing >>>>> event and this is based on event driven architecture. >>>>>> >>>>>> >>>>>> *Endpoint config artifact* >>>>>> dataSink/eventSink vs dataReceiver/eventReceiver >>>>>> >>>>> >>>>> +1 for eventSink >>>>> We cant use 'Receiver' as its will mean that ESB will be receiving the >>>>> event. Hence we have to use eventSink >>>>> >>>>> Suho >>>>> >>>>>> >>>>>> >>>>>> Can you please share your thoughts on the names to decide which is >>>>>> better? Any new name suggestions are also welcome. >>>>>> >>>>>> Thanks >>>>>> >>>>>> On Mon, Oct 27, 2014 at 11:40 AM, Maninda Edirisooriya < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> On Sun, Oct 26, 2014 at 8:13 PM, Lasantha Fernando < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Maninda, >>>>>>>> >>>>>>>> On 24 October 2014 18:16, Maninda Edirisooriya <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Oct 24, 2014 at 3:13 PM, Lasantha Fernando < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi Maninda, >>>>>>>>>> >>>>>>>>>> On 24 October 2014 14:40, Maninda Edirisooriya <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Oct 24, 2014 at 1:10 PM, Lasantha Fernando < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Maninda, all, >>>>>>>>>>>> >>>>>>>>>>>> On 24 October 2014 12:39, Gihan Anuruddha <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> We need to maintain a single location to give publisher >>>>>>>>>>>>> credential details. At the moment we are maintaining same details >>>>>>>>>>>>> in a >>>>>>>>>>>>> different location that is a bit inconvenient. As an example >>>>>>>>>>>>> if we change BAM url then we have to change BAM server >>>>>>>>>>>>> profiles as well as mediation stat publish UI as well. Also, this >>>>>>>>>>>>> password >>>>>>>>>>>>> should support secureVault. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> +1 >>>>>>>>>>>> >>>>>>>>>>> Yes. When we can come up with the generic artifact which >>>>>>>>>>> describes data sink URL and credentials, we can access them for all >>>>>>>>>>> ESB >>>>>>>>>>> components (like new mediator and mediation stats publisher) via a >>>>>>>>>>> declarative service. As this artifact is dep synced across all the >>>>>>>>>>> products >>>>>>>>>>> other products too can get URL and credentials without any issue. >>>>>>>>>>> All you >>>>>>>>>>> have to do is to install the feature to that product that exposes >>>>>>>>>>> that >>>>>>>>>>> declarative service. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Oct 24, 2014 at 12:25 PM, Maninda Edirisooriya < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Today morning we had a discussion where Anjana, Lahiru, >>>>>>>>>>>>>> Vijitha, Kasun and I participated. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There we decided to develop a common Data Publisher / Data >>>>>>>>>>>>>> Sink axis2 artifact which is generic throughout the platform. >>>>>>>>>>>>>> This will >>>>>>>>>>>>>> enable any other carbon products also for finding data publishing >>>>>>>>>>>>>> connection / credential details when they want to publish data >>>>>>>>>>>>>> to CEP / BAM. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Are we going to couple with Axis2 for the data publisher/ data >>>>>>>>>>>> sink? Querying about this since you had mentioned 'axis2 >>>>>>>>>>>> artifacts'.. :-). >>>>>>>>>>>> >>>>>>>>>>> I am not sure about the new artifact type that is going to >>>>>>>>>>> replace axis2 artifact deployment, and that is the reason I >>>>>>>>>>> mentioned the >>>>>>>>>>> name "axis2". Yes it is better if we can go with the new deployment >>>>>>>>>>> artifact type. :) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In the current data-bridge model, we are not having Axis2 >>>>>>>>>> deployment artifacts since the data receivers/data publishers are not >>>>>>>>>> hot-deployable artifacts. In the current model, usually, we >>>>>>>>>> configure a >>>>>>>>>> single data receiver for a server before start up and the no. of >>>>>>>>>> publishers >>>>>>>>>> , type are also pre-configured and not hot-deployable. Are we going >>>>>>>>>> for a >>>>>>>>>> model with multiple data publisher/data receiver artifacts deployed >>>>>>>>>> through >>>>>>>>>> an Axis2 deployer or similar? >>>>>>>>>> >>>>>>>>> >>>>>>>>> You are correct. We can use a configuration file for configuring >>>>>>>>> Data Publishing server connection URL and credentials assuming all the >>>>>>>>> tenants are publishing to the same BAM / CEP server in a multi-tenant >>>>>>>>> environment. >>>>>>>>> >>>>>>>> >>>>>>>> I think we can go for hot-deployable data sink/data publisher >>>>>>>> artifacts if there is a use case for that. I was actually wrong >>>>>>>> earlier in >>>>>>>> saying that data publishers are not hot-deployable. In BAM/CEP output >>>>>>>> adaptors, OutputWSO2Event adaptors are actually hot deployable. For ESB >>>>>>>> also, I think there is the ability to configure the BAM server profiles >>>>>>>> dynamically. Though I think the BAM server profiles are stored in >>>>>>>> registry >>>>>>>> and not hot deployable. If we move these configs to a file, we are >>>>>>>> actually >>>>>>>> removing existing functionality IMHO. So I guess we cannot move all the >>>>>>>> configs to a file-based config. +1 from me to make Data Publisher >>>>>>>> configurations hot deployable axis2 artifacts (Removing axis2 >>>>>>>> dependency >>>>>>>> has a long way to go yet, I think). Sorry for suggesting otherwise >>>>>>>> earlier.. :-) >>>>>>>> >>>>>>>> In databridge level, the receiver details and the no. of >>>>>>>> threads,event queue size are file-based configurations. The data sink/ >>>>>>>> data receiver artifacts were not made hot deployable with assumption >>>>>>>> that >>>>>>>> keeping a pre-configured single port listening for incoming Thrift >>>>>>>> traffic >>>>>>>> is adequate. Shall we make it the same for the new Data Publisher/ Data >>>>>>>> Sink configurations? i.e. file-based DataReceiver/DataSink and >>>>>>>> hot-deployable DataPublisher (We also need to get the names right as >>>>>>>> well, >>>>>>>> I think. i.e. DataPublisher vs EventPublihser, DataReceiver vs DataSink >>>>>>>> etc...) ? We can make the DataSink part hot-deployable as well if >>>>>>>> there is >>>>>>>> a use case for that? WDYT? >>>>>>>> >>>>>>> >>>>>>> As you say if we are going on with hot deployable artifacts other >>>>>>> configurations like thrift threads etc. should be made configurable in >>>>>>> this >>>>>>> artifact. Therefore for the first step lets move with a configuration >>>>>>> file >>>>>>> and iteratively we can move that to a deployable artifact after >>>>>>> considering >>>>>>> the platform wide compatibility. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> Can't we make it generic to the platform without coupling with >>>>>>>>>>>> Axis2 since we are moving away from Axis2 in other areas of the >>>>>>>>>>>> platform? >>>>>>>>>>>> >>>>>>>>>>> Can you explain how to make it generic? This is really a problem >>>>>>>>>>> I thought. I think we have to decide it before we completely get >>>>>>>>>>> rid of >>>>>>>>>>> Axis2. Maybe Azeez have an idea. >>>>>>>>>>> >>>>>>>>>>> Azeez, what do you think about the new artifact deployment modal >>>>>>>>>>> independent from Axis2? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> And specific to the ESB we are going to develop a mediator >>>>>>>>>>>>>> (it's name is not confirmed yet) which will be similar to the >>>>>>>>>>>>>> current BAM >>>>>>>>>>>>>> mediator which will refer to the above mentioned artifact for >>>>>>>>>>>>>> credentials >>>>>>>>>>>>>> and connection parameters. As also we should include the >>>>>>>>>>>>>> transport we are >>>>>>>>>>>>>> referring in that particular data sink / data publisher. For the >>>>>>>>>>>>>> first cut >>>>>>>>>>>>>> we can use only the Thrift and hope to extend for HTTP and JMS >>>>>>>>>>>>>> in future. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In new implementation of the mediator, there will be no >>>>>>>>>>>>>> configuration for Stream configuration like the BAM mediator. >>>>>>>>>>>>>> Instead there >>>>>>>>>>>>>> will be inline configurations in the mediator XML which consists >>>>>>>>>>>>>> of >>>>>>>>>>>>>> 1. a stream ID (or the combination of Stream Name and Stream >>>>>>>>>>>>>> Version) >>>>>>>>>>>>>> 2. and mappings from message XPath to the stream field. (i.e. >>>>>>>>>>>>>> maps from message properties to the stream fields.) >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> +1 for mapping message to stream attributes as described above. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> For the convenience to the user, we can prompt the stream >>>>>>>>>>>>>> fields for mapping from the UI, (once stream ID is provided) if >>>>>>>>>>>>>> the stream >>>>>>>>>>>>>> is already there in the stream definition store. Anyway there >>>>>>>>>>>>>> (if want to >>>>>>>>>>>>>> get UI help) we have to use the existing streams that were >>>>>>>>>>>>>> already created >>>>>>>>>>>>>> from CEP or BAM. But still you can add a mapping for a new >>>>>>>>>>>>>> stream which can >>>>>>>>>>>>>> subsequently be added to the stream definition store from CEP or >>>>>>>>>>>>>> BAM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We have decided to go for a mediator instead of a connector >>>>>>>>>>>>>> as this has nothing to do for accessing an external API kind of >>>>>>>>>>>>>> operation >>>>>>>>>>>>>> but to publish data for our own products according to the >>>>>>>>>>>>>> connection >>>>>>>>>>>>>> information given by the internal Data Publisher / Data Sink >>>>>>>>>>>>>> artifact. >>>>>>>>>>>>>> >>>>>>>>>>>>>> WDYT about the cases when we use other transports like HTTP, >>>>>>>>>>>>>> JMS, MQTT etc. ? >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Will we really be needing HTTP, JMS support when communicating >>>>>>>>>>>> within the platform across different products? Asking this since >>>>>>>>>>>> we already >>>>>>>>>>>> have similar functionality in many places (e.g. ESB, BAM/CEP input >>>>>>>>>>>> adaptors) and our general architectural approach is to get the >>>>>>>>>>>> events/messages into the platform from one product, then >>>>>>>>>>>> communicate within >>>>>>>>>>>> the platform using a single native format for >>>>>>>>>>>> efficiency/performance. WDYT? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Due to the client loadbalancing requirement of the Thrift >>>>>>>>>>> endpoint there may be some limitations when it comes to publishing >>>>>>>>>>> from one >>>>>>>>>>> cluster to another cluster where data receiver thrift URLs are not >>>>>>>>>>> visible >>>>>>>>>>> outside from the second cluster. There we may have to use HTTP data >>>>>>>>>>> sink >>>>>>>>>>> type. And if there is a requirement for publishing to a 3rd party >>>>>>>>>>> JMS topic >>>>>>>>>>> we may need JMS support and so on. Anyway we should first focus on >>>>>>>>>>> the >>>>>>>>>>> Thrift type and will think about others as the next steps. :) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If we are trying to send something over HTTP or JMS from ESB, >>>>>>>>>> can't we make use of the already existing implementations within ESB >>>>>>>>>> to >>>>>>>>>> send to HTTP or JMS endpoints? It will indeed be very useful to have >>>>>>>>>> a set >>>>>>>>>> of pluggable transports that can be used by any product of the >>>>>>>>>> platform. I >>>>>>>>>> think the concern is whether we will be redoing already available >>>>>>>>>> transports when implementing HTTP/JMS for databridge level as well. >>>>>>>>>> Of >>>>>>>>>> course, I might have misunderstood the approach mentioned here, if >>>>>>>>>> so, >>>>>>>>>> please correct me if am wrong.. :-) >>>>>>>>>> >>>>>>>>> In this data sink artifact we will build the messages according to >>>>>>>>> the events used in the stream where the existing HTTP, JMS and etc. >>>>>>>>> message >>>>>>>>> endpoints are capable of sending raw messages. The example is >>>>>>>>> Entitlement >>>>>>>>> mediator where it sends data via HTTP and with a specific format. >>>>>>>>> >>>>>>>> >>>>>>>> Yes, that makes sense. In that case, I think the data >>>>>>>> publisher/event publisher artifacts would provide a sort of >>>>>>>> pre-configured >>>>>>>> template for sending events over HTTP, JMS to other WSO2 products and >>>>>>>> use >>>>>>>> the underlying HTTP, JMS transport implementation that already exists. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lasantha >>>>>>>> >>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Lasantha >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Lasantha >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Feedback is welcome. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Maninda Edirisooriya* >>>>>>>>>>>>>> Senior Software Engineer >>>>>>>>>>>>>> >>>>>>>>>>>>>> *WSO2, Inc.*lean.enterprise.middleware. >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Blog* : http://maninda.blogspot.com/ >>>>>>>>>>>>>> *E-mail* : [email protected] >>>>>>>>>>>>>> *Skype* : @manindae >>>>>>>>>>>>>> *Twitter* : @maninda >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Oct 20, 2014 at 8:00 PM, Sriskandarajah Suhothayan < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Oct 20, 2014 at 4:06 AM, Mohanadarshan >>>>>>>>>>>>>>> Vivekanandalingam <[email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We had a discussion sometime back (last year) on this.. >>>>>>>>>>>>>>>> Please check the mail thread [1] for more info.. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, I believe we all agree that we need to improve the >>>>>>>>>>>>>>> current BAM Mediator. >>>>>>>>>>>>>>> When I had a chat with kasun on this he suggested writing it >>>>>>>>>>>>>>> as a connector will be much cleaner. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Where we can have the connection information and stream >>>>>>>>>>>>>>> definition in <init> and <defineStream> then then pass the data >>>>>>>>>>>>>>> via >>>>>>>>>>>>>>> <publish>. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I believe its better to have a f2f meeting with kasun on >>>>>>>>>>>>>>> this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>> Suho >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] [Architecture] Improving Data Publisher Mediator to >>>>>>>>>>>>>>>> replace BAM Mediator >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Mohan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Oct 20, 2014 at 12:55 PM, Anjana Fernando < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> *V. Mohanadarshan* >>>>>>>>>>>>>>>> *Software Engineer,* >>>>>>>>>>>>>>>> *Data Technologies Team,* >>>>>>>>>>>>>>>> *WSO2, Inc. http://wso2.com <http://wso2.com> * >>>>>>>>>>>>>>>> *lean.enterprise.middleware.* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> email: [email protected] >>>>>>>>>>>>>>>> phone:(+94) 771117673 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *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 >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> W.G. Gihan Anuruddha >>>>>>>>>>>>> Senior Software Engineer | WSO2, Inc. >>>>>>>>>>>>> M: +94772272595 >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> *Lasantha Fernando* >>>>>>>>>>>> Software Engineer - Data Technologies Team >>>>>>>>>>>> WSO2 Inc. http://wso2.com >>>>>>>>>>>> >>>>>>>>>>>> email: [email protected] >>>>>>>>>>>> mobile: (+94) 71 5247551 >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Lasantha Fernando* >>>>>>>>>> Software Engineer - Data Technologies Team >>>>>>>>>> WSO2 Inc. http://wso2.com >>>>>>>>>> >>>>>>>>>> email: [email protected] >>>>>>>>>> mobile: (+94) 71 5247551 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Lasantha Fernando* >>>>>>>> Software Engineer - Data Technologies Team >>>>>>>> WSO2 Inc. http://wso2.com >>>>>>>> >>>>>>>> email: [email protected] >>>>>>>> mobile: (+94) 71 5247551 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Lahiru Chandima >>>>>> *Senior Software Engineer* >>>>>> Mobile : +94 (0) 772 253283 >>>>>> [email protected] >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> 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>* >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vijitha Ekanayake >>>> Software Engineer*, *WSO2, Inc.; http://wso2.com/ >>>> Mobile : +94 777 24 73 39 | +94 718 74 44 08 >>>> lean.enterprise.middleware >>>> >>> >>> >>> >>> -- >>> >>> *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>* >>> >> >> > > > -- > Lahiru Chandima > *Senior Software Engineer* > Mobile : +94 (0) 772 253283 > [email protected] > -- *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 | 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
