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
