synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruwan Linton <ruwan.lin...@gmail.com>
Subject Re: Making loadbalance/failover configuration more convenient
Date Sun, 02 May 2010 12:47:20 GMT
+1

Dynamic URLs are very important, since you might want to have a LB endpoint
to balance the load among a set of identical nodes regardless of the service
to which the current request is directed to.

I propose the following configuration;

<address [uri=""] |
[uri-expression="${protocol}://${host}[:${port}][${path}]"] |
[path-regex="regex"]/>

where, any of the above parts can have static values as well. Apart from
that, you could specify a "path-regex" to extract out part of the URL path
as out bound path.

Please note that we are bit biased towards the http transport in this sample
configuration but will make sure the same behavior is available for other
transports as well. (Hiranya, I guess your comment on RFC's and relevant
fragmentation in the above comment is on URL's but not URI's, fragmentations
on URI's are much constrained since it is just an identifier, which could be
any string :-()

Thanks,
Ruwan

On Sat, May 1, 2010 at 11:25 PM, Supun Kamburugamuva <supun06@gmail.com>wrote:

>
>
> On Fri, Apr 30, 2010 at 10:21 AM, Hiranya Jayathilaka <
> hiranya911@gmail.com> wrote:
>
>> Hi Indika,
>>
>> On Fri, Apr 30, 2010 at 10:00 PM, indika kumara <indika.kuma@gmail.com>wrote:
>>
>>> Hi All
>>>
>>> I am just putting my thought … An endpoint is to capture the information
>>> about an external service including its access location, QoS requirements,
>>> etc.  In synapse point of view, we can only identify two types to give
>>> external service information… i.e Address and WSDL.
>>>
>>> In Address endpoint, the only way to give the location of the external
>>> service is URI. There are two ways – implicit and explicit.  In the case of
>>> the implicit, we never want to give URI because the endpoint itself knows
>>> how to find it. We used “Default endpoint” to capture this behavior of the
>>> address endpoint. From my point of view, the use of ‘Default’ is wrong
>>> because, there is only two ways to capture external service information
>>> (using either an epr address or WSDL). I believe, as ‘Default’ is the case
>>> where the URI of an address endpoint should be calculated from the implicit
>>> properties, the URI should be optional, and the keyword of address, and WSDL
>>> are the only meaning full domain specific names for indicating that this is
>>> a component that represents a connector to an external service.  This type
>>> of address endpoint can leverage components such as URI rewrite mediator.
>>>
>>> In the case of the explicit, we have to specify the URI of the address
>>> endpoint through a configuration. URI can be static and dynamic.
>>
>>
>> Ok this makes sense.
>>
>>
>>> In the static case, there is no only one way i.e giving the complete URI
>>> in the configuration. However, in the dynamic case, there are a few ways.
>>> To analyze this, we can divide endpoint URI into two parts – prefix and
>>> suffix. So therefore, available options for a dynamic endpoint URI as
>>> follows
>>>
>>> Case 1 : prefix - dynamic and suffix  - dynamic
>>>
>>> Case 2 : prefix – dynamic and suffix – static
>>>
>>> Case 3 : prefix – static and suffix – dynamic  - I believe  the Miyuru’s
>>> suggestion belong to this category
>>>
>>
>> So what you are really suggesting is not exactly URL rewrite capability,
>> but rather dynamic EPR calculation capability to be built into the address
>> endpoint. That's not a bad idea.
>>
>>
>>>
>>> So my suggestion , we should give a compressive way to  specify the URI
>>> of an address endpoint  and I also believe there is no need for a default
>>> endpoint …  so my suggestion to capture all these requirements
>>>
>>> <address>
>>>
>>>     <uri [ value="" expression="" ]> { case 1  or static URI}
>>>
>>>         <prefix [ value="" | expression="" ] />  { case 2 / 3 }
>>>
>>>         <suffix [ value="" | expression="" ] /> { case 2  / 3}
>>>
>>>     </uri>
>>>
>>> </address>
>>>
>>
>> I'm -1 on this URL fragmentation scheme (prefix and suffix). Concepts of
>> URL and URI are governed by a set of specs and RFCs. If we are to introduce
>> a fragmentation scheme we should think along those standards and not invent
>> our own custom stuff. That will make things more complex for us to implement
>> and more difficult for users to understand. The relevant specs already
>> define proper fragmentation schemes to be used with URLs and URIs and AFAIK
>> Java supports them out of the box.
>>
>>
>  +1, I think we should come up with a configuration scheme complient with
> the URL parts defined in the RFC.
>
> Thanks,
> Supun..
>
>
>> Thanks,
>> Hiranya
>>
>>
>>>
>>> URI is optional - case is the implicit URI of an address endpoint
>>>
>>> Either the URI attributes: value or expression or both prefix or suffix
>>> elements should be present.  I do not know whether a schema can be written
>>> for this.
>>>
>>> This is just my thought and I am not against anyone suggestions …
>>>
>>> Thanks
>>>
>>> Indika
>>>
>>>
>>
>>
>> --
>> Hiranya Jayathilaka
>> Software Engineer;
>> WSO2 Inc.;  http://wso2.org
>> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
>> Blog: http://techfeast-hiranya.blogspot.com
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>


-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

Mime
View raw message