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 Sat, 01 May 2010 17:55:04 GMT
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

Mime
View raw message