1. Organize publication topics by a domain relevant hierarchy – this will help cater to subscribers that are interested in fine grained messages as well as those who want an entire set of related publications.
2. Version publications – if one publication can send multiple types of business/data entities, version them as well.
3. Separate publication into a header and business payload section. This will help you write utilities that can examine the header and take action – e.g. display any publication as XML, report on a variety of metrics etc.
4. Reuse xml schema contracts that are used in your web service API as much as possible in the business payload publications. This will reduce the programming and integration effort for your consumers. They can reuse the same code regardless of whether a message came as a reply or sent as a publication.
5. Support multiple data formats – not all your consumers might want XML. Some might prefer delimited text or fixed length messages. Your services platform can publish the same message in multiple data formats across topics – e.g. com.yourcompany.messaging.customer_v1_0.XML and com.yourcompany.messaging.customer_v1_0.FIXED_LENGTH

These are some of the guidelines I have used. Have you used additional ones to facilitate reuse?

Like this post? Subscribe to RSS feed or get blog updates via email.

A consuming application/business process wants to integrate with your reusable asset. However, the consumer doesn’t want to take your standard message – wanting a specific format that will make it easier for them. Why? Could be because of several reasons: lack of time/money/skills or technical limitations (e.g. their system can handle only delimited files and cannot parse XML).

Suggested Approach

The immediate, tactical (and often tempting) solution would be to just format the data per the consumer’s format and integrate in a point-to-point fashion. Don’t settle for this option too quickly! Prefer to publish a standard publication in that is in line with your long-term direction (e.g. offer reusable message publications in XML format indicating changes to critical data entities or state changes in business processes). Create a subscriber that tranforms the standard message to the consumer-specific format.

Rationale

If point to point integrations go ungoverned, you will end up with a rat’s nest of tightly coupled integrations that ultimately hurt business agility.Your long-term intent is to have multiple consumers (web applications, backend systems, business processes, etc.) consume reusable message publications.If several business processes need the same core data or notifications about state changes, why would you want to integrate with them separately? Publications will not only reduce integration effort, they place less strain on your system resources – publish once and subscribe several times. No need to query databases or invoke external systems every time there is a new integration.

Note: The additional transformation logic will require extra logging/error handling but over the long haul is a better option than going for a point-to-point integration approach.

This will enable the asset provider, to integrate new applications faster (no need to custom develop messages and integration code for every new consumer) and reduce the cost of maintenance. Reducing application to application coupling is a key motivation for pursuing this approach as well.

Like this post? Subscribe to RSS feed or get blog updates via email.

Note: the illustrations below depict a data source behind the service capability. This isn’t a requirement but if you are exposing core data as entity services or business services that access underlying data you will be needing one or more data sources for the service to be functional.

#1 Request/Reply (tight SLA – typically synchronous)

Most common pattern when executing on-demand data services. This is typical of interactive applications that send requests and block on a response. When doing a synchronous request/reply via JMS, a temporary/physical response queue could be created. Regardless of transport used, the idea is to get a response very quickly.

#2 Request/Reply (relaxed SLA – typically asynchronous)

This pattern is used when executing long running service capabilities. The consumer sends a request and does not block on a reply. When the response is sent from the data service, the consumer can use a callback mechanism (a message listener) to process the data. This pattern also typically uses correlation identifiers to relate request and response messages. When using JMS, a physical queue is used to obtain the response messages. A queue receiver drains the message from the queue and proceeds with processing.

#3 Publish/Subscribe

This pattern is used by publication services that execute based on a business event or a data operation even. The service will publish standardized messages that align with your business-specific or domain-specific data model. This is very useful when multiple consumers need to get notified upon updates/changes to core data. Using this model, new consumers can be added via configuration in a message broker as opposed to writing code for each integration. The service will publish to a destination (i.e. a Topic) and subscribers (consumer applications or processes) will each get the appropriate publication.

Like this post? Subscribe to RSS feed or get blog updates via email.

Are there others you think should be included in this topic?

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :

• Import XML schemas for elements referenced by method contracts. Do not embed types/elements into the WSDL – because you will have multiple schema definitions that can quickly go out of synch. Organize XML schemas using a standard directory structure and host them externally. You can use the schemaLocation attribute to point to the physical location of the schema.
• Follow a consistent naming convention for WSDL namespaces. I use http://my-server.my-company.com/<DomainName>/<ServiceName>_<ServiceVersion>. This will make it easier for consumers when they generate service proxies and bindings.
• Use WSDL templates with variables for specifying transport specific information (e.g. when using HTTP you can have a variable for service endpoint host, port, etc. Alternatively, when using Java Message Service (JMS) you can specify queue name, user name, password etc.). Using an ant script with property files you can replace these variables with service specific values.

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :