+ for adhering to standards Thanks
Indika On Sat, May 1, 2010 at 11:55 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 > > >
