Hi Lakmali On Thu, Apr 20, 2017 at 11:51 PM, Lakmali Baminiwatta <[email protected]> wrote:
> On 20 April 2017 at 19:19, Joseph Fonseka <[email protected]> wrote: > >> >> @Jo > Even though the API is designed to work with client credential, it doesn't > mean only the subscribed users can invoke it, right? Any user that access > the subscribed app will be able to invoke that API. My argument is, the > pattern used in test app is possible in any other normal apps as well. I > understand that this can be confusing and might be not easy to convince for > some users. > Your argument assumes that an app is shared/available to all the users. It can be true for some scenarios like mobile apps but if you look at instances like B2B ( system to system ) API invocations app will not be available for all the users or for any user to start with. Regards Jo > > However, when proceeding with the implementation we found further problems > which we couldn't find clean enough solutions. > > - Getting the admin apps credentials to the front end for swagger can > be vulnerable. Even if we go for implicit grant type, we have to figure out > how to compose the callback URLs. > - We can do per user app creation with automatic on demand > subscriptions (may be with an explicit button as Jo mentioned). If so, only > thing we achieve here compared to C4 is doing an automatic > subscription/token generation for a default app. > > So for now, we'll be integrating API Console only for editor and Store. > Since API doesn't have security applied in Editor mode, we don't have to > worry about token generation. For Store, we will keep the same behavior as > in C4 for now. > > Thanks, > Lakmali > > >> Regards >> Jo >> >> >>> >>> Thanks, >>> Lakmali >>> >>> I guess to prevent that you have to use a per user or per API test app. >>>> >>>> Regards >>>> Jo >>>> >>>> On Thu, Apr 20, 2017 at 10:10 AM, Lakmali Baminiwatta <[email protected] >>>> > wrote: >>>> >>>>> Hi Jo, >>>>> >>>>> On 20 April 2017 at 09:01, Joseph Fonseka <[email protected]> wrote: >>>>> >>>>>> Hi Lakmali >>>>>> >>>>>> Small thing, will the portal app subscription be automatic in the >>>>>> store ? if so can we make it explicit with a button on top of the swagger >>>>>> console with the title "Try API with swagger console" and bellow that we >>>>>> can explain what actually happens. >>>>>> >>>>> >>>>> We are creating an app for the admin user here and therefore the >>>>> subscription happens for the admin user. Therefore IMO, that information >>>>> is >>>>> not required for the store user. >>>>> >>>>>> >>>>>> Also how will the test app affects stats ? If we are not planing to >>>>>> hide it better to document that behavior. >>>>>> >>>>> >>>>> The admin user will have this test app. I believe its okay for admin >>>>> to have this test app shown may be with a special flag. >>>>> >>>>> In overall, we can explain the underlying process here when we >>>>> document the options users will have around this. >>>>> >>>>> Thanks, >>>>> Lakmali >>>>> >>>>> >>>>>> Thanks >>>>>> Jo >>>>>> >>>>>> On Thu, Apr 20, 2017 at 8:17 AM, Lakmali Baminiwatta < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> We had a discussion regarding this yesterday and please find the >>>>>>> summarized points. >>>>>>> >>>>>>> >>>>>>> - "Testing APIs" is a required feature for Store and Editor >>>>>>> portals. Since we are not restricting API designing only to the >>>>>>> editor, but >>>>>>> allowed in publisher too, it is good to have "Testing APIs" feature >>>>>>> in >>>>>>> Publisher for a complete story. >>>>>>> - For editor, since the API is published to a local GW, it will >>>>>>> not have any security and therefore testing API will not require any >>>>>>> tokens/subscriptions etc. >>>>>>> - When the API is published from Publisher portal to the GW in >>>>>>> CREATED state for testing, we have to apply standard >>>>>>> security/throttling to >>>>>>> avoid security risks. >>>>>>> - As discussed in this thread as well, we will be using the >>>>>>> OAuth app created for the portals as the test app. However, for >>>>>>> supporting >>>>>>> prod and sandbox tokens, we have to register 2 apps. >>>>>>> - We can create the test apps when doing the DCR call. >>>>>>> - When retrieving the swagger definition of the API, we can >>>>>>> check the availability of subscriptions against the test apps and >>>>>>> add if >>>>>>> not available. >>>>>>> - Since swagger itself support OAuth, we can rely on it to >>>>>>> obtain a token. For that, we need to inject the test app's >>>>>>> credentials to >>>>>>> swagger UI and KM details needs to be injected to swagger definition. >>>>>>> - We can have a special throttling tier for API testing purpose. >>>>>>> - As the first step, we can implement this for Store and then >>>>>>> decide on adding it to Publisher. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Lakmali >>>>>>> >>>>>>> On 24 March 2017 at 19:08, Nuwan Dias <[email protected]> wrote: >>>>>>> >>>>>>>> Hi Jo, >>>>>>>> >>>>>>>> The publisher and store are anyway OAuth apps registered in the >>>>>>>> IDP. There are registered under the system/admin user. That is done >>>>>>>> irrespective of the testing usecase so that those apps can use the >>>>>>>> OAuth >>>>>>>> protected Rest APIs. >>>>>>>> >>>>>>>> Regarding stats, the stats against the API will show that there are >>>>>>>> requests being being from the publisher/store webapps. Which is what >>>>>>>> happens in reality. The stats against the application will only be >>>>>>>> visible >>>>>>>> to the system/admin user since the publisher/store webapps belong to >>>>>>>> him. >>>>>>>> So it doesn't confuse the end user (actual App Developer on the Store) >>>>>>>> like >>>>>>>> it does today. >>>>>>>> >>>>>>>> My thinking is that this testing of the API is mainly for the API >>>>>>>> Developers (not publishers) to test the API Implementation code >>>>>>>> (ballerina >>>>>>>> code) they write. Testing OAuth and throttling are just by-products of >>>>>>>> the >>>>>>>> main usecase. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> NuwanD. >>>>>>>> >>>>>>>> On Fri, Mar 24, 2017 at 4:40 PM, Joseph Fonseka <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Mar 24, 2017 at 10:20 AM, Nuwan Dias <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> @Jo, what's the downside of using the Publisher/Store webapp that >>>>>>>>>> you're trying to get rid of by explicitly creating a test app? >>>>>>>>>> What's the >>>>>>>>>> difference basically? >>>>>>>>>> >>>>>>>>> >>>>>>>>> The main issue I see is that automatic subscription of store and >>>>>>>>> publisher app. Once subscribed it will come up in IdP , Stats ( If we >>>>>>>>> capture ) which will confuse the end user. The second issue is that >>>>>>>>> majority of APIs will be just proxy-ed though GW and you wont be >>>>>>>>> testing >>>>>>>>> the BE functionality at this stage so what you would do is more of an >>>>>>>>> integration test with OAuth and throttling hence the user should be >>>>>>>>> able to >>>>>>>>> utilize all grant types and scopes. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Jo >>>>>>>>> >>>>>>>>> >>>>>>>>>> I see a few negatives in allowing to create test apps from the >>>>>>>>>> Publisher. >>>>>>>>>> >>>>>>>>>> 1. The UX is definitely not as good since the user now has to go >>>>>>>>>> through additional steps just to test his API. >>>>>>>>>> 2. There will be lots of test apps created in the system as >>>>>>>>>> opposed to the two webapps. >>>>>>>>>> 3. If by any chance the same user visits the Store, we have to >>>>>>>>>> find mechanisms to differentiate his test Apps from the Standard >>>>>>>>>> Apps so >>>>>>>>>> that the test Apps don't appear in Store. >>>>>>>>>> 4. If we open up an App creation functionality on the Publisher, >>>>>>>>>> chances are that users will misuse this for other purposes. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Mar 24, 2017 at 10:06 AM, Lakmali Baminiwatta < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> The objective of providing this feature is making the API >>>>>>>>>>> developers/publisher to test and verify before make it available >>>>>>>>>>> for the >>>>>>>>>>> consumers. So how about we provide the ability to deploy it to the >>>>>>>>>>> gateway >>>>>>>>>>> without security so that it can be invoked without a token? >>>>>>>>>>> Once the test is completed, they can set the security and >>>>>>>>>>> publish that to the store/gateway. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Lakmali >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 24 March 2017 at 09:34, Nuwan Dias <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 23, 2017 at 11:06 PM, Sanjeewa Malalgoda < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Mar 23, 2017 at 7:12 PM, Nuwan Dias <[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Mar 23, 2017 at 9:04 PM, Sanjeewa Malalgoda < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Mar 23, 2017 at 12:17 PM, Nuwan Dias < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, Mar 23, 2017 at 3:15 PM, Joseph Fonseka < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I guess there is a possibility of that API developer not >>>>>>>>>>>>>>>>> being the one who publish / create the API ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes, the API Developer may not be the same one who's >>>>>>>>>>>>>>>> publishing the it. But what's wrong with him testing the API >>>>>>>>>>>>>>>> under >>>>>>>>>>>>>>>> development using a valid token? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If this is valid argument then person who create APIs can >>>>>>>>>>>>>>> consume it. If we consider scenario where we develop API and >>>>>>>>>>>>>>> later it >>>>>>>>>>>>>>> published and appear in gateways, just because I'm developer >>>>>>>>>>>>>>> will i get >>>>>>>>>>>>>>> chance to use this API? I don't think we should allow it. Even >>>>>>>>>>>>>>> if we say we >>>>>>>>>>>>>>> are testing what actually happen is someone invoke API and get >>>>>>>>>>>>>>> results. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> In API Manager 3.0.0, the API deployment to the Gateway >>>>>>>>>>>>>> happens before the Publishing phase actually. It gets deployed >>>>>>>>>>>>>> on the >>>>>>>>>>>>>> Gateway as soon as its created. >>>>>>>>>>>>>> >>>>>>>>>>>>> Why do we deploy API to gateway by the time we created it? >>>>>>>>>>>>> Ideally it should go to topic and notified only after publishing >>>>>>>>>>>>> it. I >>>>>>>>>>>>> haven't noticed it any of our previous discussions. >>>>>>>>>>>>> Did i missed something here? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The cause is the same as before. We want to enable API testing >>>>>>>>>>>> on the publisher itself so that API developers can test their API >>>>>>>>>>>> before >>>>>>>>>>>> publishing it to the Store. In order to test an API, it should be >>>>>>>>>>>> deployed >>>>>>>>>>>> on the Gateway. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> sanjeewa. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the API developer accessing a published API with a valid >>>>>>>>>>>>>> token is a concern, we can automatically remove the publisher >>>>>>>>>>>>>> webapp's >>>>>>>>>>>>>> subscription to the API once the API gets published. This will >>>>>>>>>>>>>> prevent the >>>>>>>>>>>>>> API developers and publishers from accessing a published API >>>>>>>>>>>>>> since they no >>>>>>>>>>>>>> longer have a valid subscription. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> sanjeewa. >>>>>>>>>>>>>>> This can be an edge case, but if you consider an API >>>>>>>>>>>>>>> designed to work with client credentials ie. B2B API, >>>>>>>>>>>>>>> subscription is the >>>>>>>>>>>>>>> authorization point for that API if so you don't want the >>>>>>>>>>>>>>> creator or >>>>>>>>>>>>>>> publisher on accessing it ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I guess it is fare to ask a user to go though subscription >>>>>>>>>>>>>>> process to test the published API without magic. WDYT ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Well, the point here is that we're trying to provide the >>>>>>>>>>>>>>>> facility for the Developer to test the API he's developing >>>>>>>>>>>>>>>> before >>>>>>>>>>>>>>>> publishing it. Because that's a very valid use case. Asking >>>>>>>>>>>>>>>> the developer >>>>>>>>>>>>>>>> to publish the API and subscribe to it in order to be able to >>>>>>>>>>>>>>>> safely test >>>>>>>>>>>>>>>> it is not right IMO. The sole reason he wants to test the API >>>>>>>>>>>>>>>> first is >>>>>>>>>>>>>>>> because he's not ready to publish it yet. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks & Regards >>>>>>>>>>>>>>>>> Jo >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Mar 23, 2017 at 2:32 PM, Nuwan Dias < >>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Why is it a concern? Its only the App developers who have >>>>>>>>>>>>>>>>>> the subscriber role. Almost all consumers of the API are >>>>>>>>>>>>>>>>>> general users and >>>>>>>>>>>>>>>>>> hence do not have the subscriber role. So why is it a >>>>>>>>>>>>>>>>>> concern to allow the >>>>>>>>>>>>>>>>>> person who's developing the API to access it? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Thu, Mar 23, 2017 at 1:59 PM, Lakmali Baminiwatta < >>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 23 March 2017 at 13:46, Joseph Fonseka < >>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Thu, Mar 23, 2017 at 1:01 PM, Lakmali Baminiwatta < >>>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> In publisher shouldn't we invoke the API back-end >>>>>>>>>>>>>>>>>>>>>> instead of Gateway ? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I guess publisher may need to test the API execution >>>>>>>>>>>>>>>>>>>>> flow through gateway. For instance the resource paths, >>>>>>>>>>>>>>>>>>>>> mediation logics, >>>>>>>>>>>>>>>>>>>>> etc. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yes that make sense, but if we automatically subscribe >>>>>>>>>>>>>>>>>>>> to a published API it will allow a user ( ie user with >>>>>>>>>>>>>>>>>>>> creator role in >>>>>>>>>>>>>>>>>>>> publisher ) who may not have subscription permission to >>>>>>>>>>>>>>>>>>>> invoke an API. That >>>>>>>>>>>>>>>>>>>> might be a security concern based on a company policy. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yes, this can be a valid concern. In that case we can >>>>>>>>>>>>>>>>>>> allow this only for users with publish permissions. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Lakmali >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Or are we only allowing the test feature in publisher >>>>>>>>>>>>>>>>>>>> for specific roles. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>> Jo >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Lakmali >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> IMO it would be difficult to explain the mention >>>>>>>>>>>>>>>>>>>>>> approach to a user than what we have. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks & Regards >>>>>>>>>>>>>>>>>>>>>> Jo >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The proposed solution is to generate an access token >>>>>>>>>>>>>>>>>>>>>>> with the UUF app's credentials + special scope. The >>>>>>>>>>>>>>>>>>>>>>> subscription validation >>>>>>>>>>>>>>>>>>>>>>> will be skipped for the tokens in this special scope. >>>>>>>>>>>>>>>>>>>>>>> For implementing the >>>>>>>>>>>>>>>>>>>>>>> solution, we have to consider below points. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> - Grant Type - If the client_credentials grant >>>>>>>>>>>>>>>>>>>>>>> type is used, all the concurrent users accessing the >>>>>>>>>>>>>>>>>>>>>>> UI app will get the >>>>>>>>>>>>>>>>>>>>>>> same token. In order to do any user level >>>>>>>>>>>>>>>>>>>>>>> restrictions for this token in >>>>>>>>>>>>>>>>>>>>>>> the gateway level, we have to use password grant >>>>>>>>>>>>>>>>>>>>>>> type. One case is >>>>>>>>>>>>>>>>>>>>>>> visibility restricted API invocations. Also I guess >>>>>>>>>>>>>>>>>>>>>>> we shouldn't allow to >>>>>>>>>>>>>>>>>>>>>>> invoke API resources protected with scopes if the >>>>>>>>>>>>>>>>>>>>>>> logged in user is not >>>>>>>>>>>>>>>>>>>>>>> allowed for that. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> - Scope white listing - This scope has to be >>>>>>>>>>>>>>>>>>>>>>> white listed, since the API resource is not actually >>>>>>>>>>>>>>>>>>>>>>> protected with it. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> - Throttling - Since there is no API >>>>>>>>>>>>>>>>>>>>>>> subscription, special throttle limit has to be >>>>>>>>>>>>>>>>>>>>>>> applied with some minimum >>>>>>>>>>>>>>>>>>>>>>> quota. One option is to apply the unauthenticated >>>>>>>>>>>>>>>>>>>>>>> tier limits which does a >>>>>>>>>>>>>>>>>>>>>>> throttling based on the client IP. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> - Token validity and refresh token - If the >>>>>>>>>>>>>>>>>>>>>>> client_credential grant type is used, we can't >>>>>>>>>>>>>>>>>>>>>>> invalidate this test token >>>>>>>>>>>>>>>>>>>>>>> when a user is logged out since other users might be >>>>>>>>>>>>>>>>>>>>>>> using it already. >>>>>>>>>>>>>>>>>>>>>>> Therefore IMO, we can use password grant type and >>>>>>>>>>>>>>>>>>>>>>> use the similar token >>>>>>>>>>>>>>>>>>>>>>> refreshing mechanism done for UUF app authentication. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> - Obtaining the access token - In order to get >>>>>>>>>>>>>>>>>>>>>>> an access token, we need the consumer key and secret >>>>>>>>>>>>>>>>>>>>>>> of the UUF app. >>>>>>>>>>>>>>>>>>>>>>> Currently we do a UUF backend app call only when the >>>>>>>>>>>>>>>>>>>>>>> user is authenticating >>>>>>>>>>>>>>>>>>>>>>> or when refreshing the token. So here also, I think >>>>>>>>>>>>>>>>>>>>>>> we can generate the >>>>>>>>>>>>>>>>>>>>>>> test token when the user is authenticated(log in to >>>>>>>>>>>>>>>>>>>>>>> the UUF app) and store >>>>>>>>>>>>>>>>>>>>>>> it in the local storage. I believe its okay to >>>>>>>>>>>>>>>>>>>>>>> display this access token >>>>>>>>>>>>>>>>>>>>>>> for the user. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Lakmali >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> Lakmali Baminiwatta >>>>>>>>>>>>>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>>>>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>>>>>>>>> mobile: +94 71 2335936 >>>>>>>>>>>>>>>>>>>>>>> blog : lakmali.com >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> *Joseph Fonseka* >>>>>>>>>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> mobile: +94 772 512 430 >>>>>>>>>>>>>>>>>>>>>> skype: jpfonseka >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> Lakmali Baminiwatta >>>>>>>>>>>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>>>>>>> mobile: +94 71 2335936 >>>>>>>>>>>>>>>>>>>>> blog : lakmali.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> *Joseph Fonseka* >>>>>>>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> mobile: +94 772 512 430 >>>>>>>>>>>>>>>>>>>> skype: jpfonseka >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Lakmali Baminiwatta >>>>>>>>>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>>>>> mobile: +94 71 2335936 >>>>>>>>>>>>>>>>>>> blog : lakmali.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Nuwan Dias >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>>>>>>>>> email : [email protected] >>>>>>>>>>>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> *Joseph Fonseka* >>>>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> mobile: +94 772 512 430 >>>>>>>>>>>>>>>>> skype: jpfonseka >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Nuwan Dias >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>>>>>>> email : [email protected] >>>>>>>>>>>>>>>> Phone : +94 777 775 729 <077%20777%205729> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Nuwan Dias >>>>>>>>>>>>>> >>>>>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>>>>> email : [email protected] >>>>>>>>>>>>>> Phone : +94 777 775 729 <077%20777%205729> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>>>>>>> >>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Nuwan Dias >>>>>>>>>>>> >>>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>>> email : [email protected] >>>>>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Lakmali Baminiwatta >>>>>>>>>>> Associate Technical Lead >>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>> mobile: +94 71 2335936 >>>>>>>>>>> blog : lakmali.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Nuwan Dias >>>>>>>>>> >>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>> email : [email protected] >>>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Joseph Fonseka* >>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>> lean.enterprise.middleware >>>>>>>>> >>>>>>>>> mobile: +94 772 512 430 >>>>>>>>> skype: jpfonseka >>>>>>>>> >>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Nuwan Dias >>>>>>>> >>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>> email : [email protected] >>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Lakmali Baminiwatta >>>>>>> Associate Technical Lead >>>>>>> WSO2, Inc.: http://wso2.com >>>>>>> lean.enterprise.middleware >>>>>>> mobile: +94 71 2335936 >>>>>>> blog : lakmali.com >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> -- >>>>>> *Joseph Fonseka* >>>>>> WSO2 Inc.; http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> >>>>>> mobile: +94 772 512 430 >>>>>> skype: jpfonseka >>>>>> >>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Lakmali Baminiwatta >>>>> Associate Technical Lead >>>>> WSO2, Inc.: http://wso2.com >>>>> lean.enterprise.middleware >>>>> mobile: +94 71 2335936 >>>>> blog : lakmali.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> -- >>>> *Joseph Fonseka* >>>> WSO2 Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> mobile: +94 772 512 430 >>>> skype: jpfonseka >>>> >>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Lakmali Baminiwatta >>> Associate Technical Lead >>> WSO2, Inc.: http://wso2.com >>> lean.enterprise.middleware >>> mobile: +94 71 2335936 >>> blog : lakmali.com >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> -- >> *Joseph Fonseka* >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 772 512 430 >> skype: jpfonseka >> >> * <http://lk.linkedin.com/in/rumeshbandara>* >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Lakmali Baminiwatta > Associate Technical Lead > WSO2, Inc.: http://wso2.com > lean.enterprise.middleware > mobile: +94 71 2335936 > blog : lakmali.com > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- -- *Joseph Fonseka* WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 772 512 430 skype: jpfonseka * <http://lk.linkedin.com/in/rumeshbandara>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
