Hi Vijitha, On Sun, Jul 14, 2013 at 11:13 AM, Vijitha Kumara <[email protected]> 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 <[email protected]>wrote: > >> Hi Ragu, >> >> On Thu, Jun 20, 2013 at 10:52 AM, Sriragu Arudsothy <[email protected]>wrote: >> >>> 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=admin&tenantid=-1234 * >> >> Regards, >> Dinusha. >> >>> >>> Thanks, >>> Ragu >>> >>> >>> >>> On Tue, Jun 18, 2013 at 1:20 PM, Dinusha Senanayaka <[email protected]>wrote: >>> >>>> >>>> >>>> On Tue, Jun 18, 2013 at 12:59 PM, Sriragu Arudsothy >>>> <[email protected]>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 <[email protected] >>>>> > 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 >>>>>> <[email protected]>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, 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 <[email protected] >>>>>>> > 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 < >>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Jun 10, 2013 at 4:08 PM, Dinusha Senanayaka < >>>>>>>>>> [email protected]> 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 >>>>>>>>>>> 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. >>>>>>>>>>> <ManageAPIs>true/false<ManageAPIs> >>>>>>>>>>> >>>>>>>>>>> 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 < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> 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 < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> 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, queryParam, payload..etc from REST client's request and >>>>>>>>>>>>> add it to >>>>>>>>>>>>> the request given to APIM. But I am able to extract the access >>>>>>>>>>>>> token, >>>>>>>>>>>>> queryparam and add it to HttpMethod and call the APIM. Request >>>>>>>>>>>>> Handler >>>>>>>>>>>>> seems that does not have a way to extract the payload ( POST/PUT). >>>>>>>>>>>>> Therefore unable to pass the payload to the REGISTRY REST API. >>>>>>>>>>>>> That is why >>>>>>>>>>>>> GET and DELETE requests are working fine in the second approach >>>>>>>>>>>>> since those >>>>>>>>>>>>> do not require the payload. BUT POST/PUT requests fail to proceed. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Therefore The CXF JAX-RS Request Handler has both the >>>>>>>>>>>>> Standalone Mode and APIM mode execution. Therefore the standalone >>>>>>>>>>>>> mode is >>>>>>>>>>>>> working fine. But Which approach to be selected regarding the >>>>>>>>>>>>> APIM mode to >>>>>>>>>>>>> put it in the request handler class. Since there is an issue in >>>>>>>>>>>>> Approach 2 >>>>>>>>>>>>> @ APIM mode, It went to approach 1. According to the approach 1 >>>>>>>>>>>>> the code >>>>>>>>>>>>> will be cleaner than approach 2. >>>>>>>>>>>>> >>>>>>>>>>>>> *According to Approach 1 @APIM mode the example Request URL >>>>>>>>>>>>> will be,* >>>>>>>>>>>>> >>>>>>>>>>>>> http://{ipaddress}:8280/{REST API context >>>>>>>>>>>>> @APIM}/{version}/comments?path=/sample.xml. >>>>>>>>>>>>> >>>>>>>>>>>>> *in Standalone mode: >>>>>>>>>>>>> * >>>>>>>>>>>>> http:{IP address}:{greg http port}/{rest api context @ >>>>>>>>>>>>> greg}/comments?path=/sample.xml. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The APIM team already given their words to derive an integrate >>>>>>>>>>>>> able APIM solution for other WSO2 products. Meanwhile we heard >>>>>>>>>>>>> that APIM >>>>>>>>>>>>> team working on that too. >>>>>>>>>>>>> >>>>>>>>>>>>> Few days ago, Had a chat with APIM guys, They said that API >>>>>>>>>>>>> publisher and API store will be there as it is. Therefore whoever >>>>>>>>>>>>> wants to >>>>>>>>>>>>> publish an API have login to the API publisher and publish an >>>>>>>>>>>>> API. This can >>>>>>>>>>>>> not be done automatically during the server starts up. >>>>>>>>>>>>> >>>>>>>>>>>>> This is all about the integration part of REST API with API >>>>>>>>>>>>> Manager. @APIM please let us know the current stage of your >>>>>>>>>>>>> solution. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> Ragu >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Dinusha Dilrukshi >>>>>>>>>>> Senior Software Engineer >>>>>>>>>>> WSO2 Inc.: http://wso2.com/ >>>>>>>>>>> Mobile: +94725255071 >>>>>>>>>>> Blog: http://dinushasblog.blogspot.com/ >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> * >>>>>>>>>> * >>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>> WSO2 Inc. >>>>>>>>>> Mobile : +94713068779 >>>>>>>>>> >>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dinusha Dilrukshi >>>>>> Senior Software Engineer >>>>>> WSO2 Inc.: http://wso2.com/ >>>>>> Mobile: +94725255071 >>>>>> Blog: http://dinushasblog.blogspot.com/ >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dinusha Dilrukshi >>>> Senior Software Engineer >>>> WSO2 Inc.: http://wso2.com/ >>>> Mobile: +94725255071 >>>> Blog: http://dinushasblog.blogspot.com/ >>>> >>> >>> >> >> >> -- >> Dinusha Dilrukshi >> Senior Software Engineer >> WSO2 Inc.: http://wso2.com/ >> Mobile: +94725255071 >> Blog: http://dinushasblog.blogspot.com/ >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Vijitha Kumara > Senior Software Engineer; WSO2, Inc.; http://wso2.com/ > email: [email protected] > > > Lean . Enterprise . Middleware > -- Dinusha Dilrukshi Senior Software Engineer WSO2 Inc.: http://wso2.com/ Mobile: +94725255071 Blog: http://dinushasblog.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
