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/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
