Agreed. This is a tricky issue. There are two fundamentally different
ways to deal with this:
1. Choose a small number of buckets (e.g., DAS, instance) and dump all
functionality into one or both buckets. (This is what we do currently)
or
2. Group functions into some larger number of "roles", possibly with the
number of roles approaching the number of functions. In this case, the
roles are oriented towards the function like what you suggest below
("can deploy to domain") rather than being types of servers. And then
define server types based on these roles. Thus the individual functions
have no concept at all of the type of the server, and different
variations of the server can be created by just choosing different roles.
This latter approach is much more difficult for several reasons:
a. A better understanding of the dependencies and interrelationships
between functions is needed in order to choose roles.
b. It is difficult to test all of the various combinations of different
roles and that server can take on.
For now, I'm assuming we are going to continue along path #1.
Tom
On 4/21/2011 3:19 PM, Tim Quinn wrote:
> Tom,
>
> As you alluded to earlier, I think, we will need to be a little
> cautious in how we deal with this. There are probably various aspects
> of server behavior that, up until now, have been grouped into "DAS"
> vs. "non-DAS." Various bits of code which use xxx.isDas() or other
> techniques might actually be interested in different of these aspects.
>
> For example, is this server capable of deploying an app? While in the
> past only the DAS could do that, there could be ways in which that is
> relaxed going forward so non-DAS servers might be able deploy apps -
> although perhaps only to themselves rather than to the whole domain.
> So, in fact, perhaps some piece of code really needs to distinguish
> between "can deploy to domain" vs. "can deploy only to self."
>
> Ideally, we'd understand at each bit of code precisely what
> characteristic of DAS-ness or non-DAS-ness the code was really
> interested in and then expose that in some coherent way, whether it's
> on ServerEnvironment or in some other way.
>
> - Tim
>
> On Apr 21, 2011, at 3:09 PM, Hong Zhang wrote:
>
>> Hi, Tom
>> We have been using ServerEnvironment.isDas API, the underlying
>> implementation is checking the server type.
>>
>> - Hong
>>
>> On 4/21/2011 3:57 PM, Tom Mueller wrote:
>>> I've been looking into how a DAS determines that it's a DAS, and I'm
>>> seeing some different approaches:
>>>
>>> 1. Calling Server.isDas() - this method looks at the instance name;
>>> if it's "server" then return true.
>>>
>>> 2. Using the "-type" argument that is passed when the JVM is
>>> launched. start-domain passes in DAS, start-local-instance passes
>>> in INSTANCE.
>>>
>>> 3. Calling Server.getName() and doing the comparison to "server"
>>> directly, rather than calling isDas().
>>>
>>> Do you know of other ways that code determines whether it is running
>>> on the DAS?
>>>
>>> I'd like to move in the direction of consolidating this behavior, so
>>> that we have exactly one way of determining the role that the server
>>> is filling. Thoughts?
>>>
>>> Thanks.
>>> Tom
>>>
>