synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From indika kumara <indika.k...@gmail.com>
Subject Re: Making loadbalance/failover configuration more convenient
Date Mon, 03 May 2010 14:12:51 GMT
Ruwan

When I am just going through [1] ,  I feel that the use of  XML element for
URI is more suitable than an attribute. The variation is in URI and not in
address endpoint.

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

Thanks

Indika

[1] http://www.ibm.com/developerworks/xml/library/x-eleatt.html


On Sun, May 2, 2010 at 6:47 PM, Ruwan Linton <ruwan.linton@gmail.com> wrote:

> +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