On Tue, May 4, 2010 at 10:16 PM, Supun Kamburugamuva <[email protected]>wrote:
> > > 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. > 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 <[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 > > > -- 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
