Michael Rowley's Blog

Michael Rowley's Homepage
Michael Rowley is an Architect and Director of Technology within BEA's office of the CTO. He is one of the authors of the SCA and SDO specifications. Work on the SCA specifications, in particular, has been his primary focus over approximately the last 2 years. He has also been involved in BEA efforts related to BPEL, BPELJ, BPEL4People, event processing technologies and our ESB.

Does SCA define a new programming model for Java?

David Chappell says it does. Sanjay Patil says it doesn't. The question seems to come down to the definition of a "programming model".

So, what is a "programming model"? Frankly, I don't really care. I don't think agreeing on a precise definition of that term would really help people understand the technology.

So, what does it define -- in particular, what in JavaEE is no longer needed when you have an implementation of the "SCA Java Component Implementation Specification"? (BTW, this implies that you also have an implementation of the assembly specification and the Common APIs and Annotations specification). Here's my take:

What you can do:

• Create Java classes that are components. These components:
  • Provide services (the interfaces they implement).
  • Are the client of other services (via dependency injection)
  • Have configurable properties (again, using injection)
  • May use async constructs (conversations, callbacks, events)
• Configure and deploy those components. The configuration defines:
  • Which service each client should use (what we call wiring)
  • How clients talk to services (the binding)
  • Security characteristics (authentication, authorization, confidentiality)
  • Transactional characteristics (a specification is coming soon)
  • Reliability

Some of what you can't do using only standard SCA:

• Create or deploy Web applications (no servlets, JSPs, struts, JSF or equivalent)
• Access databases (you need JDBC, JPA or JDO; SDO is insufficient by itself)
• Access bindings via APIs (bindings are manipulated by configuration only)
• Access LDAP or other directory information (i.e. JNDI)

To generalize: SCA is primarily concerned with the business tier, and leaves the presentation tier and data tiers for other technologies to handle.

This means that it is appropriate to use SCA with other technologies. But does it mean that SCA is purely additive to JavaEE? I don't think so. I think that most use cases for creating business-tier functionality can be handled by SCA alone. This means that EJB session beans, MDBs, JAX-WS and even JMS aren't usually necessary in an SCA universe.

Is SDO the data tier for SCA?

SDO is often mentioned in the same breath as SCA in a way that implies that it can handle the data-tier needs of an SCA-based application. I don't think that is the right way of looking at it.

SDO supports the concept of "change summaries", which are basically diffs for data graphs (where a data graph usually corresponds to an XML document). Because of this, SDO is well suited to creating ""data access services", which are services that serve up data and allow it to be modified remotely and sent back. The change summaries make it possible update only the part of the data that has changed (and avoid optimistic concurrency collisions with the rest of it).

SDO also provides a mapping of XML Schemas to Java classes (like JAXB, XMLBeans, JiBX and a hundred others). SDO has a few advantages over the others, and is also philosophically a bit different, in that it attempts to hide XML-isms, so that you can use SDOs without necessarily being tied to XML.

Given only these two basic areas of functionality, it is pretty clear that SDO does not eliminate the need for database access technology for accessing data from Java. However, since SCA supports multiple technologies, it is possible that your SCA environment may offer some non-Java technology for creating data access services. At BEA we have ALDSP for doing exactly that. But if you want to create a new data access service using Java, or if you want your components to access data more directly (rather than as a service) then you need something else. I'd recommend JPA.

SCA vs. JAX-WS

Other people that have blogged about SCA, such as Bill Roth, Jim Marino, Edwin Khodabakchian and JJ Dubray, have all concentrated on SCA's assembly model. The assembly model is indeed one of the most interesting aspects of SCA, but SCA also has two Client and Implementation Specifications, one for Java and one for C++. But Java already has a technology for implementing and using web services, right? Shouldn't JAX-WS just be used for SCA? Naturally the answer to that is no, which is why we have this new programming model for SCA. JAX-WS can be used by components within SCA, but it doesn't have to be.

The biggest differences between JAX-WS and the SCA Client and Implementation specification are differences of philosophy. JAX-WS is very explicitly about supporting the use of web services that are advertised with WSDL and most likely use SOAP over HTTP as the transport mechanism. SCA assumes that clients and authors of services don't care. They do care that it is remote, but they don't necessarily care whether WSDL will be used, and they certainly don't care what the transport mechanism is.

// Sample client code
public ClientComponent {
   // WebServiceRef using the generated service interface type
   @WebServiceRef
   public StockQuoteService stockQuoteService;

   // WebServiceRef using the SEI type
   @WebServiceRef(StockQuoteService.class)
   private StockQuoteProvider stockQuoteProvider;

   // other methods go here...
}

   stockQuoteService.getStockQuoteHTTPPort().getStockQuote();

// Sample client code
public ClientComponent {
   @Reference
   public StockQuoteProvider stockQuoteProvider;

   // other methods go here...
}

// Generated Service Interface
@WebServiceClient(name="StockQuoteService",
                  targetNamespace="...",
                  wsdlLocation="...")
public interface StockQuoteService extends javax.xml.ws.Service {
   @WebEndpoint(name="StockQuoteHTTPPort")
   StockQuoteProvider getStockQuoteHTTPPort();

   @WebEndpoint(name="StockQuoteSMTPPort")
   StockQuoteProvider getStockQuoteSMTPPort();
}

3) Since none of the annotations mentions web services, there is no place where the client or the service provider can point directly at a WSDL URI, or any other WSDL specific configuration data. If this information is to be provided anywhere (and often it isn't) it is provided in a module file.

Service Authoring

// Generated SEI
@WebService
public interface StockQuoteProvider {
   @WebMethod
   Double getStockQuote(String ticker);
}

// Generated SEI
@Remotable
public interface StockQuoteProvider {
   Double getStockQuote(String ticker);
}

It is not possible to say where to find the WSDL. It isn't possible to change the WSDL operation name of "getStockQuote" or to change the WSDL target namespace. If a WSDL is to be generated from this interface, it would use the default mappings. If that mapping needs to be customized, it is done outside the source code of the service.

SCA uses JAX-WS SEI mapping

SCA goes beyond JAX-WS

In addition to being less tied to WSDL, SCA also has a few capabilities that aren't present in JAX-WS. For example, the SCA programming model supports the concept of conversational services and bidirectional services.

Conversational services allow a service to be written where a service provider class can maintain state that is specific to a single client in the fields of that class. The runtime makes sure that any requests that are part of the same conversation get routed to the service instance that has the state for that conversation. Conversations are intended to be business-level concepts, so there might be a single conversation that follows an entire purchasing process. As such, conversation lifetimes would typically be measured in days rather than seconds.

Bidirectional services are services that have asynchronous communication back to the client. As such, the service provider needs for the client to provide an implementation of a callback interface. Note that JAX-WS provides the ability to create an asynchronous client for a synchronous service (so the client can do other things while waiting for the synchronous response), but it does not have the ability to create server-side asynchrony (i.e. callbacks). When SCA uses a web service binding, the protocol that is used would most likely be the WS-Addressing protocol, but that fact is not hard wired into the model.

Summary

SCA provides less WS-specific functionality than JAX-WS, which means that it is easier to use the same service code that may be used through multiple protocols. SCA's client and implementation model also has support for a few key (non-WS-specific) features that are not yet supported by JAX-WS.

SDO vs. EJB3 Persistence

• With EJB3, while it is possible to disconnect from the transaction, you always start by accessing data within a transaction. By contrast, SDO's client always accesses data outside of any transaction that may be used to access the data, so SDO doesn't need to say anything about transactions. How you write the Data Access Service (DAS), which constructs the object graph that is given to the client, is considered outside the scope of SDO. In fact, I expect you could use EJB3 in the implementation of your DAS.
• EJB3 doesn't standardize the form of a changed object graph (a ChangeSummary in SDO), although an implementations of EJB3 may create something like a change summary internally in order to make the merge() operation more efficient.
• For that matter, SDO doesn't have a merge operation. EJB3 merges changes into the persistent graph in the context of a transaction. SDO assumes that the change summary is merged in elsewhere (possibly using EJB3). On a side note, while I say here that EJB3 could be used to implement a DAS, this site describes SDO as being at a lower level then EJB3, where EJB3 could be written with SDO. I'm not sure I buy that.
• SDO, unlike EJB3, is not POJO based. It is not intended that you start with arbitrary Java classes and then make them persistent with SDO. Instead, it is expected that you start with some description of a schema (either XML schema or SDO type description) and then generate Java classes representing the SDO types.
• SDO has a standardized mapping to/from XML. EJB3 doesn't deal with XML, although JAXB does. In this respect it has more overlap with JAXB then with EJB3.
• SDO allows you to use something like XPath (and, in a future version, real XPath) to traverse the graph of objects that you get back. Neither EJB3 nor JAXB allows this.

JBI is for Engines, not Services

I can see the reason for the mistake. JBI proponents describe JBI as the standard for enterprise services buses (ESBs), which leads to the obvious conclusion that JBI must provide an easy way to make a service available on a service bus. This isn't really true. JBI is really at one level of indirection from that. Instead of plugging in services, it is more appropriate for plugging in service engines that in turn allow people to plug in services. It is a subtle distinction, since clearly anything that can host multiple services can also provide a single service. James Strachan has a good, brief summary of JBI. This is more of an exploration into what it is not.

Just for fun, I took a look at how you would make a trivial HelloWorld web service available through JBI.

Here is the code as a JSR 181 web service:

@WebService
class MyService {
   String greeting(String input) {
        return "Hello "+input;
   }
}

If you used a JBI service engine to implement your service, your code would look like this (and I really did work to make it as simple as possible within constraints of the JBI model):

class MyServiceEngine implements Component, ComponentLifeCycle,  Runnable {
    DeliveryChannel channel;
    ServiceEndpoint serviceEndpoint;

    public void init(ComponentContext context)
        throws JBIException
    {
        // Obtain reference to delivery channel
        channel = context.getDeliveryChannel();
        // Activate service endpoint (SEVICE2,ENDPOINT2)
        serviceEndpoint = context.activateEndpoint(SERVICE2,  ENDPOINT2);
        // Spawn a thread to listen for messages.
        new Thread(this);
    }

    /** Loop that listens for requests **/
    void run() {
        while (true) {
            MessageExchange exchange = channel.accept();
            if (exchange instanaceof InOut)
               process((InOut) exchange);
            else {
               // Don't know how to send an error to the sender.
               Log.log("I don't understand this: "+exchange);
            }
        }
    }

    /** Process one request and send the result **/
    void process(InOut inOut) {
        NormalizedMessage inMsg = inOut.getInMessage();
        NormalizedMessage outMsg = inOut.createMessage();

        try {
            // Get the input as a DOM Text node
            Node inNode = (Node)((DOMSource)inMsg.getContent ()).getNode();

            // perform appropriate processing to inMsg
            Node outNode = greet(inNode);

            // populate message content
            outMsg.setContent(new DOMSource(outNode));

            // attach message to exchange
            inOut.setOutMessage(outMsg);
        }
        catch (Exception ex) {
            inOut.setError(ex);
            inOut.setStatus(ExchangeStatus.ERROR);
        }
        channel.send(inOut);
    }


    /** The real work **/
    Node greet(Node inNode) {
       String input = inNode.getTextContent();
       String result = "Hello "+input;
       Node outNode = inNode.getOwnerDocument().createTextNode (result);
       return outNode;
    }
}

Clearly, if you are working in an environment that already has the engines that you need for hosting web services, business processes, XML transformations and other business code, then JBI is not for you.

October 2007

Search this blog:

Archives

May 2007
January 2006
August 2005

Categories

Recent Entries

Does SCA define a new programming model for Java?

Is SDO the data tier for SCA?

SCA vs. JAX-WS