Client Integration Mini-Checklist for Services

May 27, 2012

Working with clients who are consuming your services? Here is a mini-checklist of questions to ask:

  1. While executing request/reply on the service interface is there a timeout value set on the call?
  2. Is there code/logic to handle SOAP Faults /system exceptions when invoking the service?
  3. Is building service header separated from the payload? This will facilitate reuse across services that share common header parameters
  4. If there are certain error codes that the calling code can handle, is there logic for each of them?
  5. Is the physical end point information (URL string for HTTP, Queue connection and name for MQ/EMS) stored in an external configuration file?
  6. Is UTF-8 encoding used while sending XML requests to the service i.e. by making use of platform-specific UTF encoding objects?
  7. If using form-encoding are unsafe characters such as ‘&’, ‘+’, ‘@’ escaped using appropriate %xx (hexadecimal) values?
  8. While processing the service response is the logic for parsing/processing SOAP and service-specific headers decoupled from processing the business data elements?
  9. Is the entire request/reply operation – invocation and response handling logic – encapsulated into its own class or method call?
  10. While performing testing, is the appropriate testing environment URL/queue manager being used?
  11. Is a valid correlation id being used in the service request? This is very essential for aynchronous request/reply over JMS (JMS Header) or HTTP (callback handler)

Event Driven Messaging SOA Pattern

April 11, 2010

I co-authored a short article on event driven messaging – published as part of the SOA Pattern of the Week Article series. If you need to support reliable transports to deliver data and events for SOA solutions – event driven messaging is a key pattern to consider.


Reuse Friendly Practices When Using Messaging Publications

December 3, 2009

Here are a few useful practices that will facilitate systematic reuse when using message publications:

  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.

tweet this


Systematic Reuse Recipe #1 – Minimize Point to Point Integrations

November 21, 2009

Problem Statement

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.

tweet this add to del.icio.us post to facebook


Message Exchange Patterns For Service Capabilities

October 15, 2009

Service capabilities can be reused mainly from the user interface tier, the business services tier, batch processes, and real-time processes and could be consumed from a plethora of platforms.  These capabilities could be accessed via message exchange patterns – request/reply (tight or relaxed SLA) and publish/subscribe.  All of these patterns drive your SOA and systematic reuse efforts. Some capabilities might always be available only via a single exchange mechanism but  you will increasingly be offering similar capabilities across these three patterns.

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.

request_reply#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)

request_reply_relaxed_slaThis 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.publish_subscribe

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

tweet this add to del.icio.us post to facebook


SOA-based Systematic Reuse – Key Considerations

August 13, 2009

Here is a presentation on the key considerations when pursuing a SOA-based systematic reuse approach.

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

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

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

Reblog this post [with Zemanta]

Keeping WSDLs Modular and Simpler to Maintain

June 5, 2009

Here are few tips for keeping Web Services Description Language (WSDL) documents modular and simpler to maintain:

  • 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&gt;. 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.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


%d bloggers like this: