Hi,

On Mon, Sep 23, 2013 at 4:21 PM, Paul Fremantle <[email protected]> wrote:

> That is really circular logic: APIM requires exactly one subscriber. We
> have one app owner, so we decided to make that the subscriber. Now, because
> there can only be one subscriber we can't make more that one app owner.
>
> There are two simple solutions to this:
>
> 1) Create a new role (API Subscriber) and make that only assignable to one
> person
>

Since option-2 is not not in APIM roadmap we have to do the first one. We
can introduce API Subscriber role, but application roles are not for the
wso2con time-line. So to workaround to the problem is, we can use the
appowner and then use the API-Subscriber role when we have application
roles. WDYT?



> 2) Fix API Manager so that it can support group subscribers.
>
>
This is not in the road map yet.

thanks,
dimuthu


> I don't think making a single app owner because of this is the right
> answer.
>
> Paul
>
>
> On 23 September 2013 11:22, Punnadi Gunarathna <[email protected]> wrote:
>
>> Hi Paul,
>>
>> We have had a discussion mail earlier (i.e subject "Issue in App
>> subscription and Key generation with API Manager in AppFactory") on
>> Architecture group and I have mentioned the reason there in more details.
>>
>> In summary there is a limitation in APIM where there is no such a concept
>> as "Group Subscription". Therefore in App Factory, if there is a
>> application and number of members in the team (App Owner, Developers etc)
>> only one person can login to APIM and subscribe to APIs.
>>
>> So if there are several developers we will have to identify one person
>> from them.
>> Instead since we have 1 App Owner per application we have decided to give
>> subscription/key generation rights to App Owner.
>>
>>
>> On Mon, Sep 23, 2013 at 3:19 PM, Paul Fremantle <[email protected]> wrote:
>>
>>> I don't see why the App Owner is the person to generate the keys anyway.
>>> Normally it would be one of the devs.
>>>
>>> This looks like something where we need to define exactly what behaviour
>>> we would like to see is, and then implement that in APIM.
>>>
>>> For example, if I generate keys for an app, who else in the team should
>>> see them? I actually don't know the answer to that question. I think we
>>> need to figure that out first.
>>>
>>> Paul
>>>
>>>
>>> On 23 September 2013 10:44, Punnadi Gunarathna <[email protected]> wrote:
>>>
>>>>
>>>> Hi All,
>>>>
>>>> Myself and Dimuthu had a offline chat regarding $subject and please
>>>> find more details on why that cannot be done.
>>>>
>>>> -If we allow to have multiple App Owners per application then there
>>>> will be an issue with APIM. That is;
>>>>
>>>> "AppOwner1" creates an Application called "App1" in App Factory. Then
>>>> he invites
>>>> few more people as App Owners say AppOwner2 and AppOwner3.
>>>> AppOwner1 login to API Manger and subscribe App1 with "API1" and
>>>> generate key pairs.
>>>>
>>>> Based on the current APIM implementation, any other App Owner who will
>>>> login to APIM will not be able to see the previous subscriptions or already
>>>> generated keys. Furthermore they can subscribe the same application
>>>> individually again with the API1 and generate new keys.
>>>>
>>>> This is why we thought of not having multiple App Owners per
>>>> application.
>>>>
>>>> So then comes the question if the AppOwner1 leaves the company, then
>>>> how can we manage the App1 as well as its subscribed APIs?
>>>>
>>>> In such a situation we thought to provide scripts to update both App
>>>> Factory and APIM databases in such a way that the old App Owner will be
>>>> updated with the new App Owner details.
>>>>
>>>> Please let us know your thought on this.
>>>>
>>>> --
>>>> Thanks and Regards,
>>>>
>>>> Punnadi Gunarathna
>>>> Senior Software Engineer,
>>>> WSO2, Inc.; http://wso2.com <http://wso2>
>>>> Blog: http://hi-my-world.blogspot.com/
>>>> Tel : 94 11 214 5345
>>>> Fax :94 11 2145300
>>>>
>>>>
>>>>
>>>>  <http://lalajisureshika.blogspot.com/>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Paul Fremantle
>>> CTO and Co-Founder, WSO2
>>> OASIS WS-RX TC Co-chair, Apache Member
>>>
>>> UK: +44 207 096 0336
>>> US: +1 646 595 7614
>>>
>>> blog: http://pzf.fremantle.org
>>> twitter.com/pzfreo
>>> [email protected]
>>>
>>> wso2.com Lean Enterprise Middleware
>>>
>>> Disclaimer: This communication may contain privileged or other
>>> confidential information and is intended exclusively for the addressee/s.
>>> If you are not the intended recipient/s, or believe that you may have
>>> received this communication in error, please reply to the sender indicating
>>> that fact and delete the copy you received and in addition, you should not
>>> print, copy, retransmit, disseminate, or otherwise use the information
>>> contained in this communication. Internet communications cannot be
>>> guaranteed to be timely, secure, error or virus-free. The sender does not
>>> accept liability for any errors or omissions.
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Thanks and Regards,
>>
>> Punnadi Gunarathna
>> Senior Software Engineer,
>> WSO2, Inc.; http://wso2.com <http://wso2>
>> Blog: http://hi-my-world.blogspot.com/
>> Tel : 94 11 214 5345
>> Fax :94 11 2145300
>>
>>
>>
>>  <http://lalajisureshika.blogspot.com/>
>>
>
>
>
> --
> Paul Fremantle
> CTO and Co-Founder, WSO2
> OASIS WS-RX TC Co-chair, Apache Member
>
> UK: +44 207 096 0336
> US: +1 646 595 7614
>
> blog: http://pzf.fremantle.org
> twitter.com/pzfreo
> [email protected]
>
> wso2.com Lean Enterprise Middleware
>
> Disclaimer: This communication may contain privileged or other
> confidential information and is intended exclusively for the addressee/s.
> If you are not the intended recipient/s, or believe that you may have
> received this communication in error, please reply to the sender indicating
> that fact and delete the copy you received and in addition, you should not
> print, copy, retransmit, disseminate, or otherwise use the information
> contained in this communication. Internet communications cannot be
> guaranteed to be timely, secure, error or virus-free. The sender does not
> accept liability for any errors or omissions.
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Dimuthu Leelarathne
Architect & Product Lead of App Factory

WSO2, Inc. (http://wso2.com)
email: [email protected]
Mobile : 0773661935

Lean . Enterprise . Middleware
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to