Best Practices: SOA Application Design Analysis
Partner InteractionThe result of your analysis should be a set of process models, a list of partner services and the types and details of the interaction (whether synchronous or asynchronous) associated with each partner.
Keep these considerations in mind when working with partner services:
- Is there a well-defined interface and data model that describes the partner's interface? Some home-grown applications may not have had a well-defined interface (but it just happens to work). Additional steps may be needed to examine and redefine a partner's interface.
- Are the WSDL and XML Schema definitions for the interfaces available? ActiveVOS allows the import of WSDL and XML Schema artifacts from shared repository into an individual orchestration project where they are cached and consumed. If XML Schema definitions are not readily available but XML instance documents are, then instance documents can be used by ActiveVOS to create the appropriate schema definitions.
- What are the main characteristics of the partner services? Are they short lived, atomic transactions that usually complete in seconds? If so, then synchronous interaction pattern may be most appropriate. If not, then an asynchronous communication pattern should be considered. This, of course, will depend on the service's ability to perform call-backs. Additionally, if the service supports WS-Addressing, ActiveVOS engine-managed correlation (video link - registration required) should be considered.
- Are these definitions fairly stable or it is anticipated that they will change during the course of implementation? The fundamental advantage of loosely coupled application development model rests on the assumption that service interfaces are well-defined and remain stable. Sometime components get developed simultaneously and their interface evolves over time because new business requirements are being addressed. This is an undesirable practice because of the disruption this kind of change causes. Planning and designing up front can minimize otherwise avoidable disruptions. Things may break when someone replaces a string type with an enumeration type in a schema, for example. If this cannot be avoided, then an effective mechanism and procedures for managing definitions need to be put in place:
- Interface artifacts should be put under source code control and versioned
- Updates to shared artifacts should be strictly managed through a change process
- Close and effective team communication is key to ensuring success and minimizing disruption
- Will there be a need to bridge between different protocols and message encoding? If yes, list the transport protocols/encoding and the applicable technology to support them:
- ActiveVOS supports the following protocols/bindings for consumption and producing services out-of-box: SOAP/HTTP/HTTPS, SOAP/JMS, Plain XML/JMS, REST, and JAVA/EJB
- Use the custom invoke and custom receive handler mechanism provided by ActiveVOS. With these features you can write Java class to handle the message transformation and transport protocol conversion anyway you want.
- Use an Enterprise Service Bus (ESB) solution together with ActiveVOS if you need to support a wide spectrum of transport protocols/bindings