Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Programing Restriction - SCBCD Objective 1.3

 
Paulina Paul
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I have a question.

As per SCBCD Study kit , In the Programming Restriction section ,(SCBCD Objective 1.3), I found this restriction. From Inside the bean, never use the object substitution or subclass feature of Java Serialisation Protocol.

What does this mean exactly?

-Paulina.
[ March 31, 2006: Message edited by: Paulina Paul ]
 
Frederic Esnault
Ranch Hand
Posts: 284
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Paulina !

Quite a tricky point you have here. But don't worry, the explanation is quite simple and refers to powerful features of the Java Serialization protocol. Of course in the case of EJB, these features may be extremely dangerous and make your beans EJB outlaws !

First thing, the simplest one, the "subclass thing". This is basically the same as the ClassLoader thing. This just states that an EJB does NOT have the right to provide a subclass of the ObjectInputStream/ObjectOutputStream to the system, exactly like it cannot replace the ClassLoader. The problem is that once you subclass ObjectInputStream, you may write different readObject() method to suit your need and, say, modify some field values as soon as you read them, before the actual read object is returned.

Why is this dangerous? Because the RMI protocol is based on serialization for marshalling/unmarshalling of objects (write an object on the network stream and get it back at the other end). The whole EJB remote system expects this communication to be data-preserving. Which means data sent must arrive exactly in the same state. If you mess with the ObjectInputStream reader and modify the read object, the whole system is not secure anymore.

Now, the second point, a little more tricky if you don't know the Serialization Protocol.

When you use objects in your remote communications, a nice thing is to declare them as Serializable. When you do this, you may do something with the serialization protocol : define a readResolve() method.

What the ?%*! is this method? It simply allows to replace the read object with another one during the deserialization process. Which means you receive a completely different object as the one written on the other side ofthe network.

For information, this method is mostly used when you deal with an object that MUST be unique in your system. SO when you deserialize this unique object, if you already have an instance in memory, use the readResolve method to replace the object you're reading by the already existing object, and your uniqueness is preserved (kinda like a Factory/Singleton design pattern pair).

This, obviously, is unacceptable in the EJB law !

Hope it's a bit clearer now.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic