[jboss-dev-forums] [Design of the JBoss EJB Container] - Question about Remoting, Marshalling, and EJBs

[ron.sigal@jboss.com]

I'm looking at an old Remoting issue, JBREM-167 "RMI Invoker does not use true remoting marshalling/unmarshalling" and I have a question.  This issue concerns the Remoting RMI transport, which, as an alternative to the more commonly used "socket" transport, makes invocations using Java RMI.  If the "jboss.remoting:service=Connector,transport=socket" Connector in conf/jboss-service.xml were configured to use the RMI tranport, then EJB2 calls would be transported by Java RMI.

Currently, the RMI transport uses org.jboss.invocation.unified.marshall.InvocationMarshaller to marshal invocations on the client side and org.jboss.invocation.unified.marshall.InvocationUnMarshaller to unmarshal invocations on the server side.  Their main function, other than serializing and deserializing the invocation, is to add and remove transaction context information:


  |    // From InvocationMarshaller:
  | 
  |    public Object addDecoration(Object dataObject) throws IOException {
  |         if(dataObject instanceof InvocationRequest)
  |         {
  |            InvocationRequest remoteInv = (InvocationRequest) dataObject;
  | 
  |            if(remoteInv.getParameter() instanceof Invocation)
  |            {
  |               Invocation inv = (Invocation) remoteInv.getParameter();
  | 
  |               MarshalledInvocation marshInv = new MarshalledInvocation(inv);
  | 
  |               if(inv != null)
  |               {
  |                  // now that have invocation object related to ejb invocations,
  |                  // need to get the possible known payload objects and make sure
  |                  // they get serialized.
  | 
  |                  try
  |                  {
  |                     marshInv.setTransactionPropagationContext(getTransactionPropagationContext());
  |                  }
  |                  catch(SystemException e)
  |                  {
  |                     log.error("Error setting transaction propagation context.", e);
  |                     throw new IOException("Error setting transaction context.  Message: " + e.getMessage());
  |                  }
  | 
  |                  // reset the invocation parameter within remote invocation
  |                  remoteInv.setParameter(marshInv);
  |               }
  |               else
  |               {
  |                  //Should never get here, but will check anyways
  |                  log.error("Attempting to marshall Invocation but is null.  Can not proceed.");
  |                  throw new IOException("Can not process data object due to the InvocationRequest's parameter being null.");
  |               }
  | 
  |            }
  |         }
  |         return dataObject;
  |     }
  | 

and


  |    // From InvocationUnMarshaller:
  | 
  |     public Object removeDecoration(Object obj) throws IOException
  |     {
  |         if(obj instanceof InvocationRequest)
  |         {
  |            InvocationRequest remoteInv = (InvocationRequest) obj;
  |            Object param = remoteInv.getParameter();
  | 
  |            if(param instanceof MarshalledInvocation)
  |            {
  |               MarshalledInvocation mi = (MarshalledInvocation) param;
  |               Object txCxt = mi.getTransactionPropagationContext();
  |               if(txCxt != null)
  |               {
  |                  TransactionPropagationContextImporter tpcImporter = TransactionPropagationContextUtil.getTPCImporter();
  |                  mi.setTransaction(tpcImporter.importTransactionPropagationContext(txCxt));
  |               }
  |            }
  |         }
  |         return obj;
  |     }
  | 

On the other hand, when the server returns a response, no marshalling is performed on the server side and no unmarshalling is performed on the client side: the response is passed directly to the RMI runtime.  The point of JBREM-167 is to change the RMI server invoker to use a configured marshaller and to change the RMI client invoker to use a configured unmarshaller.  This way, someone could interpose, for example, encrypting or compressing marshaller/unmarshallers, which is not currently possible.  

My questions:

1. Does anyone care about having this feature?

2. This change would mean that the InvocationMarshaller would be used on the server side when returning a response and InvocationUnMarshaller would be used on the client side to unmarshal the response. Would adding and removing transaction context in the server-to-client direction have any implications?

3. Since EJB3 handles transaction information in an interceptor and doesn't, by default, configure any marshaller or unmarshaller, am I right that this issue is irrelevant to EJB3?

Thanks,
Ron

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135118#4135118

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135118