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 <[email protected]> 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 <[email protected]>wrote:
>
>>
>>
>> On Fri, Apr 30, 2010 at 10:21 AM, Hiranya Jayathilaka <
>> [email protected]> wrote:
>>
>>> Hi Indika,
>>>
>>> On Fri, Apr 30, 2010 at 10:00 PM, indika kumara
>>> <[email protected]>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: [email protected]; 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: [email protected]; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>
