Codehaus XFire
DocumentationQuicklinksDevelopers
Sponsors |
Overview of APIsGenerally many of the various frameworks share the same principles.
Axis2Transports and Messages The correlation to a MessageExchange in JBI would be the OperationContext in Axis 2. The OperationContext holds references to the various MessageContexts involved in the message exchange pattern. public class OperationContext { public MessageContext getMessageContext(String messageLabel) throws AxisFault {} } Handlers For the interceptor chain, Axis2 has the concept of Handlers, Phases and flows. There are multiple flows - in, out, and fault. Fore each flow there are many different phases. Handlers can associate themselves with a phase and they can specify that they want to run before/after specific handlers within the phase. Pros:
Cons:
CeltixHandlers Transport API
Celtix really reuses the concept of WS-Addressing endpoint references within its API. Whenever you create a transport you must supply an EPR. This will then set up your ReplyTo/FaultTo streams automatically. Pros:
Cons:
ServiceMix/JBIJBI Javadocs Central to JBI is the concept of a NormalizedMessage. The NormalizedMessage holds a reference to the message as a Source object.
Pros:
Cons:
TuscanyTuscany's Message class holds a simple object containing the Body of the message. It also provides a callback channel for synchronous/correlated responses. TODO: what is getRelatedCallbackMessage for? It seems like maybe its for a correlated response. public interface Message { Object getBody(); void setBody(Object body); public void setTargetInvoker(TargetInvoker invoker); /** * Sets the target invoker to dispatch to when the message passes through the request side of the invocation chain */ public TargetInvoker getTargetInvoker(); public MessageChannel getCallbackChannel(); public Message getRelatedCallbackMessage(); } public interface MessageChannel { void send(Message message); } The MessageChannel class is as close to defining a Transport API as Tuscany comes currently. It does however, define some interception patterns: public interface Interceptor { /** * Process a synchronous wire. */ Message invoke(Message msg); /** * Sets the next interceptor. */ void setNext(Interceptor next); } public interface MessageHandler { boolean processMessage(Message message); } TODO: fill in more details on how these classes are used! Pros:
Cons:
XFireThe XFire model focuses on the idea of Transports and Channels. Channels provide a means of communication on a Transport. When a request comes in, a Channel is opened and a message is sent to the ChannelReceiver. This starts an invocation flow within XFire sending a message down the in pipeline. public interface Channel { void open() throws Exception; void send(MessageContext context, OutMessage message) throws XFireException; void receive(MessageContext context, InMessage message); void setEndpoint(ChannelEndpoint receiver); ChannelEndpoint getEndpoint(); void close(); Transport getTransport(); String getUri(); boolean isAsync(); } public interface Transport extends ChannelFactory, HandlerSupport { boolean isUriSupported(String uri); String[] getSupportedBindings(); void dispose(); Binding findBinding(MessageContext context, Service service); } public interface ChannelFactory { Channel createChannel() throws Exception; Channel createChannel(String uri) throws Exception; void close(Channel c); } Typically transports will want to handle soap messages. To do there is typicall a raw transport class, like HttpTransport, and a Soap transport class which extends it - like SoapHttpTransport. A soap transport will then register additional handlers to parse the soap message, set the soap version, etc. Messages in XFire are represented by the InMessage and OutMessage classes. The InMessage has an XMLStreamReader associated with it. The OutMessage takes a MessageSerializer which is a callback to write the message to an XMLStreamWriter at the appropriate time. The InMessage/OutMessage API is mostly focused around StAX, but can be used to hold objects as well in its Body property. There is also the concept of a MessageExchange in XFire. These holds references to the various messages in the MessageExchange pattern. It also holds a reference to an OperationInfo instance which contains the metadata about the operation being invoked. This class correlates highly with the WSDL operation concept. Handlers are XFire's way to Intercept messages. They provide an invoke method which takes a MessageContext. Handlers can be registered in the in, out, and fault flows of a service & client. Within each flow there are a number of phases a Handler can participate in. Pros:
Cons:
|