Hi Dinusha,
Good progress. I will use the in-built APIM to test the
Registry REST API.
1) Version support can be added. I will do that.
2) Since we wanted to create the users with user name and tenant id to
separate registry space belongs to the user based on the tenant and
username.
Could you tell me what do you mean by "external users" ? How can an
external user access the Registry REST API ? I am bit unclear about the
terminology .
Even if the APIM running externally or in-built APIM component, users will
be generating access token via API store jaggery app anyway. Therefore
user should have an account in the platform.
Do we allow external users to access the Registry resources ?
Thanks!
On Thu, Jun 20, 2013 at 11:20 AM, Dinusha Senanayaka <dinu...@wso2.com>wrote:
> Hi Ragu,
>
> On Thu, Jun 20, 2013 at 10:52 AM, Sriragu Arudsothy <srir...@wso2.com>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 <dinu...@wso2.com>wrote:
>>
>>>
>>>
>>> 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 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 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.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
>>>>>>>>>> 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 <
>>>>>>>>>> srir...@wso2.com> 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 <
>>>>>>>>>>> srir...@wso2.com> 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
>>>>>>>>>> architect...@wso2.org
>>>>>>>>>> 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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
