Hi Kasun, Yes we don't have plan to read endpoints from registry by default. And obviously we cant do that because of the distributed deployment architecture do not allow us to share registry between publisher and gateway(when create API from publisher can put sequences, endpoints etc to publisher's registry space). Because of that we need to store endpoints in publisher registry and use them during API creation process. But when we publish it to gateway we will deploy exact endpoint to gateway manager(after resolving environment). So we need to use endpoint, sequence admin services deployed in gateway manager and push synapse artifacts to gateway manager via web service call. If we do that then we may not need to share registry and mandate registry endpoints.
The problem with environment variables and other variables is these endpoints can change rapidly. And system administrator do not know all of these at the beginning as different tenants may have different endpoints(and during the runtime properties can be added). If we can have solution for that then we may use parameterized URLs as well. Thanks, sanjeewa. On Fri, Aug 19, 2016 at 1:08 AM, Kasun Indrasiri <[email protected]> wrote: > Hi Harsha/Sanjeewa, > > Can you explain a bit about the runtime behavior? Are you suggesting to > read endpoint from registry by default? > > Anyway doing this at API-M level seems to be not the ideal solution. I'd > rather prefer to introduce the variable concept across all the artifacts in > ESB and use the same for above use case. So, can we think about a solution > around endpoint templates where we extend the template variable resolution > mechanism? > > For eg: This is an EP that users a template by resolving address from a > system properly. > <send> > <endpoint name="MyEp" template="endPointTemplete" uri="http:// > {system.prop.host}:{system.prop.port}/services/SimpleStockQuoteService"/> > </send> > > > On Thu, Aug 18, 2016 at 11:37 AM, Harsha Kumara <[email protected]> wrote: > >> >> On Wed, Aug 17, 2016 at 11:52 AM, Sanjeewa Malalgoda <[email protected]> >> wrote: >> >>> >>> >>> On Wed, Aug 17, 2016 at 11:44 AM, Bhathiya Jayasekara <[email protected] >>> > wrote: >>> >>>> Hi Sanjeewa, >>>> >>>> On Wed, Aug 17, 2016 at 11:37 AM, Sanjeewa Malalgoda <[email protected] >>>> > wrote: >>>> >>>>> It works like this, >>>>> When you go to publisher and develop API you can see certain endpoints >>>>> based on the roles you assigned. >>>>> Then if need you can pick existing endpoint and create API if need. >>>>> Else you can create brand new endpoint and use it for your API. If you >>>>> think this endpoint need to shared with your friends then you set >>>>> visibility of that endpoint to role. >>>>> Then users belong to that role can use that endpoint and create API if >>>>> need. >>>>> >>>>> You can only see your APIs >>>>> >>>> >>>> This is exactly what I'm talking about. We don't have this in API >>>> manager, do we? >>>> If we have this, then role based access control for endpoints is a >>>> valid requirement. >>>> >>> Yes you are right, actually its your tenant APIs. So if we have multiple >>> roles within tenant then that could cause a problem like you mentioned. >>> When we try to edit others APIs in publisher we will see endpoint we are >>> not suppose to see. Seems we need solution for that. >>> >>> Yes, that's the point that I was talking earlier as well. Currently we >> don't have endpoint visibility control in API Manager. So if someone edits >> some other users' API, he can see that user's endpoint. By separating >> endpoint definition, we can control the visibility of newly adding >> endpoints. IMO Introducing visibility control for inline endpoint >> definition will make things complex. So with feature, if user don't want to >> share his endpoint, he may define his endpoint and set visible roles. Even >> though some other user view his API, he will only see the endpoint name. >> >>> Thanks, >>> sanjeewa. >>> >>>> >>>> Thanks, >>>> Bhathiya >>>> >>>> >>>>> You can create them only with allowed endpoints. So there is no such >>>>> thing seeing API but not endpoints. >>>>> >>>>> >>>>> >>>>> On Wed, Aug 17, 2016 at 11:31 AM, Bhathiya Jayasekara < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 17, 2016 at 11:21 AM, Sanjeewa Malalgoda < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 17, 2016 at 11:14 AM, Bhathiya Jayasekara < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Sanjeewa, >>>>>>>> >>>>>>>> On Wed, Aug 17, 2016 at 10:39 AM, Sanjeewa Malalgoda < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 17, 2016 at 8:56 AM, Harsha Kumara <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Aug 17, 2016 at 12:09 AM, Bhathiya Jayasekara < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On Tue, Aug 16, 2016 at 10:31 PM, Harsha Kumara < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We can use a role base model to control the visibility of >>>>>>>>>>>> defined endpoints. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> But this will be challenging since we don't have a role based >>>>>>>>>>> access control for APIs in publisher. Actually it does not make >>>>>>>>>>> sense to >>>>>>>>>>> have such an access control only for endpoints when APIs are open >>>>>>>>>>> to all. >>>>>>>>>>> For example, say endpoint E1 is visible only to Role1, and Role2 >>>>>>>>>>> can't see >>>>>>>>>>> that. If someone with Role1 creates an API with E1, all users in >>>>>>>>>>> Role2 also >>>>>>>>>>> can see that API, which means they can/should see E1 too. So IMO, >>>>>>>>>>> first we >>>>>>>>>>> have to come to a decision whether we implement roles base API >>>>>>>>>>> visibility >>>>>>>>>>> in publisher or not. Then we can decide how to implement visibility >>>>>>>>>>> for >>>>>>>>>>> endpoints. >>>>>>>>>>> >>>>>>>>>>> Yes, currently anyone can see the APIs in publisher able to look >>>>>>>>>> at the defined endpoints in implementation phase. Since we only >>>>>>>>>> giving >>>>>>>>>> option of selecting the endpoint name only, user who don't have the >>>>>>>>>> required role only see the name of it. But again it's not >>>>>>>>>> consistent. If we >>>>>>>>>> going to support the endpoint visibility based on a scheme such as >>>>>>>>>> role >>>>>>>>>> based, we may need to look at the API visibility in publisher as >>>>>>>>>> well. >>>>>>>>>> >>>>>>>>> If we think carefully its not a new thing. As example we can >>>>>>>>> consider tier permissions. Anyone can login to API store and create >>>>>>>>> application. But only few specific users will see some tiers and they >>>>>>>>> can >>>>>>>>> use them for their subscriptions. >>>>>>>>> >>>>>>>> >>>>>>>> In this case we control visibility in store side. There we can do >>>>>>>> that. (We do have even API visibility in store.) But when we talk about >>>>>>>> endpoints, it's about publisher. And we have a visibility issue to >>>>>>>> solve >>>>>>>> there. >>>>>>>> >>>>>>>> IIRC, every publisher can see all subscription tiers regardless of >>>>>>>> the role based visibility we set for them. So the problem is there in >>>>>>>> publisher. >>>>>>>> >>>>>>> Its not a problem, that is how we implemented it there(as there was >>>>>>> no use case for role based visibility control). >>>>>>> >>>>>> >>>>>> Yeah that's correct. I didn't mean there's a problem in tier >>>>>> subscriptions. What I meant was that we already have store side role >>>>>> based >>>>>> visibility for APIs, subscription tiers etc., but we still don't have it >>>>>> in >>>>>> publisher side. >>>>>> >>>>>> >>>>>>> Even in publisher we can do certain permission checks and show >>>>>>> content based on permissions user allowed. >>>>>>> >>>>>> >>>>>> Yes technically that may be possible. But does that make sense if you >>>>>> have access to an API but not for its endpoints (like in the example I >>>>>> gave >>>>>> in my 1st reply)? >>>>>> >>>>>> Thanks, >>>>>> Bhathiya >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> sanjeewa. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bhathiya >>>>>>>> >>>>>>>> >>>>>>>>> In same way we can have endpoints which users can see according >>>>>>>>> to roles they assigned. And if they can see then they can use them. >>>>>>>>> WDYT? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> sanjeewa. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>>> Bhathiya >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> sanjeewa. >>>>>>>>>>>>> >>>>>>>>>>>>>> [1] - http://wso2.com/library/arti >>>>>>>>>>>>>>> cles/2016/03/article-architecting-a-multi-environment-api-ma >>>>>>>>>>>>>>> nager-deployment-with-wso2-api-manager/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Harsha >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Harsha Kumara >>>>>>>>>>>>>>> Software Engineer, WSO2 Inc. >>>>>>>>>>>>>>> Mobile: +94775505618 >>>>>>>>>>>>>>> Blog:harshcreationz.blogspot.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>>>> Mobile : +94713068779 >>>>>>>>>>>>>> >>>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>>> Mobile : +94713068779 >>>>>>>>>>>>> >>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Harsha Kumara >>>>>>>>>>>> Software Engineer, WSO2 Inc. >>>>>>>>>>>> Mobile: +94775505618 >>>>>>>>>>>> Blog:harshcreationz.blogspot.com >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Bhathiya Jayasekara* >>>>>>>>>>> *Senior Software Engineer,* >>>>>>>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>>>>>>>>> >>>>>>>>>>> *Phone: +94715478185 <%2B94715478185>* >>>>>>>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>>>>>>>>> <http://www.linkedin.com/in/bhathiyaj>* >>>>>>>>>>> *Twitter: https://twitter.com/bhathiyax >>>>>>>>>>> <https://twitter.com/bhathiyax>* >>>>>>>>>>> *Blog: http://movingaheadblog.blogspot.com >>>>>>>>>>> <http://movingaheadblog.blogspot.com/>* >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Harsha Kumara >>>>>>>>>> Software Engineer, WSO2 Inc. >>>>>>>>>> Mobile: +94775505618 >>>>>>>>>> Blog:harshcreationz.blogspot.com >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>> WSO2 Inc. >>>>>>>>> Mobile : +94713068779 >>>>>>>>> >>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Bhathiya Jayasekara* >>>>>>>> *Senior Software Engineer,* >>>>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>>>>>> >>>>>>>> *Phone: +94715478185 <%2B94715478185>* >>>>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>>>>>> <http://www.linkedin.com/in/bhathiyaj>* >>>>>>>> *Twitter: https://twitter.com/bhathiyax >>>>>>>> <https://twitter.com/bhathiyax>* >>>>>>>> *Blog: http://movingaheadblog.blogspot.com >>>>>>>> <http://movingaheadblog.blogspot.com/>* >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Sanjeewa Malalgoda* >>>>>>> WSO2 Inc. >>>>>>> Mobile : +94713068779 >>>>>>> >>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Bhathiya Jayasekara* >>>>>> *Senior Software Engineer,* >>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>>>> >>>>>> *Phone: +94715478185 <%2B94715478185>* >>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>>>> <http://www.linkedin.com/in/bhathiyaj>* >>>>>> *Twitter: https://twitter.com/bhathiyax >>>>>> <https://twitter.com/bhathiyax>* >>>>>> *Blog: http://movingaheadblog.blogspot.com >>>>>> <http://movingaheadblog.blogspot.com/>* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Sanjeewa Malalgoda* >>>>> WSO2 Inc. >>>>> Mobile : +94713068779 >>>>> >>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Bhathiya Jayasekara* >>>> *Senior Software Engineer,* >>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>> >>>> *Phone: +94715478185 <%2B94715478185>* >>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>> <http://www.linkedin.com/in/bhathiyaj>* >>>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >>>> *Blog: http://movingaheadblog.blogspot.com >>>> <http://movingaheadblog.blogspot.com/>* >>>> >>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >> >> >> -- >> Harsha Kumara >> Software Engineer, WSO2 Inc. >> Mobile: +94775505618 >> Blog:harshcreationz.blogspot.com >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Kasun Indrasiri > Director, Integration Technologies > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +1 650 450 2293 > Blog : http://kasunpanorama.blogspot.com/ > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <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
