Our current approach is as srinath mentioned . 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.
Thanks On 14 May 2013 23:59, Vijayaratha Vijayasingam <[email protected]> wrote: > Hi all; > Im not clear on what you are trying to do really. > @ senaka; > 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. > > I agree, but we can use our jaggery webapps to publish any apis from any > component. That is how we decided sometime back and we did like taht in > Registry. Waht we need to do is, simple POST to our jaggery app, with the > details, other subscription/validation process will be automatically > handled by APIM itself. > > 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. > > Again why do you need to have AM features in RESTAPI? > If we can publish a service as API using RESTAPI (to the jaggery > endpoint), that would be great. (we can remove our current executor, which > does same) > > @ragu; > > 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 > > Invoking the RESTAPI via the published API?, if we published the API > , then why do we need RESTAPi additionally there? > > @ sumedha; > > 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. > > Why do we again need to pack APIM functionality in GREG? > Can't we simply post the API to our publisher webapp? > > Thanks > -Ratha > > > > On 14 May 2013 13:04, Sumedha Rubasinghe <[email protected]> wrote: > >> You question was not 100% clear. >> >> API Manager's APIs are secured using basic auth now. Just establish a >> session & invoke the operations you need to publish the APIs. That should >> be the way to proceed. >> >> >> On Tue, May 14, 2013 at 12:03 PM, Sriragu Arudsothy <[email protected]>wrote: >> >>> Hai Sumedha....! >>> >>> I have a question, >>> >>> 1) the user having API publisher role or above will be able to publish >>> the API. Therefore Shall I have an another API in the Registry REST >>> endpoint to login to the API publisher and add the API to the API >>> publisher. It means that the particular method in the Registry REST API >>> calls the API publisher's login API with the credentials. Once the login is >>> success then send an another call to add an api to the REST API endpoint >>> which will call the API Publisher's API to add that API and change the >>> state to published. these two calls can be bound together. If we allow the >>> users to send the tier and tiercollection parameters with the request when >>> add the API would be better I think, >>> >>> What Would you think? >>> >>> Thanks! >>> Ragu >>> >>> >>> >>> >>> >>> >>> On Mon, May 13, 2013 at 11:03 PM, Vijayaratha Vijayasingam < >>> [email protected]> wrote: >>> >>>> Publishing APIs from GREG is already implemented..We just do a >>>> POSTing,..? >>>> >>>> >>>> On 13 May 2013 22:20, Supun Malinga <[email protected]> wrote: >>>> >>>>> 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 >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >> >> >> -- >> /sumedha >> m: +94 773017743 >> b : bit.ly/sumedha >> >> _______________________________________________ >> 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
