synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Supun Kamburugamuva <supu...@gmail.com>
Subject Re: Making loadbalance/failover configuration more convenient
Date Tue, 04 May 2010 16:46:35 GMT
On Mon, May 3, 2010 at 7:42 PM, indika kumara <indika.kuma@gmail.com> wrote:

> 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>
>
> In the proposed approach I believe the user has to set the properties,
protocol, host, port and path.

For example to calculate the path user has to say.

<property name="path" value="path value" scope="synapse"/>.

And we will parse the above url and replace the ${} with
the calculated values.

Thanks,
Supun..


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


-- 
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

Mime
View raw message