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 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. 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
