Hai Sumedha....!
I have designed the subscriber as you mentioned
above...! During the subscribing process, As what you said I can treat the
instance of GREG as a subscriber. Therefore all the subscribers from that
instance will be considered as a same. During the Token generation, I am
giving a REST call to the Login API. Therefore How can I get to know the
consumer key, secret generated for that GREG instance? Bz I have to send
the base64 encoded (key:secret) with the REST call.
Thanks!
Ragu
On Wed, May 15, 2013 at 2:59 AM, Sumedha Rubasinghe <[email protected]>wrote:
> 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
>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
