Re: [Architecture] SSO IDP Proxy Application + SDK
Hi Prabath, 1. Can't we use the implicit grant type instead of *Authorization code . * - *Authorization Code* for apps running on a web serverhttp://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#web-server-apps - *Implicit* for browser-basedhttp://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#browser-based-apps or mobile appshttp://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps Any reason why it can't be used. Is that because we use a proxy app and client app ? 2. Also can't we eliminate the use of web view. Rather use direct calls ? 3. Also can we have a custom grant type for mobile application , so that same level of security is achieved ? On Mon, Mar 10, 2014 at 10:39 PM, Chan duli...@wso2.com wrote: IMO we don't revoke mobile app's Consumer key and Consumer secret but revokes the Access token of a user. Next step for this integration is to map access tokens that have been issued for devices. With this integration EMM can revoke access of a mobile device from enterprise resources (APIs) completely by coordinating with IS. Cheers~ On Mon, Mar 10, 2014 at 6:10 PM, Suresh Attanayaka sur...@wso2.comwrote: Hi Manjula, Let me answer inline, On Mon, Mar 10, 2014 at 4:54 PM, Manjula Rathnayake manju...@wso2.comwrote: Hi all, How do we store client secret and access tokens in mobile application? Have we encrypted the client secret? We can let the mobile app developer to implement his own mechanism for this, or if we are supporting this at the SDK, we can use a password to encrypt the client secrete. In case of mobile device is lost, how do we remove the mobile application subscription from OAuth server without affecting to other mobile devices which uses same application? Do we generate the applicationId together with a unique mobile Id? User can always revoke the tokens issued for the application. We can let each application to have its own client-key, client-secrete as well using dynamic client registration. Is the mobile IDP app code signed by a trusted cert? How does the trust relationship works with mobile IDP and WSO2IS? WSO2IS does not have to trust the proxy IDP in the mobile. IS will always validate client-key, client-secrete and will check user authentication at logins. thank you. On Mon, Mar 10, 2014 at 4:37 PM, Gayan Gunawardana ga...@wso2.comwrote: Hi Nira, Reason to do that way is normally client secret does not share with any other party On Mon, Mar 10, 2014 at 4:24 PM, Niranjan Karunanandham niran...@wso2.com wrote: Hi Gayan, Here the IDP proxy app is only used to get the authorization code from the WSO2 IS and pass it to the SDK. After which the SDK is communicates directly with the WSO2 IS to get the access token and manage the access token and refresh token. Just a small clarification why we can't use the IDP proxy app to do this, .i.e, let the IDP proxy app manage the access token and refresh token for each app. Therefore cutting off the connection between the SDK and the WSO2 IS. Here if the access token expires then the SDK will call the IDP proxy app to get the token refreshed. On Mon, Mar 10, 2014 at 3:58 PM, Gayan Gunawardana ga...@wso2.comwrote: Image attached On Mon, Mar 10, 2014 at 3:51 PM, Gayan Gunawardana ga...@wso2.comwrote: Hi All, Problem: Implement SSO for enterprise mobile apps The idea is to provide SDK for mobile apps developers within the organization, then they can integrate SDK inside the application and implement SSO across required applications. Provide (SDK + Mobile IDP proxy app) To achieve above purpose we plan to utilize oauth 2.0 with *Authorization code* grant type. Briefly Explaining message flow : Initially new application has to be registered in WSO2 IS under Oauth management and obtain client_key, client_secret, Access Token Url and Authorize Url 1. SDK initiate the process by sending client_key, redirect_url and scope to mobile IDP proxy app 2. IDP proxy app obtain Authorization code 3. SDK (in side mobile app) receive Authorization code 4. SDK send second request directly to WSO2 IS with Authorization code, client secret and redirect_url 5. SDK obtain access token 6. Mobile app pass access token to resource server 7. Resource server contact IPD and validate access token This is much similar to Facebook approach where facebook application act as mobile IDP proxy app and they provide SDK to develop apps. All your suggestions are welcome. -- Gayan Gunawardana Software Engineer; WSO2 Inc.; http://wso2.com/ Email: ga...@wso2.com Mobile: +94 (71) 8020933 Blog: http://gayanj2ee.blogspot.com/ -- Gayan Gunawardana Software Engineer; WSO2 Inc.; http://wso2.com/ Email: ga...@wso2.com Mobile: +94 (71) 8020933 Blog: http://gayanj2ee.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org
Re: [Architecture] [C5] Jetty integration with carbon kernel
On Tue, Mar 11, 2014 at 12:04 AM, Sagara Gunathunga sag...@wso2.com wrote: On Mon, Mar 10, 2014 at 10:11 PM, Kishanthan Thangarajah kishant...@wso2.com wrote: We have done $subject which can be used for servlet transport in C5 kernel [1]. The embedded jetty instance uses a default jetty.xml configuration file located at $CARBON_HOME/repository/conf/jetty/jetty.xml. The main advantage of jetty is that it is OSGi friendly [2]. It can also expose the OSGi HttpSevice for servlet registrations, etc. We are thinking of using this for the UI framework of carbon. Other servlet container can also be plugged in (Eg: Tomcat with AS) using the plugable run-time concept, but they will use different ports to avoid +1 please see my comments below. 1.) Have we define the scope of Jetty integration within Carbon ? if not we need to define what are the supported Jetty features and what are the features not supported based on our needs. To make it clear we are not trying to make Tomcat kind of integration here instead we need basic servlet support for Admine console, we don't need to support web socket , JSP 2.2 , EL 2.2 etc :) But if we don't define the scope users may confuse and can be treated as a weakness and there is a high chance to compare Carbon-Jetty with Carbon-Tomcat. The current plan is to use this for UI framework, and AdminServices framework (JAX-RS services, which we need the servlet support). We don't need to support all the features of jetty at kernel level. The main purpose of this to remove the dependency of tomcat at kernel level. So that products like AS can independently do changes (like upgrading tomcat). Integration and usage of Tomcat will be same like before (like Apps hosting in AS), but the only change is that UI and AdminServices framework will use Jetty instead. 2.) What are the dependencies required for Jetty and how we going to keep them ? within the Jetty bundle or import from other bundles ? If 2nd one is the approach we need to be very careful and should follow best practises like OSGi versioning etc from day-0. I would prefer if Carbon not exporting dependencies like servlet-api , xml-api etc so that each Carbon product can have control on these dependencies. We could solve these type of issues with proper package imports/exports with versions. 3.) It would be better to avoid publishing Jeety related details on user guides, here Jetty is the underline framework we used but what Carbon user wants is technology to right admin UIs and admin services that's what we need to cover on user guides. One good example is Jetty support on GAE. +1. Thanks ! collisions. Thanks, Kishanthan. [1] https://wso2.org/jira/browse/CARBON-14716 [2] http://wiki.eclipse.org/Jetty/Feature/Jetty_OSGi -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Adding Statistics to API Manager Store
Hi, I've started working on the $subject.The Hive queries written for the publisher dashboard can be reused after some modification. Currently working on 1. Per App / Per API call count Thanks. On Mon, Mar 10, 2014 at 8:58 AM, Uvindra Dias Jayasinha uvin...@wso2.comwrote: Yes Samisa, thats exactly how it will happen. On Sat, Mar 8, 2014 at 7:59 AM, Samisa Abeysinghe sam...@wso2.com wrote: So when BAM is in use, do we publish these stats into BAM and have store oriented developer accessible dashboard? Thanks, Samisa... Samisa Abeysinghe Vice President Developer Evangelism WSO2 Inc. http://wso2.com On Fri, Mar 7, 2014 at 3:18 PM, Uvindra Dias Jayasinha uvin...@wso2.comwrote: Hi All, Currently APIM only publishes stats in its publisher view. We are looking into $subject. This will be primarily targeted at developers who subscribe to API's so that they can get insight into API usage from the store. An API subscription is associated with a given application that is using the API. A given API can also be subscribed to by many applications. Based on this below are the initial stats that we thought would be useful to have, 1. Per App / Per API call count 2. Per App / Number of registered users 3. Per App / Per API faulty invocation count 4. Per App / Per API call type 5. Per App / Top users -- Regards, Uvindra Mobile: 33962 ___ 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 -- Regards, Uvindra Mobile: 33962 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Asiri Liyana Arachchi* Engineering Intern, WSO2 Inc. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] A few questions about WSO2 CEP/Siddhi
First of all, thank you very much for your explanations and clarifications! It is very interesting and useful! Let me ask a few more questions and provide a few comments. Hi All, these questions and answers are very educating. Shall we add them to our doc FAQs? I think it would be a very good idea to add something like this to the FAQs or to create some sort of an architecture and implementation overview document. 1) How many rules/queries can be defined in one engine. How does it affect performance? For example, can I define (tens of) thousands of queries using the same (or multiple) instance of SiddhiManager? Would it make processing much slower? Or is the speed not proportional to the number of queries? E.g. when a new event arrives, does Siddhi test it in a linear fashion against each query or does Siddhi keep an internal state machine that tries to match an event against all rules at once? SiddhiManager can have many queries, and if you chain the queries in a liner fashion then all those queries will be executed one after the other and you might see some performance degradation, but if you have have then parallel then there wont be any issues. Well, before I got this answer, I created a few test-cases to check experimentally how it behaves. I created a single instance of a SiddhiManager, added 1 queries that all read from the same input stream, check if a specific attribute (namely, price) of an event is inside a given random interval ( [ price = random_low and price = random_high] ) and output into randomly into one of 100 streams. Then I measured the time required to process 100 events using this setup. I also did exactly the same experiment with Esper. My findings were that Siddhi is much slower than Esper in this setup. After looking into the internal implementations of both, I realized the reason. Siddhi processes all queries that read from the same input stream in a linear fashion, sequentially. Even if many of the queries have almost the same condition, no optimization attempts are done by Siddhi. Esper detects that many queries have a condition on the same variable and create some sort of a decision tree. As a result, their running time in log N, where as Siddhi needs O(n). I'm not saying that this test-case if very typical or important, but may be Siddhi should try to analyze the complete set of queries and try to apply some optimizations, when it is possible? I.e. it is a bit of a global optimization applied. It could detect some common sub-expressions or sub-conditions in the queries and evaluate them only once, instead of doing it over and over again by evaluating each query separately. After getting these first results, I changed the setup, so that each query uses one of many input streams (e.g. one of 300) instead of using the same one. This greatly improved the situation, because now the number of queries per input stream was much smaller and thus processing was way faster. But even in this setup it is still about 5-6 times slower than Esper in this situation. Could you share your testcases?, and we can have a look. Yes we have not much worked with 1000s of queries much, Yes, I could provide my testcases - the source code is actually pretty small. What is the best way to do it? Should I simply attach a ZIP file with my project or better create a small github project? Could you report a JIRA here https://wso2.org/jira/browse/CEP and attach it? but likely it is something we can fix without much trouble. Sounds promising. 2) Is it possible to easily disable/enable some queries? In my use-cases I have a lot of queries. Actually, I have a lot of tenants and each tenant may have something like 10-100 queries. Rather often (e.g. few times a day), tenants would like to disable/enable some of their queries. What is a proper way to do it? Is it a costly operation, i.e. does Siddhi need to perform a lot of processing to disable or enabled a query? Is it better to keep a dedicated SiddhiManager instance per tenant or is it OK to have one SiddhiManager instance which handles all those tenants with all their queries? The general norm is, you have to use a SiddhiManager per scenario, where each scenario might contain one or more queries, with this modal its easy if any tenant want to add a remove a scenario and it will not affect other queries and tenants. If I have tens of thousands of tenants, then having a dedicated SiddhiManager per tenant is probably not very practical or even possible, as it will get pretty heave weight, I guess. Therefore, having the ability to enable/disable to query could be very practical. In fact, it could be probably implemented very easily. Imagine that each query object has a boolean flag that indicates if it is enabled or not. If the condition matches and before Siddhi tries to perform the insert, i.e. the action, it could check if the
Re: [Architecture] WSO2 Products Tenant Creation Process calls the Reset Password
Well By having custom userstores and tenant stores, someone can have shared users and someone can create tenants with an existing user. But this call breaks everything since its trying to reset the password of the given user. @Manjula : Will check about hashing. Didn't aware about that. Thanks Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 On Mon, Mar 10, 2014 at 10:28 PM, Amila Maha Arachchi ami...@wso2.comwrote: What are the issues of having this? On Thu, Mar 6, 2014 at 9:08 AM, Danushka Fernando danush...@wso2.comwrote: Hi all I found that our tenant creation process is calling reset password call inside tenant creation process. When we call tenant creation it goes through *persistTenant* call in *TenantPersistor* class. And it calls *persistTenantInUserStore*. In the end of this call it calls for *updateTenantAdminPassword*. By the time Tenant Manager is created the tenant admin and have added the password to the LDAP. So is there a particular reason that we should do this? I cant see any reason that we call the update/reset password at this moment. So IMO we should remove this if no such reason. WDYT? Thanks Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 -- *Amila Maharachchi* Senior Technical Lead WSO2, Inc.; http://wso2.com Blog: http://maharachchi.blogspot.com Mobile: +94719371446 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] G-Reg vs ES for artefacts
Hi all, IMHO, G-Reg will focus on the Governance aspect. The governance of Service Providers' artefacts will happen through G-Reg, and it will continue to support SOA Governance as first-class. But, for use-cases involving Artefacts/Store, it will be ES. ES will also provide a complete lifecycle. But, without a governed workflow. This is where I was trying to get to in the AM thread on workflows. If we properly separate the lifecycle and governed workflow associated with a lifecycle we can clearly differentiate G-Reg and ES, AFAIU. G-Reg will have an embedded store, just like AM, but with limited scope. Thanks, Senaka. On Tue, Mar 11, 2014 at 8:54 AM, Ruchira Wageesha ruch...@wso2.com wrote: Hi Janaka, Immediate/blocking requirements were fixed in 1.0.1 branch[1] and we will do a patch release of 1.0.0. All the features and major improvements will go with 1.1.0 and has planed to release at least an Alpha by the end of Q1. [2], [3] and [4] issues reported by Chandana have already been fixed in [1]. /Ruchira [1] https://github.com/wso2/enterprise-store/tree/es-1.0.1-apm-reg [2] https://wso2.org/jira/browse/STORE-391 [3] https://wso2.org/jira/browse/STORE-394 [4] https://wso2.org/jira/browse/STORE-395 On Tue, Mar 11, 2014 at 7:16 AM, Janaka Ranabahu jan...@wso2.com wrote: Hi Guys, Will these limitations get fixed in the upcoming release? If so do we have a timeline for that? Thanks, Janaka On Sat, Mar 8, 2014 at 10:43 AM, Chandana Napagoda chand...@wso2.comwrote: Hi Samisa In addition to above issue, ES is still not supporting all the RXT configuration elements(ex: unbounded table option) which are currently supported by G-Reg. We have reported JIRAs to get those added to coming up releases. Regards, Chandana On Mar 8, 2014 7:09 AM, Janaka Ranabahu jan...@wso2.com wrote: Hi Samisa, IMO, it should be ES. But the current ES architecture does not pick new RXT types automatically and some configurations to jaggery config files are required to show the new asset in both Store and Publisher[1]. Until we have a more flexible way of generating the Store and Publisher UI, I believe we have to stick with G-Reg. Thanks, Janaka [1] https://docs.wso2.org/display/ES100/Adding+a+New+Asset+Type On Fri, Mar 7, 2014 at 8:08 PM, Samisa Abeysinghe sam...@wso2.comwrote: We used to position G-Reg as a store of anything with RXT. Now what ES is there, and is more capable, do we propose the users use ES or G-Reg RXT like use cases? Thanks, Samisa... Samisa Abeysinghe Vice President Developer Evangelism WSO2 Inc. http://wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Janaka Ranabahu* Senior Software Engineer; WSO2 Inc.; http://wso2.com * E-mail: jan...@wso2.com http://wso2.com**M: **+94 718370861 %2B94%20718370861* 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 -- *Janaka Ranabahu* Senior Software Engineer; WSO2 Inc.; http://wso2.com * E-mail: jan...@wso2.com http://wso2.com**M: **+94 718370861 %2B94%20718370861* Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Ruchira Wageesha**Associate Technical Lead* *WSO2 Inc. - lean . enterprise . middleware | wso2.com http://wso2.com* *email: ruch...@wso2.com ruch...@wso2.com, blog: ruchirawageesha.blogspot.com http://ruchirawageesha.blogspot.com, mobile: +94 77 5493444 %2B94%2077%205493444* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *[image: http://wso2.com] http://wso2.com Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://linkedin.com/in/senakafernando http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] G-Reg vs ES for artefacts
Why not governed workflow in ES? In case of LCs, people always have use cases to plug-in workflows. Thanks, Samisa... Samisa Abeysinghe Vice President Developer Evangelism WSO2 Inc. http://wso2.com On Tue, Mar 11, 2014 at 10:51 PM, Senaka Fernando sen...@wso2.com wrote: Hi all, IMHO, G-Reg will focus on the Governance aspect. The governance of Service Providers' artefacts will happen through G-Reg, and it will continue to support SOA Governance as first-class. But, for use-cases involving Artefacts/Store, it will be ES. ES will also provide a complete lifecycle. But, without a governed workflow. This is where I was trying to get to in the AM thread on workflows. If we properly separate the lifecycle and governed workflow associated with a lifecycle we can clearly differentiate G-Reg and ES, AFAIU. G-Reg will have an embedded store, just like AM, but with limited scope. Thanks, Senaka. On Tue, Mar 11, 2014 at 8:54 AM, Ruchira Wageesha ruch...@wso2.comwrote: Hi Janaka, Immediate/blocking requirements were fixed in 1.0.1 branch[1] and we will do a patch release of 1.0.0. All the features and major improvements will go with 1.1.0 and has planed to release at least an Alpha by the end of Q1. [2], [3] and [4] issues reported by Chandana have already been fixed in [1]. /Ruchira [1] https://github.com/wso2/enterprise-store/tree/es-1.0.1-apm-reg [2] https://wso2.org/jira/browse/STORE-391 [3] https://wso2.org/jira/browse/STORE-394 [4] https://wso2.org/jira/browse/STORE-395 On Tue, Mar 11, 2014 at 7:16 AM, Janaka Ranabahu jan...@wso2.com wrote: Hi Guys, Will these limitations get fixed in the upcoming release? If so do we have a timeline for that? Thanks, Janaka On Sat, Mar 8, 2014 at 10:43 AM, Chandana Napagoda chand...@wso2.comwrote: Hi Samisa In addition to above issue, ES is still not supporting all the RXT configuration elements(ex: unbounded table option) which are currently supported by G-Reg. We have reported JIRAs to get those added to coming up releases. Regards, Chandana On Mar 8, 2014 7:09 AM, Janaka Ranabahu jan...@wso2.com wrote: Hi Samisa, IMO, it should be ES. But the current ES architecture does not pick new RXT types automatically and some configurations to jaggery config files are required to show the new asset in both Store and Publisher[1]. Until we have a more flexible way of generating the Store and Publisher UI, I believe we have to stick with G-Reg. Thanks, Janaka [1] https://docs.wso2.org/display/ES100/Adding+a+New+Asset+Type On Fri, Mar 7, 2014 at 8:08 PM, Samisa Abeysinghe sam...@wso2.comwrote: We used to position G-Reg as a store of anything with RXT. Now what ES is there, and is more capable, do we propose the users use ES or G-Reg RXT like use cases? Thanks, Samisa... Samisa Abeysinghe Vice President Developer Evangelism WSO2 Inc. http://wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Janaka Ranabahu* Senior Software Engineer; WSO2 Inc.; http://wso2.com * E-mail: jan...@wso2.com http://wso2.com**M: **+94 718370861 %2B94%20718370861* 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 -- *Janaka Ranabahu* Senior Software Engineer; WSO2 Inc.; http://wso2.com * E-mail: jan...@wso2.com http://wso2.com**M: **+94 718370861 %2B94%20718370861* Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Ruchira Wageesha**Associate Technical Lead* *WSO2 Inc. - lean . enterprise . middleware | wso2.com http://wso2.com* *email: ruch...@wso2.com ruch...@wso2.com, blog: ruchirawageesha.blogspot.com http://ruchirawageesha.blogspot.com, mobile: +94 77 5493444 %2B94%2077%205493444* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *[image: http://wso2.com] http://wso2.com Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1 408 754 7388 %2B1%20408%20754%207388; ext: 51736*; *M: +94 77 322 1818 %2B94%2077%20322%201818 Linked-In: http://linkedin.com/in/senakafernando http://linkedin.com/in/senakafernando* Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org
Re: [Architecture] [C5] Jetty integration with carbon kernel
IMO, the UI framework/Jetty integration should be outside the kernel. Azeez On Tue, Mar 11, 2014 at 12:52 PM, Kishanthan Thangarajah kishant...@wso2.com wrote: On Tue, Mar 11, 2014 at 12:04 AM, Sagara Gunathunga sag...@wso2.comwrote: On Mon, Mar 10, 2014 at 10:11 PM, Kishanthan Thangarajah kishant...@wso2.com wrote: We have done $subject which can be used for servlet transport in C5 kernel [1]. The embedded jetty instance uses a default jetty.xml configuration file located at $CARBON_HOME/repository/conf/jetty/jetty.xml. The main advantage of jetty is that it is OSGi friendly [2]. It can also expose the OSGi HttpSevice for servlet registrations, etc. We are thinking of using this for the UI framework of carbon. Other servlet container can also be plugged in (Eg: Tomcat with AS) using the plugable run-time concept, but they will use different ports to avoid +1 please see my comments below. 1.) Have we define the scope of Jetty integration within Carbon ? if not we need to define what are the supported Jetty features and what are the features not supported based on our needs. To make it clear we are not trying to make Tomcat kind of integration here instead we need basic servlet support for Admine console, we don't need to support web socket , JSP 2.2 , EL 2.2 etc :) But if we don't define the scope users may confuse and can be treated as a weakness and there is a high chance to compare Carbon-Jetty with Carbon-Tomcat. The current plan is to use this for UI framework, and AdminServices framework (JAX-RS services, which we need the servlet support). We don't need to support all the features of jetty at kernel level. The main purpose of this to remove the dependency of tomcat at kernel level. So that products like AS can independently do changes (like upgrading tomcat). Integration and usage of Tomcat will be same like before (like Apps hosting in AS), but the only change is that UI and AdminServices framework will use Jetty instead. 2.) What are the dependencies required for Jetty and how we going to keep them ? within the Jetty bundle or import from other bundles ? If 2nd one is the approach we need to be very careful and should follow best practises like OSGi versioning etc from day-0. I would prefer if Carbon not exporting dependencies like servlet-api , xml-api etc so that each Carbon product can have control on these dependencies. We could solve these type of issues with proper package imports/exports with versions. 3.) It would be better to avoid publishing Jeety related details on user guides, here Jetty is the underline framework we used but what Carbon user wants is technology to right admin UIs and admin services that's what we need to cover on user guides. One good example is Jetty support on GAE. +1. Thanks ! collisions. Thanks, Kishanthan. [1] https://wso2.org/jira/browse/CARBON-14716 [2] http://wiki.eclipse.org/Jetty/Feature/Jetty_OSGi -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/* *email: **az...@wso2.com* az...@wso2.com * cell: +94 77 3320919 blog: **http://blog.afkham.org*http://blog.afkham.org *twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez * linked-in: **http://lk.linkedin.com/in/afkhamazeez http://lk.linkedin.com/in/afkhamazeez* *Lean . Enterprise . Middleware* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
