Considerations for developing SCA applications using EJB bindings

Considerations for developing SCA applications using EJB bindings

When developing Service Component Architecture (SCA) applications that you intend to use with EJB bindings, keep in mind that the SCA EJB binding is architected in a Java-centric manner, in contrast to the XML-centric implementations of the SCA default binding and the SCA web services binding.
The EJB transports marshal and unmarshal application data into the wire format by using Java serialization, whereas the web services and default bindings use XML serialization. This difference also affects the programming model in that the SCA clients and implementations using the EJB binding must use java.io.Serializable types, in contrast to the JAXB data types-based programming model used for the SCA default and web services bindings.

SCA reference

In this case, we have an existing EJB to invoke with an SCA client using a reference configured with an EJB binding.
When you develop an SCA client that will invoke an existing EJB using the SCA EJB binding, use a Java interface when developing the SCA client rather than using a WSDL interface. The EJB binding marshalling of application data into the wire data format is performed using Java serialization, not XML serialization as defined by JAXB.
To learn more about SCA references, read about developing SCA service clients. However, when we are using the SCA EJB binding, the information in this topic takes precedence.
Because you obtain the Java interface and parameter types from the EJB provider for use in the client, we do not have to worry about the effects of marshalling and unmarshalling when writing the client. However, when you provide these data types across new services, problems can occur if you pass these data types across new services, because they might not serialize correctly over other bindings, such as the default binding, because of the difference in Java serialization and the JAXB XML marshalling and unmarshalling.
Example problematic scenario of starting with an existing EJB interface and using a Java serializable data type that does not serialize well using JAXB marshalling and unmarshalling.
public interface NameService extends javax.ejb.EJBObject {

    public String computeName(Person p) throws RemoteException;
}
// This snippet is intended as an example of a type that is problematic.  
public class Person implements java.io.Serializable {

    private int code;
    private String name;

    // The code field must be passed into constructor.  However, this causes problems for 
    // for SCA default and web services bindings that use JAXB marshalling/unmarshalling.   

    public Person(int code) {
        this.code = code;
    }

    public Person() {
    }

    public String getName() {
        return name;
    }

    public void setName(String value) {
        this.name = value;
    }

}
The following SCA client A example works correctly. The Person object that is instantiated directly in the ClientAImpl implementation is correctly marshalled to invoke the EJB with a remote interface of NameService.
// Client A  ClientAImpl.java
 ..
@Reference
public NameService nameService

public someClientMethod() {
    // No problem when Person object is instantiated by client     Person person = new Person(5);
    String name = nameService.computeName(person);
}
In contrast, the following example demonstrates the problem with the Person type. The client code has been refactored so that it contains a reference to NameService, and it obtains the Person object that is passed into the computeName method over a new remotable interface, rather than constructing it directly.
// Problem client interface  

import org.osoa.sca.annotations.Remotable;
@Remotable
public interface PersonFilter {
     boolean filterPerson(Person p);
}


// Problem client implementation  

@Service(PersonFilter.class)
public class PersonFilterImpl implements PersonFilter {
     @Reference
     public NameService nameService

     boolean filterPerson(Person p) {
     //   business logic     String name = nameService.computeName(person);
     //   business logic      }
}
If the PersonFilterImpl class receives a Person object from the client over the PersonFilter interface and the implementation is invoked using the SCA default binding, the data is not handled correctly. The default binding does not preserve the code field of the Person object that is passed to the PersonFilterImpl class.
For a class without JAXB annotations, JAXB marshalling and unmarshalling preserves JavaBeans properties, but not private data such as the code field, which does not have a setter and is only established in the constructor. When the Person object is passed to the NameService EJB, the code value is set to the default value of 0 regardless of what the PersonFilter client passed to the PersonFilterImpl class.
If the Person type was written in the JavaBeans style with getters and setters for all important data, then this type works correctly in the example for the PersonFilterImpl client. However, if you are consuming an existing EJB, we do not have control over the types it already uses on its interface. Not all existing Java types are optimal for SCA Java programming. To address the problems in this example, create a new type for use on the PersonFilter interface and translate the data for this type into a Person object within the PersonFilterImpl class which directly invokes the EJB with the remote interface NameService.
In this example, if the PersonFilter interface was defined as a local interface, then the concerns with preserving data integrity do not apply. The runtime environment performs pass-by-reference semantics across local interfaces that are appropriate for tightly-coupled clients and services such that no data is copied.

SCA service

If we write a new SCA service and intend to expose it over the SCA EJB binding so that an EJB client can invoke the service, it is a best practice to develop the SCA service using the top-down methodology starting with an existing WSDL file or XSD schema and generating the JAXB classes used to write the service implementation. Using this approach, we can address the differences between Java serialization and JAXB marshalling and unmarshalling by specifying that the generated JAXB classes are Java serializable.
To enable the generated JAXB classes to work correctly over the SCA EJB binding, add the serializable customization to the schema definition so that the generated JAXB classes are Java serializable and implement the java.io.Serializable interface. For example:
<schema targetNamespace="http://com.mycompany/banking/" jaxb:version="2.0"
 xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
 xmlns="http://www.w3.org/2001/XMLSchema">
  <annotation>
    <appinfo>
      <jaxb:globalBindings>
        <jaxb:serializable uid="....."/>
     </jaxb:globalBindings>
    </appinfo>
  </annotation>

   

</schema>
As a result, we can use the Java implementation with the generated JAXB data types over the EJB binding, which uses Java serialization. At this point, because we have the generated JAXB artifacts, we can also use the Java implementation with the generated JAXB data types over the SCA default and SCA web services bindings, which use XML serialization as defined by JAXB.
If we develop your SCA service using the bottom-up approach starting with Java code, use types that implement the java.io.Serializable interface as required when writing an EJB. See the developing SCA services with existing Java code documentation for more information regarding requirements for the user-defined types. Also, see the SCA reference section to learn how to avoid problems with your user-defined types when using EJB bindings because of the differences between Java serialization and JAXB marshalling and unmarshalling.

Related tasks

Develop SCA service clients
Develop SCA services with existing Java code
Develop SCA services from existing WSDL files
Specify bindings in an SCA environment
Configure EJB bindings in SCA applications

Service Component Architecture specifications and APIs