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.
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
