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 <mani...@wso2.com>
wrote:
>
> On Mon, Nov 3, 2014 at 9:27 PM, Sriskandarajah Suhothayan <s...@wso2.com>
> wrote:
>
>>
>>
>> On Mon, Nov 3, 2014 at 6:49 AM, Vijitha Ekanayake <vijit...@wso2.com>
>> 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 <
>>> s...@wso2.com> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Oct 27, 2014 at 8:58 PM, Lahiru Chandima <lahi...@wso2.com>
>>>> 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 <
>>>>> mani...@wso2.com> wrote:
>>>>>
>>>>>> On Sun, Oct 26, 2014 at 8:13 PM, Lasantha Fernando <lasan...@wso2.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi Maninda,
>>>>>>>
>>>>>>> On 24 October 2014 18:16, Maninda Edirisooriya <mani...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Oct 24, 2014 at 3:13 PM, Lasantha Fernando <
>>>>>>>> lasan...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Maninda,
>>>>>>>>>
>>>>>>>>> On 24 October 2014 14:40, Maninda Edirisooriya <mani...@wso2.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Oct 24, 2014 at 1:10 PM, Lasantha Fernando <
>>>>>>>>>> lasan...@wso2.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Maninda, all,
>>>>>>>>>>>
>>>>>>>>>>> On 24 October 2014 12:39, Gihan Anuruddha <gi...@wso2.com>
>>>>>>>>>>> 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 <
>>>>>>>>>>>> mani...@wso2.com> 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* : mani...@wso2.com
>>>>>>>>>>>>> *Skype* : @manindae
>>>>>>>>>>>>> *Twitter* : @maninda
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Oct 20, 2014 at 8:00 PM, Sriskandarajah Suhothayan <
>>>>>>>>>>>>> s...@wso2.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Oct 20, 2014 at 4:06 AM, Mohanadarshan
>>>>>>>>>>>>>> Vivekanandalingam <mo...@wso2.com> 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 <
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *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
>>>>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> W.G. Gihan Anuruddha
>>>>>>>>>>>> Senior Software Engineer | WSO2, Inc.
>>>>>>>>>>>> M: +94772272595
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Architecture mailing list
>>>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> *Lasantha Fernando*
>>>>>>>>>>> Software Engineer - Data Technologies Team
>>>>>>>>>>> WSO2 Inc. http://wso2.com
>>>>>>>>>>>
>>>>>>>>>>> email: lasan...@wso2.com
>>>>>>>>>>> mobile: (+94) 71 5247551
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Architecture mailing list
>>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Architecture mailing list
>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Lasantha Fernando*
>>>>>>>>> Software Engineer - Data Technologies Team
>>>>>>>>> WSO2 Inc. http://wso2.com
>>>>>>>>>
>>>>>>>>> email: lasan...@wso2.com
>>>>>>>>> mobile: (+94) 71 5247551
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Architecture mailing list
>>>>>>>>> Architecture@wso2.org
>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Lasantha Fernando*
>>>>>>> Software Engineer - Data Technologies Team
>>>>>>> WSO2 Inc. http://wso2.com
>>>>>>>
>>>>>>> email: lasan...@wso2.com
>>>>>>> mobile: (+94) 71 5247551
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lahiru Chandima
>>>>> *Senior Software Engineer*
>>>>> Mobile : +94 (0) 772 253283
>>>>> lahi...@wso2.com
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> 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
>>>> Architecture@wso2.org
>>>> 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
lahi...@wso2.com
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
