Page History

...

In an SOA environment, business functions can be implemented in various technologies such as Java, C++, Scripting, BPEL, Spring, OSGi and XQuery. The business data can also be represented in different formats such as DOM, JAXB, SDO, AXIOM or POJO. Business services often communicate with each other on the network using various protocols such as RMI, RMI/IIOP, SOAP/HTTP, JMS, JCA, FEED and JSON-RPC. The service collaborations are achieved by data exchanges between service components. The SCA programming model defines an extension model for interface, implementation and binding types. The extensibility is essential to SOA as we need to be able to leverage and integrate all kinds of technologies. On the data side, we also need the extensibility for different formats so that we can flow any data type that is supported by both the client and the provider.

Business data are represented in different ways even they are for the same infoset. For example, we can model a Customer business object as:

• SDO
• JAXB
• JavaBeans
• DOM

And different protocol implementation stacks support different data representations. For example, in the Web Service domain, we have:

• Axis1 uses DOM
• Axis2 uses AXIOM
• JAX-WS uses JAXB

Application developers should have the freedom to choose their preferred data representation and components with compatible data should be able to interoperate without the intervention of the business logic. With the ability to attach data transformation mediations to wires, this actually becomes a requirement to support any data type that can be mapped from client to provider and back again.

In any interchange there are just two things that are defined: the format of data that will be supplied by the client and the format of data that will be consumed by (delivered to) the provider. Neither client or provider needs to be aware of the format of data on the other end or of what gyrations the fabric went though in order to make the connection. As part of making the connection, it is the fabric's job to make the connection as efficient as possible, factoring in the semantic meaning of the data, the policies that need to be applied, and what the different containers support.

All this flexibility just about requires we use the most generic type possible to hold the data being exchanged: a java.lang.Object or a (void*) depending on the runtime. The actual instance used would depend on the actual wire, some examples from Java land being:

• POJO (for local pass by reference)
• SDO (when supplied by the application)
• Axiom OMElement (for the Axis2 binding)
• StAX XMLStreamReader (for streamed access to a XML infoset)
• ObjectInputStream (for cross-classloader serialization) and so forth.

Each container SCA implementation and transport binding type just needs to declare which data formats it can support for each endpoint it manages. The wiring framework need to know about these formats and about what transformations can be engaged in the wire invocation pipeline.

For example, the Axis2 transport may declare that it can support Axiom and StAX for a certain port and the Java container may declare that it can only handle SDOs for an implementation that expects to be passed a DataObject. The wiring framework can resolve this by adding a StAX->SDO transform into the pipeline.

The limitation here is whether a transformation can be constructed to match the formats on either end. If one exists then great, but as the number increases then developing n-squared transforms becomes impractical. A better approach would be to pick the most common formats and require bindings and containers to support those at a minimum, with other point-to-point transforms being added as warranted. (Source: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c4418A53D.2080606@apache.org%3e)

Business data are represented in different ways

• SDO
• JAXB
• JavaBeans
• DOM

Different Web Service stacks use different data representations

• Axis1 uses DOM
• Axis2 uses AXIOM
• JAX-WS uses JAXB

Application developers should have the freedom to choose their preferred data representation and components with compatible data should be able to interoperate without the intervention of the business logic

Usage Scenarios

The data model

...