Re: [Architecture] [Dev] Improving Data Publisher Mediator to replace BAM Mediator
On Fri, Jun 14, 2013 at 5:11 PM, Maninda Edirisooriya mani...@wso2.comwrote: On Fri, Jun 14, 2013 at 10:59 AM, Srinath Perera srin...@wso2.com 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 mani...@wso2.comwrote: On Thu, Jun 13, 2013 at 12:02 PM, Sriskandarajah Suhothayan s...@wso2.com 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 receiverUrltcp://localhost:7612/receiverUrl authenticatorUrlssl://localhost:7712/authenticatorUrl userNameadmin/userName passwordadmin/password streamNameAllLocationEvents/streamName streamVersion1.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 d...@wso2.org 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 *
Re: [Architecture] Issue in App subscription and Key generation with API Manager in AppFactory
On Fri, Jun 14, 2013 at 10:14 PM, Punnadi Gunarathna punn...@wso2.comwrote: Hi All, We have identified $subject and the scenario is as follows: AppOwner creates an Application called App1 in App Factory. He loggs-in to API Manger and subscript App1 with API1 and generate key pairs. He also invite few developers for App1. Based on the current implementation, any other developer who will login to App Factory will not be able to see the previous subscription or already generated keys and also since sso is enabled at API Manager front, they can subscribe the same application individually again with the API1 and generate new keys. But as per the requirement there should be only a single set of keys generated for sandbox and production separately for a particular application (It is true that we can regenerate keys and it is accepted). But with the above scenario, each person can generate different key sets for same application and this will be a hassle in terms of usage. As we discussed with Sumedha, API Manager currently does not support group wise key generation. Therefore we have come up with a below strategy to prevent each user from creating separate keys for the same application over and over again. That is, Only the AppOwner will have the privilege to subscribe to an API and re/generate keys with API Manager. The generated keys will be saved in DB and when other users (dev,qa,devops) login, they can only see the generated keys. We will also make SSO disabled and no buttons will be available in UI to go to API Manager for these user roles. If SSO is disabled(API store) how the appowner is going to login and subscribe to API(manually entering the credential again)? Feel free to share your feedback. -- Thanks and Regards, Punnadi Gunarathna Senior Software Engineer, WSO2, Inc.; http://wso2.com http://wso2 email: punn...@wso2.com lal...@wso2.com http://lalajisureshika.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- ajanthan -- Ajanthan Balachandiran Senior Software Engineer; Solutions Technologies Team ;WSO2, Inc.; http://wso2.com/ email: ajanthan http://goog_595075977@wso2.com; cell: +94775581497 blog: http://bkayts.blogspot.com/ Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Issue in App subscription and Key generation with API Manager in AppFactory
+1 - also, only the App owner should be in the subscriber role. SSO needs to work for the AppOwner though. Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Jun 14, 2013, at 6:53 PM, Ajanthan Balachandran ajant...@wso2.com wrote: On Fri, Jun 14, 2013 at 10:14 PM, Punnadi Gunarathna punn...@wso2.com wrote: Hi All, We have identified $subject and the scenario is as follows: AppOwner creates an Application called App1 in App Factory. He loggs-in to API Manger and subscript App1 with API1 and generate key pairs. He also invite few developers for App1. Based on the current implementation, any other developer who will login to App Factory will not be able to see the previous subscription or already generated keys and also since sso is enabled at API Manager front, they can subscribe the same application individually again with the API1 and generate new keys. But as per the requirement there should be only a single set of keys generated for sandbox and production separately for a particular application (It is true that we can regenerate keys and it is accepted). But with the above scenario, each person can generate different key sets for same application and this will be a hassle in terms of usage. As we discussed with Sumedha, API Manager currently does not support group wise key generation. Therefore we have come up with a below strategy to prevent each user from creating separate keys for the same application over and over again. That is, Only the AppOwner will have the privilege to subscribe to an API and re/generate keys with API Manager. The generated keys will be saved in DB and when other users (dev,qa,devops) login, they can only see the generated keys. We will also make SSO disabled and no buttons will be available in UI to go to API Manager for these user roles. If SSO is disabled(API store) how the appowner is going to login and subscribe to API(manually entering the credential again)? Feel free to share your feedback. -- Thanks and Regards, Punnadi Gunarathna Senior Software Engineer, WSO2, Inc.; http://wso2.com email: punn...@wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- ajanthan -- Ajanthan Balachandiran Senior Software Engineer; Solutions Technologies Team ;WSO2, Inc.; http://wso2.com/ email: ajant...@wso2.com; cell: +94775581497 blog: http://bkayts.blogspot.com/ Lean . Enterprise . Middleware ___ 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
Re: [Architecture] Issue in App subscription and Key generation with API Manager in AppFactory
Hi Punnadi, +1 Allowing Subscribe to API only for App Owner and making them visible for the team. If that feature is implemented, following issues can be resolved at once. https://wso2.org/jira/browse/APPFAC-1230 - When a user clicks on Subscribed to API, user directs to the API Manager, with a different login which was already logged in and does not allow to log out https://wso2.org/jira/browse/APPFAC-1225 - Already subscribed APIs by an App Owner or a Developer should be visible to the team. https://wso2.org/jira/browse/APPFAC-1224 - Subscribe to an API should be enabled only for App Owner and Developer. For Dev Ops for Production key https://wso2.org/jira/browse/APPFAC-1235 - Application sandbox prod user tokens, consumer keys should be same for the app owner and developer Thanks and Regards, Ushani On Fri, Jun 14, 2013 at 10:30 PM, Isabelle Mauny isabe...@wso2.com wrote: +1 - also, only the App owner should be in the subscriber role. SSO needs to work for the AppOwner though. Isabelle. __ *Isabelle Mauny* Director, Product Management; WSO2, Inc.; http://wso2.com/ On Jun 14, 2013, at 6:53 PM, Ajanthan Balachandran ajant...@wso2.com wrote: On Fri, Jun 14, 2013 at 10:14 PM, Punnadi Gunarathna punn...@wso2.comwrote: Hi All, We have identified $subject and the scenario is as follows: AppOwner creates an Application called App1 in App Factory. He loggs-in to API Manger and subscript App1 with API1 and generate key pairs. He also invite few developers for App1. Based on the current implementation, any other developer who will login to App Factory will not be able to see the previous subscription or already generated keys and also since sso is enabled at API Manager front, they can subscribe the same application individually again with the API1 and generate new keys. But as per the requirement there should be only a single set of keys generated for sandbox and production separately for a particular application (It is true that we can regenerate keys and it is accepted). But with the above scenario, each person can generate different key sets for same application and this will be a hassle in terms of usage. As we discussed with Sumedha, API Manager currently does not support group wise key generation. Therefore we have come up with a below strategy to prevent each user from creating separate keys for the same application over and over again. That is, Only the AppOwner will have the privilege to subscribe to an API and re/generate keys with API Manager. The generated keys will be saved in DB and when other users (dev,qa,devops) login, they can only see the generated keys. We will also make SSO disabled and no buttons will be available in UI to go to API Manager for these user roles. If SSO is disabled(API store) how the appowner is going to login and subscribe to API(manually entering the credential again)? Feel free to share your feedback. -- Thanks and Regards, Punnadi Gunarathna Senior Software Engineer, WSO2, Inc.; http://wso2.com http://wso2/ email: punn...@wso2.com lal...@wso2.com http://lalajisureshika.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- ajanthan -- Ajanthan Balachandiran Senior Software Engineer; Solutions Technologies Team ;WSO2, Inc.; http://wso2.com/ email: ajanthan http://goog_595075977/@wso2.com http://wso2.com/; cell: +94775581497 blog: http://bkayts.blogspot.com/ Lean . Enterprise . Middleware ___ 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 -- *Ushani Balasooriya* Software Engineer - QA; WSO2 Inc; http://www.wso2.com/. Mobile; +94772636796 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
