Hi All,
We had a review on the implementation done for supporting the filtering
logic. Please find below the points discussed during the review.
- Exposing all the API/Proxy through the ports which we are creating
inbound endpoints may affect the existing customers in a confusing manner.
Most of our existing customers are using single http listener configured
for listening http requests (This may differ with the inbound capability in
the future). Let's say an existing customer is migrating from ESB 4.8.1 to
4.9.0. If he creates an inbound endpoint for a specific use case, with the
existing functionality, all the remaining API/Proxy services will be
exposed through this port. This will cause several issues related to
security. The point here is that if the user wants to expose them through
all the ports, that we can accommodate as an optional feature. But the
default behavior should be to expose that specific sequence, API or Proxy
through that port.
- We will implement the filtering functionality such that
- by default, requests would be dispatched to the defined
sequence.
- If the user wants to expose all the Proxy/API through
this port, he can specify the "dispatch.filter.pattern" parameter as ' * '.
- If the user wants to expose only a set of Proxy/API,
then he can specify the "dispatch.filter.pattern" parameter matching to
that specific pattern (eg: services/)
- On filter failure we can invoke the defined fault sequence (or main
fault if no fault is defined).
Any suggestions?
Thanks,
Chanaka
On Thu, Jul 2, 2015 at 1:58 PM, Isuru Udana <[email protected]> wrote:
> Hi Shankar,
>
> Please find answers inline.
>
> On Thu, Jul 2, 2015 at 1:39 PM, Selvaratnam Uthaiyashankar <
> [email protected]> wrote:
>
>> How does this work in multi-tenancy? If one tenant create an inbound
>> endpoint, it is available to all tenants or all proxies of all tenants
>> exposed through that port?
>>
> No. If a tenant create an inbound endpoint, it is only available for that
> particular tenant. Two tenants are completely isolated (similar to other
> artifacts).
>
>
>> Also, can two tenants define inbound endpoint with same port (there will
>> be only 1 physical listener on the port though).. ?
>>
> Yes. Two tenants can share the same port. We have decouple the listener
> and the inbound endpoint artifact to achieve this.
>
> Thanks.
>
>>
>> On Fri, Jun 26, 2015 at 4:25 PM, Kasun Indrasiri <[email protected]> wrote:
>>
>>> Hi,
>>>
>>> In the current HTTP Inbound EP impl, the message dispatching occurs as
>>> follows.
>>>
>>> - All proxy services and APIs are exposed on default HTTP port (8280).
>>> - We can create a HTTP inbound EP that listens for request on a given
>>> port (say 6060). Once we do that, all the proxy services and APIs are also
>>> available via that port (i.e.: You can access the same proxy service via
>>> 8280 or 6060).
>>> - Likewise as you keep on creating inbound EPs, the existing proxies and
>>> APIs will be exposed on those ports.
>>> - Using a service parameter (inbound.only=true), we block any request
>>> that comes to a proxy service and only expose that through inbound
>>> endpoints.
>>>
>>> IMO, above behavior may be useful in certain use cases, but there can be
>>> a requirement which the user doesn't want to expose all proxy services/api
>>> through all the available HTTP endpoints. Hence, it is required to control
>>> the dispatching logic at Inbound EP level, so that we can specify the
>>> allowed services and APIs (as a pattern matching expression) when we define
>>> an inbound EP.
>>>
>>> Any thoughts?
>>>
>>> Thanks,
>>>
>>> --
>>> Kasun Indrasiri
>>> Software Architect
>>> WSO2, Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> cell: +94 77 556 5206
>>> Blog : http://kasunpanorama.blogspot.com/
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> S.Uthaiyashankar
>> VP Engineering
>> WSO2 Inc.
>> http://wso2.com/ - "lean . enterprise . middleware"
>>
>> Phone: +94 714897591
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Isuru Udana*
> Associate Technical Lead
> WSO2 Inc.; http://wso2.com
> email: [email protected] cell: +94 77 3791887
> blog: http://mytecheye.blogspot.com/
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
--
Chanaka Fernando
Senior Technical Lead
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware
mobile: +94 773337238
Blog : http://soatutorials.blogspot.com
LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
Twitter:https://twitter.com/chanakaudaya
Wordpress:http://chanakaudaya.wordpress.com
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
