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/>
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
