Hi, Few questions to clarify..
On Mon, May 13, 2013 at 12:25 PM, Sumedha Rubasinghe <[email protected]>wrote: > I think the confusion here is due to not treating following three aspects > separately. > - Runtime API access (via gateway, key management & stat publishers) > - API Publish process (involves publisher) > - Subscription process (involves store & key issuing functionality) > > Here is what I feel what need to happen. > > Preconditions: > 1. G-Reg already has a REST endpoint > > > API publish process involves following: > 1. creating API configuration programmatically & deploying it > 2. writing API definition to API Manager's governance registry > 3. Writing a record of the API into API Manager database > > API subscription process involves following: > 1. Subscriber (carbon user) signing in > 2. writing application record to API Manager database > 3. writing subscription record to API Manager database > 4. writing generated keys to Identity database > > Gateway: > 1. Validate the access token against Identity database > 2. publish stats, throttle, etc > > > If we are to have complete API management (all three aspects) happening > with a single G-Reg node, I don't see any other option than packing > everything together. > > But what I feel most practical is, outsourcing everything related to API > Management to an externally deployed API Manager instance & integrate via > AM's APIs for publish, subscribe & token validation. > > In this approach: > For Gateway: > G-Reg only need to have a servlet filter listening to requests going to > it's REST API context. This filter should do token validation against > external AM APIs > For gateway why can't we simply ask users to talk to the api published in the AM? > > For Publishing: > During first server start up, access AM's publishing API & create an API > representing G-Reg's REST API > > For subscription: > If a G-Reg users want to access the API programmatically, provide generate > token button within G-Reg. Then call AM API & get an access token > generated. G-Reg's user account should be used as the subscriber account. > To make Application management simple, we can treat one G-Reg instance as > one application & have a consumer key & a secret generated against that > G-Reg instance. This combination will be used when that G-Reg instance > requests access tokens for it's registered users. > > There are some down sides of this approach (i.e. having one application > for G-Reg). But IMO that simplifies things to a great deal from G-Reg PoV. > Here how can we handle MTed scenario in greg..? Will the rest api same for all tenants?. > > Please invite me for any further meetings happening on this. > > > > > > > > > > On Mon, May 13, 2013 at 11:09 AM, Srinath Perera <[email protected]> wrote: > >> Hi All, >> >> I am still not sure what we try to do. Couple of questions. >> >> Cannot we just support externally running API manager and let user >> publish registry APIs to that API manager. In which case, we do not need to >> bundle the API manager with Greg. >> >> What would intercepting code do? If that only collect stats, then BAM >> handler should do the trick. >> >> --Srinath >> >> >> On Sun, May 12, 2013 at 1:37 PM, Nuwan Bandara <[email protected]> wrote: >> >>> Hi Senaka >>> >>> >>> On Sun, May 12, 2013 at 12:55 PM, Senaka Fernando <[email protected]>wrote: >>> >>>> Hi all, >>>> >>>> I think we are complicating the whole thing. Let me briefly explain >>>> what is required. For any API that will be exposed from any component, we >>>> need a concept of API Management. The AM product involves two major >>>> components. >>>> >>>> 1. The entire product (including store/publisher etc) required to >>>> do API Management. >>>> 2. A small interceptor/handler or something of that sort required >>>> to enable management of a single API (let me call this an agent). >>>> >>>> Right now, every single API needs to be managed through AM, because the >>>> concept of an agent is not defined and we don't have anything that we can >>>> deploy on Tomcat, Axis2, IIS etc. - but we need to. The idea here is to >>>> identify that minimal subset and create an agent that can be deployed in >>>> other products of our platform such that it can be interfaced with AM. >>>> >>>> Having said that, the Registry REST API is one of the APIs for which >>>> we'd like to have AM capabilities, so we wanted to get this done as a part >>>> of that. So, what we need is a lightweight agent and also the capability to >>>> do OAuth-based authentication, which is analogous to the embedded >>>> registry/user-management which ships with each product. >>>> >>>> >>> I completely agree with you Senaka. This agent is NOT bundling up API >>> manager to GREG. I think we talked about the subject during >>> few discussions that Apps/APIs need a way to publish stats and do >>> management so for this we need some handler (engaging) mechanism. so if >>> this doesn't exists right now we have to write one which can be reused in >>> similar situations. >>> >>> Regards, >>> /Nuwan >>> >>> >>>> Thanks, >>>> Senaka. >>>> >>>> >>>> On Sun, May 12, 2013 at 9:33 AM, Nuwan Bandara <[email protected]> wrote: >>>> >>>>> Hi Guys, >>>>> >>>>> Is this the correct way of doing it ? This essentially means, future >>>>> GREG releases will contain APIM features, which is the gateway, key >>>>> manager >>>>> and the jaggery apps. one of my concerns are, because of an API, GREG pack >>>>> will be considerably large and also having the a gateway, publisher apps >>>>> are not really relevant when you are simply exposing an API. >>>>> >>>>> IMO, if your requirement is to publish stats, you should use the >>>>> webapp BAM stats publisher (AS folks are working on this) and you can have >>>>> the key issuing and management components of IS. You can provide an API to >>>>> get new keys and renew, you dont need a publisher or store for this. >>>>> >>>>> Just because we have the API Manager doesn't mean we have to ship APIM >>>>> components with all the APIs we compose for our products. we need to have >>>>> a >>>>> light weight mechanism, where you can collect statistics, issue keys and >>>>> also document (maybe swagger based). >>>>> >>>>> Regards, >>>>> /Nuwan >>>>> >>>>> >>>>> On Sat, May 11, 2013 at 6:44 AM, Sriragu Arudsothy >>>>> <[email protected]>wrote: >>>>> >>>>>> Hai...! >>>>>> >>>>>> During the second architecture review we have been decided >>>>>> the following aspects to be added to the Registry REST API, >>>>>> >>>>>> 1) The API OAuth access token validation, >>>>>> 2) BAM stats monitoring, >>>>>> 3) Throttling policy to access the REST API. >>>>>> 4) published to dashboard. >>>>>> >>>>>> Therefore During the discussion, Since the APIM has all these >>>>>> features in it, We have been requested to use the minimal workable APIM >>>>>> inside the GREG rather than re-implementing those features for our needs. >>>>>> >>>>>> After the discussion, I approached the APIM team. According to their >>>>>> suggestion, they requested to run the APIM and Greg, invoke the registry >>>>>> REST API via the API published in the APIM. Therefore the call is being >>>>>> sent to the published api's (APIM side) endpoint which goes through the >>>>>> above handlers and validated, finally received at the REST API endpoint. >>>>>> >>>>>> Thanks! >>>>>> Ragu >>>>>> >>>>>> >>>>>> >>>>>> On Fri, May 10, 2013 at 7:12 PM, Supun Malinga <[email protected]>wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Sent from my phone >>>>>>> >>>>>>> On May 10, 2013 5:39 PM, "Sriragu Arudsothy" <[email protected]> >>>>>>> wrote: >>>>>>> > >>>>>>> > Hai...! >>>>>>> > >>>>>>> > >>>>>>> > The Registry REST API has been implemented as follows, >>>>>>> > >>>>>>> > 1) I am running an APIM instance with Greg. >>>>>>> > >>>>>>> > 2) Publish an API via API publisher and specifies the Registry >>>>>>> REST API endpoint as the Target endpoint url in the API publisher. >>>>>>> > >>>>>>> > 3) Subscriber Creates an Application which has the published API >>>>>>> via API store >>>>>>> > >>>>>>> > 4) end user who wants to use that application will generate the >>>>>>> access token for the application and access the Registry REST API >>>>>>> endpoint >>>>>>> via published API. >>>>>>> > >>>>>>> > Is there anyway that we can embed minimal APIM component that can >>>>>>> accomplish the needs? >>>>>>> >>>>>>> IMHO the easiest way is to embed the registry REST Api into AM. >>>>>>> >>>>>>> As per what you have mentioned I think you would need most of the >>>>>>> features of the AM. >>>>>>> >>>>>>> Anyways What you intend to achieve here is not clear. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> > >>>>>>> > Thanks...! >>>>>>> > Ragu >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > Architecture mailing list >>>>>>> > [email protected] >>>>>>> > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> > >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Thanks & Regards, >>>>> >>>>> Nuwan Bandara >>>>> Associate Technical Lead & Member, MC, Development Technologies >>>>> WSO2 Inc. - lean . enterprise . middleware | http://wso2.com >>>>> blog : http://nuwanbando.com; email: [email protected]; phone: +94 11 >>>>> 763 9629 >>>>> * >>>>> <http://www.nuwanbando.com/> >>>>> >>>> >>>> >>>> >>>> -- >>>> *Senaka Fernando* >>>> Member - Integration Technologies Management Committee; >>>> Technical Lead; WSO2 Inc.; http://wso2.com* >>>> Member; Apache Software Foundation; http://apache.org >>>> >>>> E-mail: senaka AT wso2.com >>>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 >>>> Linked-In: http://linkedin.com/in/senakafernando >>>> >>>> *Lean . Enterprise . Middleware >>>> >>> >>> >>> >>> -- >>> *Thanks & Regards, >>> >>> Nuwan Bandara >>> Associate Technical Lead & Member, MC, Development Technologies >>> WSO2 Inc. - lean . enterprise . middleware | http://wso2.com >>> blog : http://nuwanbando.com; email: [email protected]; phone: +94 11 763 >>> 9629 >>> * >>> <http://www.nuwanbando.com/> >>> >> >> >> >> -- >> ============================ >> Srinath Perera, Ph.D. >> http://www.cs.indiana.edu/~hperera/ >> http://srinathsview.blogspot.com/ >> > > > > -- > /sumedha > m: +94 773017743 > b : bit.ly/sumedha > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Supun Malinga, Software Engineer, WSO2 Inc. http://wso2.com http://wso2.org email - [email protected] <[email protected]> mobile - 071 56 91 321
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
