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