>I am afraid that I am not following this discussion. I would appreciate
>some clarifiaction, if you don't mind. It appears to me that Imre is
>claiming that the Java 2 Platform security model allows you to violate
>the encapsulation features that are specified in the Java Language
>Specification.
>
>Are you saying that you can take a class like this:
>
>public class Foo
>{
> private String id;
> public String somethingElse;
>
> public void setSomethingElse( String s )
> {
> somethingElse = s;
> }
>
> ...
>}
>
>and through some security policy setting be able to manipulate the "id"
>String? I'm either grossly misunderstanding your point or else you'll
>have to show me where this mechanism is described.
CMP can be implemented through the use of the reflection mechanism (standard
in both Java 1.1 and 2) that allow the server to get/set fields and call
methods on beans and objects for which the class was not known at (server)
compilation time. You may want to check out the reflection API for more
details.
Only public fields are settable in Java 1.1 reflection. Java 2 extends the
capabilities of reflection by allowing the modification of private fields as
well. To keep this feature safe, all modifications are subject to access
control checks and can only happen in a privileged security context. You
should check out the security architecture in Java 2 for more details.
Without making this too long, a Java2-based server can provide CMP on bean
instances in privileged calls without requiring the bean developer to open
up private parts of the beans or primary keys (PKs). Realizing, of course,
that only server specific calls would be privileged in a running EJB server.
The advantage of this is that your beans and, more importantly, your PKs are
all protected from other beans or java objects while you still enjoy full
CMP support. This cannot be achieved with a Java 1.1 implementation.
>I also do not understand what "abstraction features that EJB effectively
>disables." How is abstraction affected by EJB? You might argue that
>encapsulation is affected, but I would argue against that stance as
>well. Once an EJB in instanciated, there is no valid way of getting a
>direct reference to that object. All access is through the EJBObject
>which acts as the EJB's interface. THe only other class type that has
>access to the class members is a subclass of the EJB class. In the case of
>the subclass, there is a loss of encapsulation in that the superclass
>cannot hide its persistent data from the sunclass.
The point of EJB is to make component development and reuse a reality. As
soon as you are reusing beans, you want to hide the implementation details
of your super classes (beans).
The current EJB spec requires that all beans and PKs that are managed by the
container have all their persistent (important :-) fields declared public
and non-final. This also means that any other bean or java code can modify
any PK they can access without the designer or developer having any control
over the modifications (this doesn't apply if all arguments are passed by
value internally in the server, which is prohibitive from a performance
point of view).
If you think about the entity architecture in EJB, it is essentially
centered around PKs. It is very easy to access the PK of any EJBObject (or
bean instance). Moreover, finding objects by their PKs is a required
fundamental feature. If you accidentally modify a field of a referenced PK
you can easily break the uniqueness requirement of PKs or you can make
objects "disappear" which can affect the underlying database in very hard to
trace ways. In one word, one accidental field modification (from a possible
long forgotten hack or rogue bean) can bring your carefully crafted system
to its knees for no obvious reason.
>Please let me know where I've misunderstood.
>
>Imre Kifor wrote:
>>
>> That is absolutely true. The problem is that you are also using Java that
>> provides very important abstraction features that EJB effectively
disables.
>> As soon as your project becomes more than trivial, these abstraction
>> features become crucial in software maintenance. Think about the second
wave
>> of developers that come into a project and have to figure out how to
>> fix/extend already existing code. That is the time when hiding details is
>> not just necessary but absolutely required. EJB will not be widely
adopted
>> if these features that have become a very important characteristic of all
>> object-oriented languages are disabled. This is not a question of
>> compatibility. IMHO, having non-final public fields in your PKs is a
>> disaster waiting to happen. And that is not good for EJB.
>>
>> From: Richard Monson-Haefel <[EMAIL PROTECTED]>
>>
>> >If you are going to build Enterprise JavaBeans and have not settled on a
>> EJB
>> >server, you better stick to using public fields for both primary keys
and
>> >the bean classes themselves. Not all EJB servers support the Java 2
>> >platform.
>> >
>> >From: Imre Kifor
>> >
>> >Actually, on the Java 2 platform, the requirement for public PK fields
>> >can
>> >(and should) be relaxed. Having enough security privileges, a server can
>> >inspect/set private fields. The same applies to CMP beans. Exposing
>> >fields
>> >that otherwise should be private will just cause confusion, errors and
>> >misuse.
>
>--
>Michael S. Jenkins | Abstract Data Types in Java
>Jenkins Consulting Services, Inc | Michael S Jenkins / McGraw Hill
>[EMAIL PROTECTED] | ISBN 0-07-913270-7
>[EMAIL PROTECTED] | Get the book through my web site
>http://www.wwa.com/~mjenkins <<<<-- in association with Amazon.com
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
