Re: [Dev] [Architecture] Current Status of The Registry REST API and Issues I face when Integrate with APIM
Hi Vijitha, On Tue, Jul 16, 2013 at 8:08 AM, Vijitha Kumara viji...@wso2.com wrote: Had a chat with Lakmali about this. As of now this requires a manual publishing of the REST API, but since this is a feature of the registry itself it would be good to ship it published OOTB? +1. AFAIK there will be few admin services as well that need to do the API Management in this release of GReg. Since all together there are only few APIs that required API Management, it's good to ship them published OOTB. As we are not letting the REST API to be accessed without going through APIM component, the EnableAPIManagement property should be set to true by default as well or it can be ignored altogether? Or we can have a different property to denote any other aspect to be enabled//disabled other than default ones here? The EnableAPIManagement property is a global one, that can be used by other products as well. So, if GReg need this only for REST API and it need not be accessed without API Management, you can set the default value of this property to 'true' in GReg and override the carbon.xml at the product level. Regards, Dinusha. Regards, Vijitha. On Sun, Jul 14, 2013 at 9:09 PM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi Vijitha, On Sun, Jul 14, 2013 at 11:13 AM, Vijitha Kumara viji...@wso2.comwrote: Hi All, What's the status of this now? Do we have a working use case to be reviewed? We might need to finalize test within next few days. We have committed changes to trunk and have completed basic testing. You can use trunk GReg pack for testing.. Regards, Dinusha. Regards, Vijitha. On Thu, Jun 20, 2013 at 11:20 AM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi Ragu, On Thu, Jun 20, 2013 at 10:52 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hi Lakmali and Dinusha, As you have been completed the tomcat valve, shall I use the tomcat valve ( kind of interceptor) to test the Registry REST API with the externally running API Manager instance ? We are still working on supporting externally running API Manager instance. Will try to finish this by EOT.. But you can use inbuilt api-mgt support to test registry REST API. We have some concerns regarding the registry REST API; 1. We need to have versioning support there. In the current API does not have the versions support.. 2. We need to pass both userName and tenantId as query params, if some user need to use the registry REST API. Having the user name is fine, but tenantId is something external users don't know. So having to pass tenantId to invoke rest API is not correct as we see. eg : http://localhost:9763/resource/comments?path=/_system/governance/apimgt/apiconf.xml; *username=admintenantid=-1234 * Regards, Dinusha. Thanks, Ragu On Tue, Jun 18, 2013 at 1:20 PM, Dinusha Senanayaka dinu...@wso2.comwrote: On Tue, Jun 18, 2013 at 12:59 PM, Sriragu Arudsothy srir...@wso2.com wrote: Hai Dinusha, At the later part of your answer, you mentioned the how to send the request. Do we have a use case where without API manager. AFAIR, It has been clearly said during the final discussion , request will be given inbuilt or external APIM. But you mention about without APIM. But, when it comes to services like DSS, AS etc, we need to have this capability. Services, should be able to invoke with api management or without api management. yes, for the GRreg (in built apis), manageAPIs will be always true. Regards, Dinusha. Thanks! Ragu On Tue, Jun 18, 2013 at 12:31 PM, Dinusha Senanayaka dinu...@wso2.com wrote: Hi Ragu, We have wrote a Tomcat Valve which will be act as interceptor for all incoming requests. There was a need of using Axis2ConfigurationContextObserver to get the throttling related properties, which cannot be done through the CXF hander in GREG REST API. This tomcat valve can be used not only by the GReg, also from any other product like AS, DSS when it comes to manage APIs. Also we have been working on, getting publisher and store jaggery apps into Greg. It was not straight forward because just putting these apps into GReg wont work. We had do some code changes in apimgt side to avoid synapse dependencies. As an example, api-store and publisher need to have apimgt-impl component been activated and while this module getting activated we are creating the tenant artifacts by coping synapse.xml files into synapse deployment directories of tenants. We had to customize apimgt code that it can identify the where api management is doing and avoid these synapse related tasks. On Tue, Jun 18, 2013 at 9:43 AM, Sriragu Arudsothy srir...@wso2.com wrote: Hai Dinusha and Lakmali, Please update this mail thread that what have you done so far regarding the Lightweight API manager component. 1) Please let me know the strategy that you are using when
Re: [Dev] [Architecture] Current Status of The Registry REST API and Issues I face when Integrate with APIM
Had a chat with Lakmali about this. As of now this requires a manual publishing of the REST API, but since this is a feature of the registry itself it would be good to ship it published OOTB? As we are not letting the REST API to be accessed without going through APIM component, the EnableAPIManagement property should be set to true by default as well or it can be ignored altogether? Or we can have a different property to denote any other aspect to be enabled//disabled other than default ones here? Regards, Vijitha. On Sun, Jul 14, 2013 at 9:09 PM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi Vijitha, On Sun, Jul 14, 2013 at 11:13 AM, Vijitha Kumara viji...@wso2.com wrote: Hi All, What's the status of this now? Do we have a working use case to be reviewed? We might need to finalize test within next few days. We have committed changes to trunk and have completed basic testing. You can use trunk GReg pack for testing.. Regards, Dinusha. Regards, Vijitha. On Thu, Jun 20, 2013 at 11:20 AM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi Ragu, On Thu, Jun 20, 2013 at 10:52 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hi Lakmali and Dinusha, As you have been completed the tomcat valve, shall I use the tomcat valve ( kind of interceptor) to test the Registry REST API with the externally running API Manager instance ? We are still working on supporting externally running API Manager instance. Will try to finish this by EOT.. But you can use inbuilt api-mgt support to test registry REST API. We have some concerns regarding the registry REST API; 1. We need to have versioning support there. In the current API does not have the versions support.. 2. We need to pass both userName and tenantId as query params, if some user need to use the registry REST API. Having the user name is fine, but tenantId is something external users don't know. So having to pass tenantId to invoke rest API is not correct as we see. eg : http://localhost:9763/resource/comments?path=/_system/governance/apimgt/apiconf.xml; *username=admintenantid=-1234 * Regards, Dinusha. Thanks, Ragu On Tue, Jun 18, 2013 at 1:20 PM, Dinusha Senanayaka dinu...@wso2.comwrote: On Tue, Jun 18, 2013 at 12:59 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Dinusha, At the later part of your answer, you mentioned the how to send the request. Do we have a use case where without API manager. AFAIR, It has been clearly said during the final discussion , request will be given inbuilt or external APIM. But you mention about without APIM. But, when it comes to services like DSS, AS etc, we need to have this capability. Services, should be able to invoke with api management or without api management. yes, for the GRreg (in built apis), manageAPIs will be always true. Regards, Dinusha. Thanks! Ragu On Tue, Jun 18, 2013 at 12:31 PM, Dinusha Senanayaka dinu...@wso2.com wrote: Hi Ragu, We have wrote a Tomcat Valve which will be act as interceptor for all incoming requests. There was a need of using Axis2ConfigurationContextObserver to get the throttling related properties, which cannot be done through the CXF hander in GREG REST API. This tomcat valve can be used not only by the GReg, also from any other product like AS, DSS when it comes to manage APIs. Also we have been working on, getting publisher and store jaggery apps into Greg. It was not straight forward because just putting these apps into GReg wont work. We had do some code changes in apimgt side to avoid synapse dependencies. As an example, api-store and publisher need to have apimgt-impl component been activated and while this module getting activated we are creating the tenant artifacts by coping synapse.xml files into synapse deployment directories of tenants. We had to customize apimgt code that it can identify the where api management is doing and avoid these synapse related tasks. On Tue, Jun 18, 2013 at 9:43 AM, Sriragu Arudsothy srir...@wso2.com wrote: Hai Dinusha and Lakmali, Please update this mail thread that what have you done so far regarding the Lightweight API manager component. 1) Please let me know the strategy that you are using when integrate the external API manager instance. 2) when an API manager instance externally running, Do we need to call the API published at the API gateway? or Does the user call the Registry REST API and re-directing the URL to API gateway URL? 3) If it is a lightweight APIM component which resides within G-Reg, Will the request be given to Registry REST API ? Answering to the Q 1, 2, 3: Always user request will be to the G-Reg API. If the ManageAPIs is enabled then API Management will be handle through the embedded apimgt components. And If ManageAPIs enabled and if it has been provided Store, Publisher, Gateway, KeyManager urls,
Re: [Dev] [Architecture] Current Status of The Registry REST API and Issues I face when Integrate with APIM
Hi Vijitha, On Sun, Jul 14, 2013 at 11:13 AM, Vijitha Kumara viji...@wso2.com wrote: Hi All, What's the status of this now? Do we have a working use case to be reviewed? We might need to finalize test within next few days. We have committed changes to trunk and have completed basic testing. You can use trunk GReg pack for testing.. Regards, Dinusha. Regards, Vijitha. On Thu, Jun 20, 2013 at 11:20 AM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi Ragu, On Thu, Jun 20, 2013 at 10:52 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hi Lakmali and Dinusha, As you have been completed the tomcat valve, shall I use the tomcat valve ( kind of interceptor) to test the Registry REST API with the externally running API Manager instance ? We are still working on supporting externally running API Manager instance. Will try to finish this by EOT.. But you can use inbuilt api-mgt support to test registry REST API. We have some concerns regarding the registry REST API; 1. We need to have versioning support there. In the current API does not have the versions support.. 2. We need to pass both userName and tenantId as query params, if some user need to use the registry REST API. Having the user name is fine, but tenantId is something external users don't know. So having to pass tenantId to invoke rest API is not correct as we see. eg : http://localhost:9763/resource/comments?path=/_system/governance/apimgt/apiconf.xml; *username=admintenantid=-1234 * Regards, Dinusha. Thanks, Ragu On Tue, Jun 18, 2013 at 1:20 PM, Dinusha Senanayaka dinu...@wso2.comwrote: On Tue, Jun 18, 2013 at 12:59 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Dinusha, At the later part of your answer, you mentioned the how to send the request. Do we have a use case where without API manager. AFAIR, It has been clearly said during the final discussion , request will be given inbuilt or external APIM. But you mention about without APIM. But, when it comes to services like DSS, AS etc, we need to have this capability. Services, should be able to invoke with api management or without api management. yes, for the GRreg (in built apis), manageAPIs will be always true. Regards, Dinusha. Thanks! Ragu On Tue, Jun 18, 2013 at 12:31 PM, Dinusha Senanayaka dinu...@wso2.com wrote: Hi Ragu, We have wrote a Tomcat Valve which will be act as interceptor for all incoming requests. There was a need of using Axis2ConfigurationContextObserver to get the throttling related properties, which cannot be done through the CXF hander in GREG REST API. This tomcat valve can be used not only by the GReg, also from any other product like AS, DSS when it comes to manage APIs. Also we have been working on, getting publisher and store jaggery apps into Greg. It was not straight forward because just putting these apps into GReg wont work. We had do some code changes in apimgt side to avoid synapse dependencies. As an example, api-store and publisher need to have apimgt-impl component been activated and while this module getting activated we are creating the tenant artifacts by coping synapse.xml files into synapse deployment directories of tenants. We had to customize apimgt code that it can identify the where api management is doing and avoid these synapse related tasks. On Tue, Jun 18, 2013 at 9:43 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Dinusha and Lakmali, Please update this mail thread that what have you done so far regarding the Lightweight API manager component. 1) Please let me know the strategy that you are using when integrate the external API manager instance. 2) when an API manager instance externally running, Do we need to call the API published at the API gateway? or Does the user call the Registry REST API and re-directing the URL to API gateway URL? 3) If it is a lightweight APIM component which resides within G-Reg, Will the request be given to Registry REST API ? Answering to the Q 1, 2, 3: Always user request will be to the G-Reg API. If the ManageAPIs is enabled then API Management will be handle through the embedded apimgt components. And If ManageAPIs enabled and if it has been provided Store, Publisher, Gateway, KeyManager urls, then request will be redirect to the external api manager. Always, request will be first hit at the tomcat valve that we have added, logic will be reside in this valve , how api management is handling, whether inbuilt, external or without api management. Regards, Dinusha. What has to be done to complete it ? Because the Greg has a strict dead line to finish off by next week ? Thanks! Ragu On Mon, Jun 10, 2013 at 6:31 PM, Sriragu Arudsothy srir...@wso2.com wrote: Hai Sanjeewa..! We are having a strategic discussion that how to include the API publisher/ store jag
Re: [Dev] [Architecture] Current Status of The Registry REST API and Issues I face when Integrate with APIM
Hi All, What's the status of this now? Do we have a working use case to be reviewed? We might need to finalize test within next few days. Regards, Vijitha. On Thu, Jun 20, 2013 at 11:20 AM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi Ragu, On Thu, Jun 20, 2013 at 10:52 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hi Lakmali and Dinusha, As you have been completed the tomcat valve, shall I use the tomcat valve ( kind of interceptor) to test the Registry REST API with the externally running API Manager instance ? We are still working on supporting externally running API Manager instance. Will try to finish this by EOT.. But you can use inbuilt api-mgt support to test registry REST API. We have some concerns regarding the registry REST API; 1. We need to have versioning support there. In the current API does not have the versions support.. 2. We need to pass both userName and tenantId as query params, if some user need to use the registry REST API. Having the user name is fine, but tenantId is something external users don't know. So having to pass tenantId to invoke rest API is not correct as we see. eg : http://localhost:9763/resource/comments?path=/_system/governance/apimgt/apiconf.xml; *username=admintenantid=-1234 * Regards, Dinusha. Thanks, Ragu On Tue, Jun 18, 2013 at 1:20 PM, Dinusha Senanayaka dinu...@wso2.comwrote: On Tue, Jun 18, 2013 at 12:59 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Dinusha, At the later part of your answer, you mentioned the how to send the request. Do we have a use case where without API manager. AFAIR, It has been clearly said during the final discussion , request will be given inbuilt or external APIM. But you mention about without APIM. But, when it comes to services like DSS, AS etc, we need to have this capability. Services, should be able to invoke with api management or without api management. yes, for the GRreg (in built apis), manageAPIs will be always true. Regards, Dinusha. Thanks! Ragu On Tue, Jun 18, 2013 at 12:31 PM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi Ragu, We have wrote a Tomcat Valve which will be act as interceptor for all incoming requests. There was a need of using Axis2ConfigurationContextObserver to get the throttling related properties, which cannot be done through the CXF hander in GREG REST API. This tomcat valve can be used not only by the GReg, also from any other product like AS, DSS when it comes to manage APIs. Also we have been working on, getting publisher and store jaggery apps into Greg. It was not straight forward because just putting these apps into GReg wont work. We had do some code changes in apimgt side to avoid synapse dependencies. As an example, api-store and publisher need to have apimgt-impl component been activated and while this module getting activated we are creating the tenant artifacts by coping synapse.xml files into synapse deployment directories of tenants. We had to customize apimgt code that it can identify the where api management is doing and avoid these synapse related tasks. On Tue, Jun 18, 2013 at 9:43 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Dinusha and Lakmali, Please update this mail thread that what have you done so far regarding the Lightweight API manager component. 1) Please let me know the strategy that you are using when integrate the external API manager instance. 2) when an API manager instance externally running, Do we need to call the API published at the API gateway? or Does the user call the Registry REST API and re-directing the URL to API gateway URL? 3) If it is a lightweight APIM component which resides within G-Reg, Will the request be given to Registry REST API ? Answering to the Q 1, 2, 3: Always user request will be to the G-Reg API. If the ManageAPIs is enabled then API Management will be handle through the embedded apimgt components. And If ManageAPIs enabled and if it has been provided Store, Publisher, Gateway, KeyManager urls, then request will be redirect to the external api manager. Always, request will be first hit at the tomcat valve that we have added, logic will be reside in this valve , how api management is handling, whether inbuilt, external or without api management. Regards, Dinusha. What has to be done to complete it ? Because the Greg has a strict dead line to finish off by next week ? Thanks! Ragu On Mon, Jun 10, 2013 at 6:31 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Sanjeewa..! We are having a strategic discussion that how to include the API publisher/ store jag apps to other products. Therefore, I will update this thread after the discussion...! As far as I understand, there will be single interceptor which decides the processing path according to the manageAPIs property value.
Re: [Dev] [Architecture] Current Status of The Registry REST API and Issues I face when Integrate with APIM
Hi Lakmali and Dinusha, As you have been completed the tomcat valve, shall I use the tomcat valve ( kind of interceptor) to test the Registry REST API with the externally running API Manager instance ? Thanks, Ragu On Tue, Jun 18, 2013 at 1:20 PM, Dinusha Senanayaka dinu...@wso2.comwrote: On Tue, Jun 18, 2013 at 12:59 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Dinusha, At the later part of your answer, you mentioned the how to send the request. Do we have a use case where without API manager. AFAIR, It has been clearly said during the final discussion , request will be given inbuilt or external APIM. But you mention about without APIM. But, when it comes to services like DSS, AS etc, we need to have this capability. Services, should be able to invoke with api management or without api management. yes, for the GRreg (in built apis), manageAPIs will be always true. Regards, Dinusha. Thanks! Ragu On Tue, Jun 18, 2013 at 12:31 PM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi Ragu, We have wrote a Tomcat Valve which will be act as interceptor for all incoming requests. There was a need of using Axis2ConfigurationContextObserver to get the throttling related properties, which cannot be done through the CXF hander in GREG REST API. This tomcat valve can be used not only by the GReg, also from any other product like AS, DSS when it comes to manage APIs. Also we have been working on, getting publisher and store jaggery apps into Greg. It was not straight forward because just putting these apps into GReg wont work. We had do some code changes in apimgt side to avoid synapse dependencies. As an example, api-store and publisher need to have apimgt-impl component been activated and while this module getting activated we are creating the tenant artifacts by coping synapse.xml files into synapse deployment directories of tenants. We had to customize apimgt code that it can identify the where api management is doing and avoid these synapse related tasks. On Tue, Jun 18, 2013 at 9:43 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Dinusha and Lakmali, Please update this mail thread that what have you done so far regarding the Lightweight API manager component. 1) Please let me know the strategy that you are using when integrate the external API manager instance. 2) when an API manager instance externally running, Do we need to call the API published at the API gateway? or Does the user call the Registry REST API and re-directing the URL to API gateway URL? 3) If it is a lightweight APIM component which resides within G-Reg, Will the request be given to Registry REST API ? Answering to the Q 1, 2, 3: Always user request will be to the G-Reg API. If the ManageAPIs is enabled then API Management will be handle through the embedded apimgt components. And If ManageAPIs enabled and if it has been provided Store, Publisher, Gateway, KeyManager urls, then request will be redirect to the external api manager. Always, request will be first hit at the tomcat valve that we have added, logic will be reside in this valve , how api management is handling, whether inbuilt, external or without api management. Regards, Dinusha. What has to be done to complete it ? Because the Greg has a strict dead line to finish off by next week ? Thanks! Ragu On Mon, Jun 10, 2013 at 6:31 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Sanjeewa..! We are having a strategic discussion that how to include the API publisher/ store jag apps to other products. Therefore, I will update this thread after the discussion...! As far as I understand, there will be single interceptor which decides the processing path according to the manageAPIs property value. Thanks! Ragu On Mon, Jun 10, 2013 at 6:03 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Lakmali..! Yes, the above link does not work...! I moved the user token generation menu under the Resources menu in order to appear for Greg. Therefore the existing doc won't work. Also these changes have not yet been committed. I will give you , the locally built latest Greg 4.6.0 pack which has every thing. You can also try out some samples. When you get the access token via that option , that access token will be based on Client_Credentials grant type. Since the API store jag app will be there anyway to incorporate the light weight APIM component. Therefore the users are required to generate the access token via store when the manage APIs property set to true. Therefore I have to update the doc for generating the access token for either manageApis property set to true or false. I will update the Doc as quickly as possible. Thanks! Ragu On Mon, Jun 10, 2013 at 4:45 PM, Sanjeewa Malalgoda sanje...@wso2.com wrote: On Mon, Jun 10, 2013 at 4:08 PM,
Re: [Dev] [Architecture] Current Status of The Registry REST API and Issues I face when Integrate with APIM
Hi Ragu, On Thu, Jun 20, 2013 at 10:52 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hi Lakmali and Dinusha, As you have been completed the tomcat valve, shall I use the tomcat valve ( kind of interceptor) to test the Registry REST API with the externally running API Manager instance ? We are still working on supporting externally running API Manager instance. Will try to finish this by EOT.. But you can use inbuilt api-mgt support to test registry REST API. We have some concerns regarding the registry REST API; 1. We need to have versioning support there. In the current API does not have the versions support.. 2. We need to pass both userName and tenantId as query params, if some user need to use the registry REST API. Having the user name is fine, but tenantId is something external users don't know. So having to pass tenantId to invoke rest API is not correct as we see. eg : http://localhost:9763/resource/comments?path=/_system/governance/apimgt/apiconf.xml; *username=admintenantid=-1234 * Regards, Dinusha. Thanks, Ragu On Tue, Jun 18, 2013 at 1:20 PM, Dinusha Senanayaka dinu...@wso2.comwrote: On Tue, Jun 18, 2013 at 12:59 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Dinusha, At the later part of your answer, you mentioned the how to send the request. Do we have a use case where without API manager. AFAIR, It has been clearly said during the final discussion , request will be given inbuilt or external APIM. But you mention about without APIM. But, when it comes to services like DSS, AS etc, we need to have this capability. Services, should be able to invoke with api management or without api management. yes, for the GRreg (in built apis), manageAPIs will be always true. Regards, Dinusha. Thanks! Ragu On Tue, Jun 18, 2013 at 12:31 PM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi Ragu, We have wrote a Tomcat Valve which will be act as interceptor for all incoming requests. There was a need of using Axis2ConfigurationContextObserver to get the throttling related properties, which cannot be done through the CXF hander in GREG REST API. This tomcat valve can be used not only by the GReg, also from any other product like AS, DSS when it comes to manage APIs. Also we have been working on, getting publisher and store jaggery apps into Greg. It was not straight forward because just putting these apps into GReg wont work. We had do some code changes in apimgt side to avoid synapse dependencies. As an example, api-store and publisher need to have apimgt-impl component been activated and while this module getting activated we are creating the tenant artifacts by coping synapse.xml files into synapse deployment directories of tenants. We had to customize apimgt code that it can identify the where api management is doing and avoid these synapse related tasks. On Tue, Jun 18, 2013 at 9:43 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Dinusha and Lakmali, Please update this mail thread that what have you done so far regarding the Lightweight API manager component. 1) Please let me know the strategy that you are using when integrate the external API manager instance. 2) when an API manager instance externally running, Do we need to call the API published at the API gateway? or Does the user call the Registry REST API and re-directing the URL to API gateway URL? 3) If it is a lightweight APIM component which resides within G-Reg, Will the request be given to Registry REST API ? Answering to the Q 1, 2, 3: Always user request will be to the G-Reg API. If the ManageAPIs is enabled then API Management will be handle through the embedded apimgt components. And If ManageAPIs enabled and if it has been provided Store, Publisher, Gateway, KeyManager urls, then request will be redirect to the external api manager. Always, request will be first hit at the tomcat valve that we have added, logic will be reside in this valve , how api management is handling, whether inbuilt, external or without api management. Regards, Dinusha. What has to be done to complete it ? Because the Greg has a strict dead line to finish off by next week ? Thanks! Ragu On Mon, Jun 10, 2013 at 6:31 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Sanjeewa..! We are having a strategic discussion that how to include the API publisher/ store jag apps to other products. Therefore, I will update this thread after the discussion...! As far as I understand, there will be single interceptor which decides the processing path according to the manageAPIs property value. Thanks! Ragu On Mon, Jun 10, 2013 at 6:03 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Lakmali..! Yes, the above link does not work...! I moved the user token generation menu under the Resources menu in order to appear for Greg. Therefore
Re: [Dev] [Architecture] Current Status of The Registry REST API and Issues I face when Integrate with APIM
Hai Dinusha, At the later part of your answer, you mentioned the how to send the request. Do we have a use case where without API manager. AFAIR, It has been clearly said during the final discussion , request will be given inbuilt or external APIM. But you mention about without APIM. Thanks! Ragu On Tue, Jun 18, 2013 at 12:31 PM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi Ragu, We have wrote a Tomcat Valve which will be act as interceptor for all incoming requests. There was a need of using Axis2ConfigurationContextObserver to get the throttling related properties, which cannot be done through the CXF hander in GREG REST API. This tomcat valve can be used not only by the GReg, also from any other product like AS, DSS when it comes to manage APIs. Also we have been working on, getting publisher and store jaggery apps into Greg. It was not straight forward because just putting these apps into GReg wont work. We had do some code changes in apimgt side to avoid synapse dependencies. As an example, api-store and publisher need to have apimgt-impl component been activated and while this module getting activated we are creating the tenant artifacts by coping synapse.xml files into synapse deployment directories of tenants. We had to customize apimgt code that it can identify the where api management is doing and avoid these synapse related tasks. On Tue, Jun 18, 2013 at 9:43 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Dinusha and Lakmali, Please update this mail thread that what have you done so far regarding the Lightweight API manager component. 1) Please let me know the strategy that you are using when integrate the external API manager instance. 2) when an API manager instance externally running, Do we need to call the API published at the API gateway? or Does the user call the Registry REST API and re-directing the URL to API gateway URL? 3) If it is a lightweight APIM component which resides within G-Reg, Will the request be given to Registry REST API ? Answering to the Q 1, 2, 3: Always user request will be to the G-Reg API. If the ManageAPIs is enabled then API Management will be handle through the embedded apimgt components. And If ManageAPIs enabled and if it has been provided Store, Publisher, Gateway, KeyManager urls, then request will be redirect to the external api manager. Always, request will be first hit at the tomcat valve that we have added, logic will be reside in this valve , how api management is handling, whether inbuilt, external or without api management. Regards, Dinusha. What has to be done to complete it ? Because the Greg has a strict dead line to finish off by next week ? Thanks! Ragu On Mon, Jun 10, 2013 at 6:31 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Sanjeewa..! We are having a strategic discussion that how to include the API publisher/ store jag apps to other products. Therefore, I will update this thread after the discussion...! As far as I understand, there will be single interceptor which decides the processing path according to the manageAPIs property value. Thanks! Ragu On Mon, Jun 10, 2013 at 6:03 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Lakmali..! Yes, the above link does not work...! I moved the user token generation menu under the Resources menu in order to appear for Greg. Therefore the existing doc won't work. Also these changes have not yet been committed. I will give you , the locally built latest Greg 4.6.0 pack which has every thing. You can also try out some samples. When you get the access token via that option , that access token will be based on Client_Credentials grant type. Since the API store jag app will be there anyway to incorporate the light weight APIM component. Therefore the users are required to generate the access token via store when the manage APIs property set to true. Therefore I have to update the doc for generating the access token for either manageApis property set to true or false. I will update the Doc as quickly as possible. Thanks! Ragu On Mon, Jun 10, 2013 at 4:45 PM, Sanjeewa Malalgoda sanje...@wso2.comwrote: On Mon, Jun 10, 2013 at 4:08 PM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi All, This is what we are going to add from the APIM side. 1) We will be exposing current api manager handlers related functionalities as some common packages. So this bundle can be included into any of products to get API Management without using external API Manager. (i.e APIAuthenticationHandler, APIThrottleHandler and APIMgtUsageHandler) 2) There will be a new parameter added to carbon.xml to check whether APIManagement is enable or not. ManageAPIstrue/falseManageAPIs 3) There will be a interceptor which hit first and invoke the API Management functionalities when the above parameter is set
Re: [Dev] [Architecture] Current Status of The Registry REST API and Issues I face when Integrate with APIM
On Tue, Jun 18, 2013 at 12:59 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Dinusha, At the later part of your answer, you mentioned the how to send the request. Do we have a use case where without API manager. AFAIR, It has been clearly said during the final discussion , request will be given inbuilt or external APIM. But you mention about without APIM. But, when it comes to services like DSS, AS etc, we need to have this capability. Services, should be able to invoke with api management or without api management. yes, for the GRreg (in built apis), manageAPIs will be always true. Regards, Dinusha. Thanks! Ragu On Tue, Jun 18, 2013 at 12:31 PM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi Ragu, We have wrote a Tomcat Valve which will be act as interceptor for all incoming requests. There was a need of using Axis2ConfigurationContextObserver to get the throttling related properties, which cannot be done through the CXF hander in GREG REST API. This tomcat valve can be used not only by the GReg, also from any other product like AS, DSS when it comes to manage APIs. Also we have been working on, getting publisher and store jaggery apps into Greg. It was not straight forward because just putting these apps into GReg wont work. We had do some code changes in apimgt side to avoid synapse dependencies. As an example, api-store and publisher need to have apimgt-impl component been activated and while this module getting activated we are creating the tenant artifacts by coping synapse.xml files into synapse deployment directories of tenants. We had to customize apimgt code that it can identify the where api management is doing and avoid these synapse related tasks. On Tue, Jun 18, 2013 at 9:43 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Dinusha and Lakmali, Please update this mail thread that what have you done so far regarding the Lightweight API manager component. 1) Please let me know the strategy that you are using when integrate the external API manager instance. 2) when an API manager instance externally running, Do we need to call the API published at the API gateway? or Does the user call the Registry REST API and re-directing the URL to API gateway URL? 3) If it is a lightweight APIM component which resides within G-Reg, Will the request be given to Registry REST API ? Answering to the Q 1, 2, 3: Always user request will be to the G-Reg API. If the ManageAPIs is enabled then API Management will be handle through the embedded apimgt components. And If ManageAPIs enabled and if it has been provided Store, Publisher, Gateway, KeyManager urls, then request will be redirect to the external api manager. Always, request will be first hit at the tomcat valve that we have added, logic will be reside in this valve , how api management is handling, whether inbuilt, external or without api management. Regards, Dinusha. What has to be done to complete it ? Because the Greg has a strict dead line to finish off by next week ? Thanks! Ragu On Mon, Jun 10, 2013 at 6:31 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Sanjeewa..! We are having a strategic discussion that how to include the API publisher/ store jag apps to other products. Therefore, I will update this thread after the discussion...! As far as I understand, there will be single interceptor which decides the processing path according to the manageAPIs property value. Thanks! Ragu On Mon, Jun 10, 2013 at 6:03 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Lakmali..! Yes, the above link does not work...! I moved the user token generation menu under the Resources menu in order to appear for Greg. Therefore the existing doc won't work. Also these changes have not yet been committed. I will give you , the locally built latest Greg 4.6.0 pack which has every thing. You can also try out some samples. When you get the access token via that option , that access token will be based on Client_Credentials grant type. Since the API store jag app will be there anyway to incorporate the light weight APIM component. Therefore the users are required to generate the access token via store when the manage APIs property set to true. Therefore I have to update the doc for generating the access token for either manageApis property set to true or false. I will update the Doc as quickly as possible. Thanks! Ragu On Mon, Jun 10, 2013 at 4:45 PM, Sanjeewa Malalgoda sanje...@wso2.com wrote: On Mon, Jun 10, 2013 at 4:08 PM, Dinusha Senanayaka dinu...@wso2.com wrote: Hi All, This is what we are going to add from the APIM side. 1) We will be exposing current api manager handlers related functionalities as some common packages. So this bundle can be included into any of products to get API Management without using external API
Re: [Dev] [Architecture] Current Status of The Registry REST API and Issues I face when Integrate with APIM
Hai Dinusha and Lakmali, Please update this mail thread that what have you done so far regarding the Lightweight API manager component. 1) Please let me know the strategy that you are using when integrate the external API manager instance. 2) when an API manager instance externally running, Do we need to call the API published at the API gateway? or Does the user call the Registry REST API and re-directing the URL to API gateway URL? 3) If it is a lightweight APIM component which resides within G-Reg, Will the request be given to Registry REST API ? What has to be done to complete it ? Because the Greg has a strict dead line to finish off by next week ? Thanks! Ragu On Mon, Jun 10, 2013 at 6:31 PM, Sriragu Arudsothy srir...@wso2.com wrote: Hai Sanjeewa..! We are having a strategic discussion that how to include the API publisher/ store jag apps to other products. Therefore, I will update this thread after the discussion...! As far as I understand, there will be single interceptor which decides the processing path according to the manageAPIs property value. Thanks! Ragu On Mon, Jun 10, 2013 at 6:03 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Lakmali..! Yes, the above link does not work...! I moved the user token generation menu under the Resources menu in order to appear for Greg. Therefore the existing doc won't work. Also these changes have not yet been committed. I will give you , the locally built latest Greg 4.6.0 pack which has every thing. You can also try out some samples. When you get the access token via that option , that access token will be based on Client_Credentials grant type. Since the API store jag app will be there anyway to incorporate the light weight APIM component. Therefore the users are required to generate the access token via store when the manage APIs property set to true. Therefore I have to update the doc for generating the access token for either manageApis property set to true or false. I will update the Doc as quickly as possible. Thanks! Ragu On Mon, Jun 10, 2013 at 4:45 PM, Sanjeewa Malalgoda sanje...@wso2.comwrote: On Mon, Jun 10, 2013 at 4:08 PM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi All, This is what we are going to add from the APIM side. 1) We will be exposing current api manager handlers related functionalities as some common packages. So this bundle can be included into any of products to get API Management without using external API Manager. (i.e APIAuthenticationHandler, APIThrottleHandler and APIMgtUsageHandler) 2) There will be a new parameter added to carbon.xml to check whether APIManagement is enable or not. ManageAPIstrue/falseManageAPIs 3) There will be a interceptor which hit first and invoke the API Management functionalities when the above parameter is set to true. Depending on the service type, aixs2 or registry api etc, this interceptor may vary. When this comes to registry, we can call this api-management functionalities that we are going to expose through new package from the JAXWS web app that Ragu has created to expose the registry api. Since generic store feature is not going to release with the up coming registry release, we may need to include APIM Store jaggery app as well in to GReg. Just to clarify. With this model where we can create APIs, subscriptions and generate tokens? Do we provide some UI capability for this? Do we have single interceptor which handles all requests? Thanks, Sanjeewa. Regards, Dinusha. On Mon, Jun 10, 2013 at 11:41 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Lalaji, Dinusha..! We have had a discussion about the Light weight APIM component for other wso2 products as well as How to fit that to the Registry REST API. According to the last discussion with Lalaji, Dinusha and Lakmali We derived some points which I would like to mention..! Still there is some ambiguity at the APIM side. 1) The current implemetation of the registry REST API requires the APIM has to be running as a separate instance while having a configuration file (.xml) has the API manager url endpoints in it. The above config file was located at the Greg_Home/repository/conf. 2) The light weight API manager component will reside at the Greg. The flow of request goes as below, Rest Client request- Request filter/Some filter mechanism --light weight APIM -- Registry REST API Response back to Client. The above path will be executed if the APIM enabled property set to true at the config file...! Otherwise it request filter assumes that the request should be processed without APIM. Request filter executes the OAuth validation logic at the Greg REST API and proceeds to resource . Therefore the Request filter will be functioning as a centralized routing element decides whether the
Re: [Dev] [Architecture] Current Status of The Registry REST API and Issues I face when Integrate with APIM
On Mon, Jun 10, 2013 at 4:08 PM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi All, This is what we are going to add from the APIM side. 1) We will be exposing current api manager handlers related functionalities as some common packages. So this bundle can be included into any of products to get API Management without using external API Manager. (i.e APIAuthenticationHandler, APIThrottleHandler and APIMgtUsageHandler) 2) There will be a new parameter added to carbon.xml to check whether APIManagement is enable or not. ManageAPIstrue/falseManageAPIs 3) There will be a interceptor which hit first and invoke the API Management functionalities when the above parameter is set to true. Depending on the service type, aixs2 or registry api etc, this interceptor may vary. When this comes to registry, we can call this api-management functionalities that we are going to expose through new package from the JAXWS web app that Ragu has created to expose the registry api. Since generic store feature is not going to release with the up coming registry release, we may need to include APIM Store jaggery app as well in to GReg. Just to clarify. With this model where we can create APIs, subscriptions and generate tokens? Do we provide some UI capability for this? Do we have single interceptor which handles all requests? Thanks, Sanjeewa. Regards, Dinusha. On Mon, Jun 10, 2013 at 11:41 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Lalaji, Dinusha..! We have had a discussion about the Light weight APIM component for other wso2 products as well as How to fit that to the Registry REST API. According to the last discussion with Lalaji, Dinusha and Lakmali We derived some points which I would like to mention..! Still there is some ambiguity at the APIM side. 1) The current implemetation of the registry REST API requires the APIM has to be running as a separate instance while having a configuration file (.xml) has the API manager url endpoints in it. The above config file was located at the Greg_Home/repository/conf. 2) The light weight API manager component will reside at the Greg. The flow of request goes as below, Rest Client request- Request filter/Some filter mechanism --light weight APIM -- Registry REST API Response back to Client. The above path will be executed if the APIM enabled property set to true at the config file...! Otherwise it request filter assumes that the request should be processed without APIM. Request filter executes the OAuth validation logic at the Greg REST API and proceeds to resource . Therefore the Request filter will be functioning as a centralized routing element decides whether the request to be processed via light weight APIM comp or alone at the Greg REST API. @Lalaji and Dinusha please add anything if I miss anything. Thanks! Ragu On Thu, Jun 6, 2013 at 12:01 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai All, First of all, I will explain the architecture of the REST API implementation. The Registry REST API has two mode of functionality. 1) Standalone mode - Straight access to Registry REST API. This has been done and working fine. In this case Registry provide a way to generate the OAuth Access token for users to access the resources. Therefore the REST calls can be made from any REST client with an access token to access the resources. 2) With API Manager Mode - This means the access to Registry REST API with the Externally running API manager instance. In here, the admin or any responsible person will publish the REST API via API publisher. Therefore the REST API would be available for subscriber / endusers. Once the access token has been generated, user will be able to access the Registry Resources. In this mode, There are 2 ways in which I have implemented the REST API invocation process. This is explained as below. 1 REST client API gateway(REST API published at the APIM) Registry REST API Registry Resource Response go to REST client. The above implementation works fine. 2 REST Client - Registry REST API Call the REST endpoint at the APIM return call from APIM to Registry REST API Registry Resource Response back to REST client. The above approach, I have the an issue to pass the payload from Registry REST API to APIM. I have designed the REST API in CXF/ JAx-Rs. The apache CXF Jax-Rs implementation provide a Request Handler which is an interceptor for the incoming requests. Therefore any request made from REST client to Registry REST API will hit the Request Handler First. Therefore, when the request go to the handler, it will check whether the request comes from APIM or Straight from the Client. If it comes from the client it will call the REST API endpoint at the APIM via an apache HttpClient. Therefore when I call it, I have to extract the access token,
Re: [Dev] [Architecture] Current Status of The Registry REST API and Issues I face when Integrate with APIM
Hai Sanjeewa..! We are having a strategic discussion that how to include the API publisher/ store jag apps to other products. Therefore, I will update this thread after the discussion...! As far as I understand, there will be single interceptor which decides the processing path according to the manageAPIs property value. Thanks! Ragu On Mon, Jun 10, 2013 at 6:03 PM, Sriragu Arudsothy srir...@wso2.com wrote: Hai Lakmali..! Yes, the above link does not work...! I moved the user token generation menu under the Resources menu in order to appear for Greg. Therefore the existing doc won't work. Also these changes have not yet been committed. I will give you , the locally built latest Greg 4.6.0 pack which has every thing. You can also try out some samples. When you get the access token via that option , that access token will be based on Client_Credentials grant type. Since the API store jag app will be there anyway to incorporate the light weight APIM component. Therefore the users are required to generate the access token via store when the manage APIs property set to true. Therefore I have to update the doc for generating the access token for either manageApis property set to true or false. I will update the Doc as quickly as possible. Thanks! Ragu On Mon, Jun 10, 2013 at 4:45 PM, Sanjeewa Malalgoda sanje...@wso2.comwrote: On Mon, Jun 10, 2013 at 4:08 PM, Dinusha Senanayaka dinu...@wso2.comwrote: Hi All, This is what we are going to add from the APIM side. 1) We will be exposing current api manager handlers related functionalities as some common packages. So this bundle can be included into any of products to get API Management without using external API Manager. (i.e APIAuthenticationHandler, APIThrottleHandler and APIMgtUsageHandler) 2) There will be a new parameter added to carbon.xml to check whether APIManagement is enable or not. ManageAPIstrue/falseManageAPIs 3) There will be a interceptor which hit first and invoke the API Management functionalities when the above parameter is set to true. Depending on the service type, aixs2 or registry api etc, this interceptor may vary. When this comes to registry, we can call this api-management functionalities that we are going to expose through new package from the JAXWS web app that Ragu has created to expose the registry api. Since generic store feature is not going to release with the up coming registry release, we may need to include APIM Store jaggery app as well in to GReg. Just to clarify. With this model where we can create APIs, subscriptions and generate tokens? Do we provide some UI capability for this? Do we have single interceptor which handles all requests? Thanks, Sanjeewa. Regards, Dinusha. On Mon, Jun 10, 2013 at 11:41 AM, Sriragu Arudsothy srir...@wso2.comwrote: Hai Lalaji, Dinusha..! We have had a discussion about the Light weight APIM component for other wso2 products as well as How to fit that to the Registry REST API. According to the last discussion with Lalaji, Dinusha and Lakmali We derived some points which I would like to mention..! Still there is some ambiguity at the APIM side. 1) The current implemetation of the registry REST API requires the APIM has to be running as a separate instance while having a configuration file (.xml) has the API manager url endpoints in it. The above config file was located at the Greg_Home/repository/conf. 2) The light weight API manager component will reside at the Greg. The flow of request goes as below, Rest Client request- Request filter/Some filter mechanism --light weight APIM -- Registry REST API Response back to Client. The above path will be executed if the APIM enabled property set to true at the config file...! Otherwise it request filter assumes that the request should be processed without APIM. Request filter executes the OAuth validation logic at the Greg REST API and proceeds to resource . Therefore the Request filter will be functioning as a centralized routing element decides whether the request to be processed via light weight APIM comp or alone at the Greg REST API. @Lalaji and Dinusha please add anything if I miss anything. Thanks! Ragu On Thu, Jun 6, 2013 at 12:01 PM, Sriragu Arudsothy srir...@wso2.comwrote: Hai All, First of all, I will explain the architecture of the REST API implementation. The Registry REST API has two mode of functionality. 1) Standalone mode - Straight access to Registry REST API. This has been done and working fine. In this case Registry provide a way to generate the OAuth Access token for users to access the resources. Therefore the REST calls can be made from any REST client with an access token to access the resources. 2) With API Manager Mode - This means the access to Registry REST API with the Externally running API
