Enabling Self-Service for Easier Service Integrations

May 31, 2011

There are a number of benefits with exposing services and enabling application to application integration through them. However, when the number of services increase, the support and integration effort involved goes up as well – moving to a self-service model for service integrations makes it simpler and faster for clients, cheaper and more reliable for the service provider. Here are a few tips to make this happen:

  • Ensure all service interfaces are URL accessible – e.g. WSDL, associated XSD schemas etc. are hosted in a consistent structure that tools like WSDL2Java or wsdl.exe can point to and generate client side code
  • Templatize the WSDL and XSD to capture client-specific information such as application identifier and name (e.g. if your service interface mandates these values, you can default them to use the appropriate client-specific value).
  • Capture authentication and authorization requirements and similar to above point, generate code to set appropriate message headers (e.g. SOAP Header or JMS Header as appropriate) – this will be common to most clients except the exact credentials will vary
  • Keep documentation up to date as part of the build and deployment process – e.g. if you are deploying services to a client facing environment (e.g. integration testing), deploy documentation as well as part of the exercise. For instance, generate javadoc style XML schema documentation and maven site-deploy target can be leveraged to upload the generated artifacts to a web application.
  • Capture and maintain service metadata – this metadata should not only cover functional aspects but non-functional attributes as well. For instance, if your service cannot honor a response time requirement, it is critical to know that during the integration effort and not after the client has migrated their code to a production environment. This could translate to a service enhancement or an alternate integration approach altogether

This is by no means an exhaustive list but meant to give a window into the opportunities and benefits that self-service can provide.

10 Design Assumptions That Hurt Your SOA Efforts

August 24, 2009

Building service capabilities that are strategic for your enterprise is a key aspect of SOA and lays the foundation for agile business processes in your organization. Many teams are engaged in building service capabilities both as part of SOA initiatives and bottom-up ones motivated by technology teams pursuing the benefits of service orientation.

How do you ensure that the service capabilities are in line with business objectives?
Are th
ere assumptions that hurt your SOA? I believe so! Here are 10 design assumptions that you need to watch out for:

  1. Service capabilities are always Web Services
  2. Services need to support only one data format i.e. SOAP
  3. Services are implemented first and then contracts are extracted (aka code-first approach)warningsign
  4. Service contracts don’t have to be reviewed or governed
  5. Service capabilities from vendor solutions can be consumed out of the box without mediation
  6. Services handle exceptions in an ad-hoc manner
  7. Services implement consumer specific logic
  8. Service interfaces are always non-validating
  9. Service capabilities are always accessed in a on-demand fashion. No need to support event driven interactions.
  10. Service consumers will all migrate to new versions simultaneously. No need to support multiple versions.

Please add to this list any additional assumptions that inhibit the effectiveness of SOA efforts!

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! : :

Add Transports Iteratively For Service Capabilities

July 14, 2009

You can add transport bindings to your reusable services iteratively as necessitated by project needs and timelines. A service can start out getting consumed over HTTP, and then support additional ones such as HTTP-S and JMS over time. The key is to not place transport logic in your service capability. This will give you a great deal of flexibility in adding and supporting new transports.

For example, your service can be initially consumed by a user interface application via request/reply SOAP over HTTP. Day 2, you might have a backend process that consumes the service via asynchronous request/reply SOAP over JMS. This should be a graceful extension for you if there was nothing in the service logic specific to HTTP or synchronous request/reply.

In essence, you are decoupling request processing, service business logic, and response handling:


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: