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 <[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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
