On Tue, May 4, 2010 at 9:55 PM, indika kumara <indika.k...@gmail.com> wrote:
> What makes you think the current approach for endpoints is 'incorrect'? If >> it is not correct then that indeed is a problem we should get fixed >> > > Hiranja > > As currently, we generate a random one (so unique), therefore the internal > operation is correct as far as users do not specify a name. However, as > users also specified names if we do not validate names, we cannot grantee > the uniqueness. Indika, we generate UUIDs for endpoint names. So it is unique :) > (As per my knowledge, we do not validate names for in-lined endpoints... I > did not check code … so... I may be wrong)… Therefore, there is a > possibility for incorrect operation. > > On the other hand, the generated name does not represent any context > information such as for what this endpoint is (The ‘server1.foo’ the > endpoint for the service ‘foo’ in the server 1). We cannot generate such a > meaningful name… > > On the other hand, in synapse even if you have generated internally a name > for an endpoint, the end user does not know it. There is no tool for viewing > names of endpoints. Then the name will become another internal thing that > uses for the correct operation of endpoints and from the user perspective, > he cannot easily use it for diagnosing any errors, JMS monitoring, etc. > (Currently, Name is not for users but for our internal working). If the user wants to do these stuff it is up to him to give a name to the endpoints. Most users won't be doing these things so the system should not enforce that. The biggest issue I have with enforcing this is, the name of an in-lined endpoint means nothing at the SynapseConfiguration level. You cannot access an in-lined endpoint from a different sequence or a proxy using its name. Also they don't even have to be unique :( So this actually makes our model 'incorrect'. We have top level endpoints, which are globally accessible using their names and we have in-lined endpoints which are not globally accessible using the names. The behavior of endpoint names start to change according to the context, which is wrong. So in that sense our current approach is correct. Top level endpoints must be given a name and they are accessible everywhere. In-lined endpoints does not have to have a name. We generate a name internally for clustering stuff to work but it is completely transparent to the user. If the user wants to reuse endpoint configurations or manage endpoints, define a top level endpoint and refer to it using the name. Thanks, Hiranya > A named entity is used by a user to separate a particular entity from > others entities in both configurations and runtime data. In synapse, > Statistics (JMX) is one … JMS monitoring is another, error log analyzing is > another one… However, the clustering is not. It is an internal operation. > For such an internal operation, generating a name or id is perfectly OK as > it is not for users. Name is for users …. Internally generated ID is for > internal operations. > > That is why I would like, at least for any operations that require an > endpoint name, to warn (at latest) users if there is no name has been > specified. > > Making the name mandatory will be too good as it brings more advantages for > users than disadvantages. > > A user will only recognize the importance of a context aware meaningful > name, when things go wrong and he need to identify the error based on the > information in the logs. …If it was a very random issue and cannot be easily > reproduced, what kind of feeling will he feel? … I believe, after that day, > we will put names carefully – not just a unique name but meaningful … > > Thanks > Indika > > > -- Hiranya Jayathilaka Software Engineer; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
