- Payload abstraction
Payload abstraction is the ability to send a payload (the document or request object sent to a Service) without regard to what protocol might be configured.
This architectural abstraction is made necessary due to
Transport/protocol abstraction , which is the capability of switching protocols at runtime through the use of a configuration file. The fact that different protocols allow different data types may lead to problems in payload definition. That is, a system must either determine at design time all possible service protocol implementations that might be used by their service for all time, or a payload must be designed with “least common denominator” data types. For example, a Java based direct call Service Protocol implementation would likely allow any Java type to be sent. AJMS Service Protocol implementation might allow only a subset of these types. AnXML-RPC Service Protocol implementation might allow an even more limited subset of types. In order to dynamically switch from one protocol to another, the payload design must implement only the simplest types which all protocols will accept without error, or use Payload Abstraction.A description of example implementations of Payload Abstraction, from the
elemenope User Guide:Doppelganger extension - Doppelganger is an extension to the elemenope Framework which requires an XML schema definition for the payload. This schema is used to dynamically generate Java classes which may be used to marshall data to XML and back. The payload is the generated XML. In this manner, all protocols (at least all protocols implemented at this time) may pass the marshalled XML without error. The Services and their configured Operation implementations only ever see the objects of the classes generated by Doppelganger. Doppelganger uses the Castor Project Open Source data binding framework.
RosettaType - RosettaType is a project which defines a generic data structure and several protocol and language specific RosettaEngines. These RosettaEngines translate an instantiated object of any given data type to the RosettaType structure and back to the original object, i.e. from POJO2 to RosettaType and back to POJO. RosettaType provides the most efficient mechanism for payload abstraction, as the RosettaEngine implementation in use for a particular protocol will only translate or “roll out” datatypes which are not supported in that protocol. All other datatypes within the generic payload will be left as-is for simple passage. The RosettaType implementation is not complete. Multiple protocols have been implemented, and are currently being reviewed. When integrated into the elemenope Framework, each ser- vice protocol implementation will gain a class extended from the base implementation to handle the RosettaType functionality. This extension of the base implementation class will allow a user to utilize the simpler form of the service protocol implemen- tation, and only utilize the RosettaType form if needed. RosettaType is maintained by createTank. The RosettaType project is Free and Open Source [FOSS] .
When completely implemented, the RosettaType will likely be the preferred method for payload abstraction, as it offers the most natural form, not requiring any design fore-thought.
ource
elemenope User Guide
ee also
elemenope External links
* [http://elemenope.org/ elemenope home page]
* [http://elemenope.org/doc/userguide/userguide-1.1.pdf elemenope User Guide]
Wikimedia Foundation. 2010.
