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
