synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From indika kumara <indika.k...@gmail.com>
Subject Re: Generating Names for Anon. Endpoints
Date Tue, 04 May 2010 17:27:01 GMT
Ruwan


> but JMX management and error notifications like suspensions and so forth
> cannot be controlled if those endpoints are inlined in, say send mediator.
> The JMX management and all that are only possible for declared endpoint
>

I am not sure this ... I have not looked the endpoint code for a long
time..But as remind , It should just need a name and does not depend on
in-lined / declared


> The only enforcement that we can do to get rid of all that is to disable
> the ability to have inlined endpoints, but I am strongly -1 on this
> approach, since it reduces a usability a lot.
>
> Also, please note that we do not sacrifice correctness by any means hear,
> if we do this enforcement, we loose the usability and if we keep this as it
> is then again what we will loose is the usability, but the usability
> reduction on the first approach is huge with compared to doing this change.
>
> Hence, I am -1 on enforcing a name for inlined endpoints or disabling the
> ability to have inlined endpoints.
>
> Thanks,
> Ruwan
>
>
I also do not  like to remove in-lined endpoints.... but ....making endpoint
name mandatory brings advantages than disadvantages to a user even he may
not be aware at first time the importance of a meaningful name.

Thanks

Indika



> On Tue, May 4, 2010 at 5:22 PM, indika kumara <indika.kuma@gmail.com>wrote:
>
>> I too agree with supun ...
>>
>> The usability may depend on the answer for 'Why does a user like in-lined
>> configurations? '.  That is why I really needed a good answer from real
>> users...
>>
>> The correctness is come first and the most important quality attribute
>> than other quality attributes.   Irrespective of the criticality of the
>> operation that depends on the name of the endpoint, the operation should be
>> worked correctly. At least, if any operation that needs the name of the
>> endpoint is enabled, then we should validate the uniqueness of the endpoint
>> name.
>>
>> Thanks
>> Indika
>>
>> On Tue, May 4, 2010 at 12:06 PM, Supun Kamburugamuva <supun06@gmail.com>wrote:
>>
>>>
>>>
>>> On Sun, May 2, 2010 at 5:44 PM, Ruwan Linton <ruwan.linton@gmail.com>wrote:
>>>
>>>>
>>>>
>>>> On Sun, May 2, 2010 at 11:24 AM, Hiranya Jayathilaka <
>>>> hiranya911@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, May 1, 2010 at 11:23 PM, Supun Kamburugamuva <
>>>>> supun06@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Apr 30, 2010 at 10:08 AM, Hiranya Jayathilaka <
>>>>>> hiranya911@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Supun,
>>>>>>>
>>>>>>> On Fri, Apr 30, 2010 at 9:02 PM, Supun Kamburugamuva <
>>>>>>> supun06@gmail.com> wrote:
>>>>>>>
>>>>>>>> Sorry I'm bit late to the conversation. I think the proper
solution
>>>>>>>> would be to force the user to have a name for each and every
endpoint.
>>>>>>>
>>>>>>>
>>>>>>> I think we should be a little more flexible here. Most users
will
>>>>>>> appreciate the ability to define in-line endpoints anonymously.
It's a
>>>>>>> usability thing.
>>>>>>>
>>>>>>>
>>>>>> Here I'm not suggesting to remove the support for anonymous endpoints.
>>>>>> My suggestion was to force a name to every endpoint regardless of
weather
>>>>>> they are defined in-line or separately.
>>>>>>
>>>>>
>>>>> Supun, this is exactly what I think we shouldn't be doing. If we are
>>>>> forcing the user to define names for each and every endpoint, then we
are
>>>>> actually getting rid of the support for anonymous endpoints.
>>>>>
>>>>
>>>> +1
>>>>
>>>> We should try our best to keep the simple case as simple. Anonymous
>>>> endpoints are very usable from the users point of view, and at least 70-80%
>>>> of the users are not enabling clustering, if we are to enforce a name for
>>>> every endpoint regardless whether it is inlined or not, we are making the
>>>> simple case hard from the user point of view.
>>>>
>>>> My belief is doing the correct thing is important than the usability at
>>> least when the usability degradation is minimal. I think that is the exact
>>> reason why we are trying to make the synapse language schema compliant now.
>>>
>>> Also forcing a name for an inline endpoint is not that user un-friendly.
>>> To define an endpoint user has to do many things. So I think just including
>>> the name attribute is not a big user un-friendly thing compared to all the
>>> things user has to do already.
>>>
>>> My concerns about name generation are not only with clustering. Lets say
>>> an anonymous endpoint got suspended or received a time-out error. How can
>>> the user know which endpoint got suspended or received the error?
>>>
>>> Also lets say user wants to do JMX monitoring. How can he distinguish the
>>> different endpoints?
>>>
>>> I think synapse language should always force the production best
>>> practices and I think having a meaningful name to an endpoint is a
>>> production best practice that every deployment should do.
>>>
>>> Thanks,
>>> Supun..
>>>
>>>
>>>> Thanks,
>>>> Ruwan
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Hiranya
>>>>>
>>>>>
>>>>>>
>>>>>> Even now user can do this. But system doesn't enforce this, and we
>>>>>> have to generate a name. So my suggestion was to make the name attribute
of
>>>>>> the endpoint mandatory.
>>>>>>
>>>>>> Thanks,
>>>>>> Supun..
>>>>>>
>>>>>>
>>>>>>
>>>>>>> This is a best practice in a production deployment. The name
helps to
>>>>>>>> understand endpoint behavior. For example when an endpoint
is suspended user
>>>>>>>> cannot identify it easily if it doesn't have a name.
>>>>>>>
>>>>>>>
>>>>>>> +1... But it should only be a best practice. If the user does
not
>>>>>>> want to bother with endpoint management stuff then forcing him
to set names
>>>>>>> for each and every endpoint is not necessary (Needless to say,
a large
>>>>>>> config would have dozens and dozens of endpoints - so it's not
an easy job
>>>>>>> either). Also other than these management capabilities, names
of the in-line
>>>>>>> endpoints don't have any other usage either. You cannot refer
to them from
>>>>>>> other sequences etc using the specified name.
>>>>>>>
>>>>>>> If the problem is with clustering scenarios, they will work just
>>>>>>> fine, since we are generating names for unnamed, in-line endpoints.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Hiranya
>>>>>>>
>>>>>>>
>>>>>>>> So it is good if we can enforce this at the synapse level.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Supun...
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Apr 27, 2010 at 2:44 PM, Ruwan Linton <
>>>>>>>> ruwan.linton@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> Ruwan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Apr 27, 2010 at 10:55 AM, Hiranya Jayathilaka
<
>>>>>>>>> hiranya911@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Here's a little progress update. I have realized
that it is
>>>>>>>>>> difficult to generate descriptive and context sensitive
names for endpoints
>>>>>>>>>> on the fly. Reason is given an endpoint we cannot
determine it's parent. We
>>>>>>>>>> can do that for proxy services, but for sequences
it is almost impossible.
>>>>>>>>>> Therefore we will have to stick to the UUIDs at least
for the moment.
>>>>>>>>>>
>>>>>>>>>> However I was able to get the concept of endpoint
anonymity
>>>>>>>>>> implemented without changing the top level Endpoint
interface. All the
>>>>>>>>>> endpoint serializers work with the AbstractEndpoint
level, so I added the
>>>>>>>>>> necessary methods there. If the user hasn't explicitly
specified a name for
>>>>>>>>>> an endpoint it is considered anonymous. The system
will generate names for
>>>>>>>>>> such endpoints but they will not be displayed in
the serialization.
>>>>>>>>>>
>>>>>>>>>> I have raised SYNAPSE-627 to keep track of this.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Hiranya
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Apr 26, 2010 at 5:34 PM, Ruwan Linton <
>>>>>>>>>> ruwan.linton@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> +1
>>>>>>>>>>>
>>>>>>>>>>> Ruwan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Apr 26, 2010 at 5:28 PM, Hiranya Jayathilaka
<
>>>>>>>>>>> hiranya911@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Apr 26, 2010 at 5:04 PM, Ruwan Linton
<
>>>>>>>>>>>> ruwan.linton@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hiranya,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Lets introduce an internal flag to the
endpoint so that the
>>>>>>>>>>>>> builder and the serializer pair sets
and checks respectively to make the
>>>>>>>>>>>>> generated name transparent from the users
configuration.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To address the issue of having different,
UUID's on different
>>>>>>>>>>>>> server start sessions, we could compute
the endpoint name by looking at the
>>>>>>>>>>>>> parent sequence name, for example like
"main_ep_1" and so forth.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That makes sense. Shall we add following
two methods to the
>>>>>>>>>>>> Endpoint interface then?
>>>>>>>>>>>>
>>>>>>>>>>>> public boolean isAnonymous();
>>>>>>>>>>>> public void setAnonymous();
>>>>>>>>>>>>
>>>>>>>>>>>> Anonymous endpoints will also get a generated
name but that will
>>>>>>>>>>>> not be shown to the user in the serialization.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Hiranya
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Ruwan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Apr 26, 2010 at 4:52 PM, Hiranya
Jayathilaka <
>>>>>>>>>>>>> hiranya911@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Devs,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Currently Synapse generates names
for anonymous endpoints. For
>>>>>>>>>>>>>> an example take the following sequence:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <sequence name="foo">
>>>>>>>>>>>>>>     <send>
>>>>>>>>>>>>>>        <endpoint>
>>>>>>>>>>>>>>            <address uri="some
address"/>
>>>>>>>>>>>>>>        </endpoint>
>>>>>>>>>>>>>>     </send>
>>>>>>>>>>>>>> </sequence>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Synapse will generate a UUID and
set that as the name of the
>>>>>>>>>>>>>> endpoint. This is required since
all endpoints must have names in clustered
>>>>>>>>>>>>>> deployments. However generating names
causes the serialization to be
>>>>>>>>>>>>>> different from the original input
XML. As a result we currently have a bunch
>>>>>>>>>>>>>> of test failures in the trunk. Any
idea how to resolve this problem?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Hiranya Jayathilaka
>>>>>>>>>>>>>> Software Engineer;
>>>>>>>>>>>>>> WSO2 Inc.;  http://wso2.org
>>>>>>>>>>>>>> E-mail: hiranya@wso2.com;  Mobile:
+94 77 633 3491
>>>>>>>>>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Ruwan Linton
>>>>>>>>>>>>> Technical Lead & Product Manager;
WSO2 ESB;
>>>>>>>>>>>>> http://wso2.org/esb
>>>>>>>>>>>>>
>>>>>>>>>>>>> WSO2 Inc.; http://wso2.org
>>>>>>>>>>>>>  email: ruwan@wso2.com; cell: +94 77
341 3097
>>>>>>>>>>>>> blog: http://ruwansblog.blogspot.com
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Hiranya Jayathilaka
>>>>>>>>>>>> Software Engineer;
>>>>>>>>>>>> WSO2 Inc.;  http://wso2.org
>>>>>>>>>>>> E-mail: hiranya@wso2.com;  Mobile: +94 77
633 3491
>>>>>>>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Ruwan Linton
>>>>>>>>>>> Technical Lead & Product Manager; WSO2 ESB;
http://wso2.org/esb
>>>>>>>>>>> WSO2 Inc.; http://wso2.org
>>>>>>>>>>> email: ruwan@wso2.com; cell: +94 77 341 3097
>>>>>>>>>>> blog: http://ruwansblog.blogspot.com
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Hiranya Jayathilaka
>>>>>>>>>> Software Engineer;
>>>>>>>>>> WSO2 Inc.;  http://wso2.org
>>>>>>>>>> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
>>>>>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ruwan Linton
>>>>>>>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>>>>>>>> WSO2 Inc.; http://wso2.org
>>>>>>>>> email: ruwan@wso2.com; cell: +94 77 341 3097
>>>>>>>>> blog: http://ruwansblog.blogspot.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Software Engineer, WSO2 Inc
>>>>>>>> http://wso2.org
>>>>>>>> supunk.blogspot.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Hiranya Jayathilaka
>>>>>>> Software Engineer;
>>>>>>> WSO2 Inc.;  http://wso2.org
>>>>>>> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
>>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Software Engineer, WSO2 Inc
>>>>>> http://wso2.org
>>>>>> supunk.blogspot.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Hiranya Jayathilaka
>>>>> Software Engineer;
>>>>> WSO2 Inc.;  http://wso2.org
>>>>> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ruwan Linton
>>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>>> WSO2 Inc.; http://wso2.org
>>>> email: ruwan@wso2.com; 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: ruwan@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>

Mime
View raw message