On Tue, May 14, 2013 at 11:59 PM, Vijayaratha Vijayasingam <[email protected]>wrote:
> > @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? > Later I explained to Ragu that this is not needed. I think this requirement is no longer valid. > > @ 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? > This is only one suggestion if we want to come up with a single pack that has everything working. But most don't seem to be preferring this due to sizing implications. > > 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 > > -- /sumedha m: +94 773017743 b : bit.ly/sumedha
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
