Please ignore my previous post.
+1 for introducing inbound.only=true for proxy services.
How about defining proxy/API level endpoint/endpoints rather defining those
in the inbound EP?
<proxy>
<inbound-endpoint/>
</proxy>
or
<proxy>
<parameter name="inboundEndpoints">endpoint1, endpoint2</parameter>
</proxy>
Thanks
On Sun, Jun 28, 2015 at 12:28 AM, Prabath Ariyarathna <[email protected]>
wrote:
> +1 for introducing inbound.only=true for proxy services.
>
> How about introducing proxy level endpoint/endpoints rather than enabling
> proxy service to all available inbound endpoints?
>
> <proxy>
> <inbound-endpoint/>
> </proxy>
>
> or
>
> <proxy>
> <parameter name="inboundEndpoints">endpoint1, endpoint2</parameter>
> </proxy>
>
>
> Thanks
>
> On Sat, Jun 27, 2015 at 9:46 PM, Jagath Sisirakumara Ariyarathne <
> [email protected]> wrote:
>
>> +1
>>
>> Handling this logic at Inbound EP level will give us the flexibility for
>> more use cases and future changes as well.
>>
>> 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
>>>
>>>
>>
>>
>> --
>> Jagath Ariyarathne
>> Technical Lead
>> WSO2 Inc. http://wso2.com/
>> Email: [email protected]
>> Mob : +94 77 386 7048
>>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Prabath Ariyarathna*
>
> *Associate Technical Lead*
>
> *WSO2, Inc. *
>
> *lean . enterprise . middleware *
>
>
> *Email: [email protected] <[email protected]>*
>
> *Blog: http://prabu-lk.blogspot.com <http://prabu-lk.blogspot.com>*
>
> *Flicker : https://www.flickr.com/photos/47759189@N08
> <https://www.flickr.com/photos/47759189@N08>*
>
> *Mobile: +94 77 699 4730 *
>
>
>
>
>
>
--
*Prabath Ariyarathna*
*Associate Technical Lead*
*WSO2, Inc. *
*lean . enterprise . middleware *
*Email: [email protected] <[email protected]>*
*Blog: http://prabu-lk.blogspot.com <http://prabu-lk.blogspot.com>*
*Flicker : https://www.flickr.com/photos/47759189@N08
<https://www.flickr.com/photos/47759189@N08>*
*Mobile: +94 77 699 4730 *
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
