On Mon, May 3, 2010 at 7:42 PM, indika kumara <[email protected]> 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 <[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
>>
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
