You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Miyuru <mi...@gmail.com> on 2010/04/29 14:14:56 UTC
Making loadbalance/failover configuration more convenient
Hi all,
This mail is regarding https://issues.apache.org/jira/browse/SYNAPSE-567.
Currently when we defining leaf endpoints of loadbalance/failover endpoint
we have to explicitly define full url of the endpoint.
However in most loadbalance/failover scenarios endpoints are like
{IP_X}:{PORT_A}/services/MyService
{IP_Y}:{PORT_B}/services/MyService
{IP_Z}:{PORT_C}/services/MyService
Proposed solution is, configure addresss endpoint like this
<endpoint>
<address uri="https://localhost:8852/$INCOMING_URL_PATH">
</address>
</endpoint>
and replace path of the url ("services/MyService") with $INCOMING_URL_PATH.
Is this a proper solution? Else we can upgrade default endpoint to rewrite
address using regular expression which is more flexible solution.
Any ideas?
Thanks,
--
Miyuru Daminda Wanninayaka
Software Engineer - WSO2 Inc.
Re: Making loadbalance/failover configuration more convenient
Posted by Ruwan Linton <ru...@gmail.com>.
Miyuru,
In general +1, let me refine the idea a bit more.
Most of the time, users will need to extract part of the URL path, than the
complete path, so it is better if we can make it a regex so that it could
extract any part of the URL path.
<address uri="http://x.x.x.x:yyyy/@{regex, expression}"
Thanks,
Ruwan
On Thu, Apr 29, 2010 at 5:44 PM, Miyuru <mi...@gmail.com> wrote:
> Hi all,
>
> This mail is regarding https://issues.apache.org/jira/browse/SYNAPSE-567.
> Currently when we defining leaf endpoints of loadbalance/failover endpoint
> we have to explicitly define full url of the endpoint.
> However in most loadbalance/failover scenarios endpoints are like
> {IP_X}:{PORT_A}/services/MyService
> {IP_Y}:{PORT_B}/services/MyService
> {IP_Z}:{PORT_C}/services/MyService
>
> Proposed solution is, configure addresss endpoint like this
>
> <endpoint>
> <address uri="https://localhost:8852/$INCOMING_URL_PATH">
> </address>
> </endpoint>
>
> and replace path of the url ("services/MyService") with $INCOMING_URL_PATH.
> Is this a proper solution? Else we can upgrade default endpoint to rewrite
> address using regular expression which is more flexible solution.
>
> Any ideas?
>
> Thanks,
> --
> Miyuru Daminda Wanninayaka
> Software Engineer - WSO2 Inc.
>
--
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
Re: Making loadbalance/failover configuration more convenient
Posted by indika kumara <in...@gmail.com>.
>
>
> + 1 for the idea. I was thinking in the same lines. If we make the suffix
> dynamic we can deprecate the DefaultEndpoint.
>
> I'm not that comfortable with the configuration. But configuration is
> something we can always improve and get to a common ground. But I like the
> idea.
>
sure .. Supun.. It is an initial suggestion and should be improved based on
community feedback.. The configuration is the synapse's main API... API
rarely changes ...it is like specifications such as SOAP , BPEL ... there
are not chnaging every time ... if it is needed changes , then after a
compreshsive analysis of the use of existing one , it's pitfall , strength ,
an expert group create a new version of the specification. Our expert
grough is our community. So we have to create a comprehensive specifciation
for endpoint which can be live considerble long time without requiring any
changes.
Thanks
Indika
Re: Making loadbalance/failover configuration more convenient
Posted by Supun Kamburugamuva <su...@gmail.com>.
On Fri, Apr 30, 2010 at 10:00 PM, indika kumara <in...@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. 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 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>
>
> 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 …
>
>
+ 1 for the idea. I was thinking in the same lines. If we make the suffix
dynamic we can deprecate the DefaultEndpoint.
I'm not that comfortable with the configuration. But configuration is
something we can always improve and get to a common ground. But I like the
idea.
Thanks,
SUpun..
> Thanks
>
> Indika
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
Re: Making loadbalance/failover configuration more convenient
Posted by indika kumara <in...@gmail.com>.
+ for adhering to standards
Thanks
Indika
On Sat, May 1, 2010 at 11:55 PM, Supun Kamburugamuva <su...@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 <in...@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
>
>
>
Re: Making loadbalance/failover configuration more convenient
Posted by indika kumara <in...@gmail.com>.
Based on my conscience, I prefer the element ... and
[uri=""] | [uri-expression="${protocol}://${host}[:${port}][${path}]"] |
[path-regex="regex"]/
When I saw the above content. I just noticed that there is a little bit
redundancy in uri, path, etc … So , I just researched for finding
information on XML element vs attribute as I did not have good knowledge
with the XML based language design. Based on those, I feel that the element
is more suitable [the article itself describe many reasons]. I had also
read some information in DSL some time earlier… based on those , a correctly
used element can make a language API fluent than an attribute and make more
friendly for a user. E.g.
<man>
<eat>rice </eat>
</man>
Vs
<man action=”eat” value=”rice”/>
I always prefer the first one as a user and may be like the second one as a
developer.
BTW, I am not (-) on the attribute if many one like it.
Thanks
Indika
Re: Making loadbalance/failover configuration more convenient
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
On Wed, May 5, 2010 at 10:03 AM, Supun Kamburugamuva <su...@gmail.com>wrote:
>
>
> On Wed, May 5, 2010 at 10:01 AM, Supun Kamburugamuva <su...@gmail.com>wrote:
>
>>
>>
>> On Tue, May 4, 2010 at 11:02 PM, indika kumara <in...@gmail.com>wrote:
>>
>>>
>>>
>>> On Tue, May 4, 2010 at 10:46 PM, Supun Kamburugamuva <su...@gmail.com>wrote:
>>>
>>>>
>>>>
>>>> On Mon, May 3, 2010 at 7:42 PM, indika kumara <in...@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..
>>>>
>>>
>>> I did not care that ... I just told that an element is more suitable than
>>> an attribute for URI based on an article from an XML expert.
>>>
>>> I'm +1 for an uri attribute and a uri element :)
>>
>> May be I'm bit confusing in my above comment. I'm +1 for attribute
> approach as well as uri element approach. Either approach is fine with me.
>
Either approach is fine. But I think we should only support one, not both.
Thanks,
Hiranya
>
> Thanks,
> Supun..
>
>
>> Thanks,
>> Supun..
>>
>>
>>> BTW , seems you are correct..
>>>
>>> Thanks
>>>
>>> Indika
>>>
>>
>>
>>
>> --
>> Software Engineer, WSO2 Inc
>> http://wso2.org
>> supunk.blogspot.com
>>
>>
>>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>
--
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
Re: Making loadbalance/failover configuration more convenient
Posted by Supun Kamburugamuva <su...@gmail.com>.
On Wed, May 5, 2010 at 10:01 AM, Supun Kamburugamuva <su...@gmail.com>wrote:
>
>
> On Tue, May 4, 2010 at 11:02 PM, indika kumara <in...@gmail.com>wrote:
>
>>
>>
>> On Tue, May 4, 2010 at 10:46 PM, Supun Kamburugamuva <su...@gmail.com>wrote:
>>
>>>
>>>
>>> On Mon, May 3, 2010 at 7:42 PM, indika kumara <in...@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..
>>>
>>
>> I did not care that ... I just told that an element is more suitable than
>> an attribute for URI based on an article from an XML expert.
>>
>> I'm +1 for an uri attribute and a uri element :)
>
> May be I'm bit confusing in my above comment. I'm +1 for attribute approach
as well as uri element approach. Either approach is fine with me.
Thanks,
Supun..
> Thanks,
> Supun..
>
>
>> BTW , seems you are correct..
>>
>> Thanks
>>
>> Indika
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
Re: Making loadbalance/failover configuration more convenient
Posted by Supun Kamburugamuva <su...@gmail.com>.
On Tue, May 4, 2010 at 11:02 PM, indika kumara <in...@gmail.com>wrote:
>
>
> On Tue, May 4, 2010 at 10:46 PM, Supun Kamburugamuva <su...@gmail.com>wrote:
>
>>
>>
>> On Mon, May 3, 2010 at 7:42 PM, indika kumara <in...@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..
>>
>
> I did not care that ... I just told that an element is more suitable than
> an attribute for URI based on an article from an XML expert.
>
> I'm +1 for an uri attribute and a uri element :)
Thanks,
Supun..
> BTW , seems you are correct..
>
> Thanks
>
> Indika
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
Re: Making loadbalance/failover configuration more convenient
Posted by indika kumara <in...@gmail.com>.
On Tue, May 4, 2010 at 10:46 PM, Supun Kamburugamuva <su...@gmail.com>wrote:
>
>
> On Mon, May 3, 2010 at 7:42 PM, indika kumara <in...@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..
>
I did not care that ... I just told that an element is more suitable than an
attribute for URI based on an article from an XML expert.
BTW , seems you are correct..
Thanks
Indika
Re: Making loadbalance/failover configuration more convenient
Posted by Ruwan Linton <ru...@gmail.com>.
On Tue, May 4, 2010 at 10:16 PM, Supun Kamburugamuva <su...@gmail.com>wrote:
>
>
> On Mon, May 3, 2010 at 7:42 PM, indika kumara <in...@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.
>
No supun, we special case the uri-expression, basically we can extract the
stuff from the current To header and replace them on the address after
applying the optional regular expressions.
The above syntax needs to be able to have regular expressions within the
${path} and so forth.
Thanks,
Ruwan
>
> 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 <ru...@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 <su...@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
>
>
>
--
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
Re: Making loadbalance/failover configuration more convenient
Posted by Supun Kamburugamuva <su...@gmail.com>.
On Mon, May 3, 2010 at 7:42 PM, indika kumara <in...@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 <ru...@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 <su...@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 <in...@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
Re: Making loadbalance/failover configuration more convenient
Posted by indika kumara <in...@gmail.com>.
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 <ru...@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 <su...@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 <in...@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
>
Re: Making loadbalance/failover configuration more convenient
Posted by Ruwan Linton <ru...@gmail.com>.
+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 <su...@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 <in...@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
Re: Making loadbalance/failover configuration more convenient
Posted by Supun Kamburugamuva <su...@gmail.com>.
On Fri, Apr 30, 2010 at 10:21 AM, Hiranya Jayathilaka
<hi...@gmail.com>wrote:
> Hi Indika,
>
> On Fri, Apr 30, 2010 at 10:00 PM, indika kumara <in...@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
Re: Making loadbalance/failover configuration more convenient
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Indika,
On Fri, Apr 30, 2010 at 10:00 PM, indika kumara <in...@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.
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
Re: Making loadbalance/failover configuration more convenient
Posted by indika kumara <in...@gmail.com>.
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. 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 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>
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
Re: Making loadbalance/failover configuration more convenient
Posted by Supun Kamburugamuva <su...@gmail.com>.
Hi,
I like the idea of Miyuru suggested. Previously I was thinking about
introducing a expression to the Address endpoint URI. The idea was to
construct the out going URI using other mediators, for example like property
mediator or a URL rewrite mediator (like the one suggested by Hiranya).
But since having the Host part fixed is a good thing for a Endpoint URL I
guess the suggested approach would work nicely.
I would like to point to another approach as well.
Since most of the time we have a dynamic second part of the URL we can make
it a separate attribute of the Address Endpoint.
<address uri="first part" [query-expression="Synapse Expression"
query="Static Query"]/>
Thanks,
Supun..
On Fri, Apr 30, 2010 at 7:57 PM, Hiranya Jayathilaka
<hi...@gmail.com>wrote:
> Hi Miyuru,
>
> On Thu, Apr 29, 2010 at 5:44 PM, Miyuru <mi...@gmail.com> wrote:
>
>> Hi all,
>>
>> This mail is regarding https://issues.apache.org/jira/browse/SYNAPSE-567.
>> Currently when we defining leaf endpoints of loadbalance/failover endpoint
>> we have to explicitly define full url of the endpoint.
>> However in most loadbalance/failover scenarios endpoints are like
>> {IP_X}:{PORT_A}/services/MyService
>> {IP_Y}:{PORT_B}/services/MyService
>> {IP_Z}:{PORT_C}/services/MyService
>>
>> Proposed solution is, configure addresss endpoint like this
>>
>> <endpoint>
>> <address uri="https://localhost:8852/$INCOMING_URL_PATH">
>> </address>
>> </endpoint>
>>
>>
> I'm not convinced that this approach makes it 'easier' to configure a load
> balance endpoint. From the user perspective the user has to repeatedly
> specify the string '$INCOMING_URL_PATH' in the address endpoints instead of
> 'services/MyService'.
>
> And besides we currently have a very clean design for endpoints.They simply
> represent EPRs to which messages can be sent to - and that's all they do.
> IMO message processing logic such as URL rewriting should be done
> separately. May be what we are looking for is a URL rewrite mediator which
> can deal with regular expressions and URL rewrite rules. Such a mediator
> should provide access to the segments of the original URL through
> expressions such as ${host}, ${port}, ${path} etc. Then one can do a simple
> URL rewrite as follows:
>
> <URLRewrite expression="${protocol}://some.host:8080/${path}"/>
> <send/>
>
> Now this is a more generic thing that we can use anywhere in the Synapse
> configuration (sequences, proxies etc).
>
> Thanks,
> Hiranya
>
>
>> and replace path of the url ("services/MyService") with $INCOMING_URL_PATH.
>> Is this a proper solution? Else we can upgrade default endpoint to rewrite
>> address using regular expression which is more flexible solution.
>>
>> Any ideas?
>>
>> Thanks,
>> --
>> Miyuru Daminda Wanninayaka
>> Software Engineer - WSO2 Inc.
>>
>
>
>
> --
> 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
Re: Making loadbalance/failover configuration more convenient
Posted by Miyuru <mi...@gmail.com>.
Hi Hiranya,
On Fri, Apr 30, 2010 at 7:57 PM, Hiranya Jayathilaka
<hi...@gmail.com>wrote:
> Hi Miyuru,
>
> On Thu, Apr 29, 2010 at 5:44 PM, Miyuru <mi...@gmail.com> wrote:
>
>> Hi all,
>>
>> This mail is regarding https://issues.apache.org/jira/browse/SYNAPSE-567.
>> Currently when we defining leaf endpoints of loadbalance/failover endpoint
>> we have to explicitly define full url of the endpoint.
>> However in most loadbalance/failover scenarios endpoints are like
>> {IP_X}:{PORT_A}/services/MyService
>> {IP_Y}:{PORT_B}/services/MyService
>> {IP_Z}:{PORT_C}/services/MyService
>>
>> Proposed solution is, configure addresss endpoint like this
>>
>> <endpoint>
>> <address uri="https://localhost:8852/$INCOMING_URL_PATH">
>> </address>
>> </endpoint>
>>
>>
> I'm not convinced that this approach makes it 'easier' to configure a load
> balance endpoint. From the user perspective the user has to repeatedly
> specify the string '$INCOMING_URL_PATH' in the address endpoints instead of
> 'services/MyService'.
>
> And besides we currently have a very clean design for endpoints.They simply
> represent EPRs to which messages can be sent to - and that's all they do.
> IMO message processing logic such as URL rewriting should be done
> separately. May be what we are looking for is a URL rewrite mediator which
> can deal with regular expressions and URL rewrite rules. Such a mediator
> should provide access to the segments of the original URL through
> expressions such as ${host}, ${port}, ${path} etc. Then one can do a simple
> URL rewrite as follows:
>
> <URLRewrite expression="${protocol}://some.host:8080/${path}"/>
> <send/>
>
> Now this is a more generic thing that we can use anywhere in the Synapse
> configuration (sequences, proxies etc).
>
>
I agree with you. URL rewrite mediator will be a proper solution for this.
> Thanks,
> Hiranya
>
>
>> and replace path of the url ("services/MyService") with $INCOMING_URL_PATH.
>> Is this a proper solution? Else we can upgrade default endpoint to rewrite
>> address using regular expression which is more flexible solution.
>>
>> Any ideas?
>>
>> Thanks,
>> --
>> Miyuru Daminda Wanninayaka
>> Software Engineer - WSO2 Inc.
>>
>
>
>
> --
> 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
>
--
Miyuru Daminda Wanninayaka
Software Engineer - WSO2 Inc.
Re: Making loadbalance/failover configuration more convenient
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Miyuru,
On Thu, Apr 29, 2010 at 5:44 PM, Miyuru <mi...@gmail.com> wrote:
> Hi all,
>
> This mail is regarding https://issues.apache.org/jira/browse/SYNAPSE-567.
> Currently when we defining leaf endpoints of loadbalance/failover endpoint
> we have to explicitly define full url of the endpoint.
> However in most loadbalance/failover scenarios endpoints are like
> {IP_X}:{PORT_A}/services/MyService
> {IP_Y}:{PORT_B}/services/MyService
> {IP_Z}:{PORT_C}/services/MyService
>
> Proposed solution is, configure addresss endpoint like this
>
> <endpoint>
> <address uri="https://localhost:8852/$INCOMING_URL_PATH">
> </address>
> </endpoint>
>
>
I'm not convinced that this approach makes it 'easier' to configure a load
balance endpoint. From the user perspective the user has to repeatedly
specify the string '$INCOMING_URL_PATH' in the address endpoints instead of
'services/MyService'.
And besides we currently have a very clean design for endpoints.They simply
represent EPRs to which messages can be sent to - and that's all they do.
IMO message processing logic such as URL rewriting should be done
separately. May be what we are looking for is a URL rewrite mediator which
can deal with regular expressions and URL rewrite rules. Such a mediator
should provide access to the segments of the original URL through
expressions such as ${host}, ${port}, ${path} etc. Then one can do a simple
URL rewrite as follows:
<URLRewrite expression="${protocol}://some.host:8080/${path}"/>
<send/>
Now this is a more generic thing that we can use anywhere in the Synapse
configuration (sequences, proxies etc).
Thanks,
Hiranya
> and replace path of the url ("services/MyService") with $INCOMING_URL_PATH.
> Is this a proper solution? Else we can upgrade default endpoint to rewrite
> address using regular expression which is more flexible solution.
>
> Any ideas?
>
> Thanks,
> --
> Miyuru Daminda Wanninayaka
> Software Engineer - WSO2 Inc.
>
--
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