CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Continuous Integration Authors: Jason Bloomberg, Yeshim Deniz, Elizabeth White, Pat Romanski, Liz McMillan

Related Topics: XML Magazine, SOA & WOA Magazine, IT Strategy, Continuous Integration

Continuous Integration: Article

Building Strategic Services for Your SOA

Embracing the SOA metaphor from data format, schema development, services implementation, and consumer integration perspectives

Many enterprises are working with service-oriented architecture (SOA) initiatives using a variety of approaches. Regardless of the specific approaches undertaken, the intent is to build services and business processes to enable the organization to realize the benefits of SOA. However, you need to practice specific techniques to ensure that the service capabilities you are building are strategic. This article covers specific technical practices that help you build services for today and the future.

Switch from Web Services to the SOA Metaphor
Web services consumed ad-hoc from multiple one-off projects and initiatives will guarantee that you end up with a rat's nest of point-to-point integrations. Instead, fully embrace the SOA metaphor where service capabilities are built, versioned, audited, governed, and reused. Consumer contracts are sacred artifacts that cannot be changed willy-nilly and need to be aligned with your logical data modeling efforts. You will have to support multiple service versions until all your consumers migrate to a single version. When leveraging legacy services, introduce a mediation layer for decoupling consumers and legacy systems. Capture metrics and usage statistics about your consumers and support transports in addition to HTTP for integration.

Embrace Data Format Heterogeneity
Traditionally you might have supported only SOAP XML as your data format for consumers. Offer additional formats such as JSON and RSS for service capabilities accessed for enterprise mashups and web applications. You can use the Decorator design pattern to transform the XML data into multiple formats, depending on the consumer needs. The more formats you can support natively, the easier it is for your consumers to integrate the service capability, increasing reuse potential and decreasing development costs.

Support Reliable Messaging
Go beyond the synchronous request/reply message exchange pattern. Offer additional patterns such as asynchronous request/reply, publish/subscribe, and fire/forget-based integration options for consumers. This not only increases flexibility and reusability but also makes you highly scalable. Not every application in your enterprise will need synchronous request/reply type interactions. Long-running business processes and batch jobs are cases that might need asynchronous integration capabilities. Ensure that your services can support reliable messaging-based integrations using transports such as Java Messaging Service (JMS). Many mission-critical business processes require the flexibility, loose coupling, guaranteed delivery, and scalability offered by reliable messaging transports. It is imperative that your consumers can access service capabilities via messaging.

Govern Service Contracts
There are a variety of concerns with contracts that you have to be cognizant of when building services. Ensure that you enforce a consistent naming convention for namespaces, importing schemas into WSDL documents, making schema contracts extensible, and ensuring data types are reused across multiple schema structures. You also have to ensure that schema contracts align with your enterprise's logical data models. This is essential to provide necessary decoupling between physical data repositories and service interfaces. Logical data models are also aligned with your business domain and use consistent naming conventions. More important, logical data models contain the mapping between data structures in the service contract and physical tables and views. This will be invaluable to perform impact analysis on service capabilities when changes are made to data stores.

Standardize Exception Handling
As services federate across multiple systems and integrate data from several sources, it's likely that the exception semantics are inconsistent. The service capability should strive to provide a consistent exception handling mechanism on top of this heterogeneity. This can be achieved by standardizing business and technical error codes across services and designing a central exception handler that can process errors across your SOA. The central exception handler can analyze error information, try to execute automated steps to compensate transactions, and mitigate ripple effects. In addition, based on error characteristics the handler can pause the processing of requests, enrich/fix bad data, and retry failed messages. It can also send notifications/alerts to appropriate production support staff for manual intervention.

Partition Business Process and Data Services Logic
Your services inventory is likely to contain both business process services and data services. Ensure your data services logic isn't specific to a particular distribution channel, user population, or business process. This will keep your data service well encapsulated and boost its reuse potential. Data services can then be leveraged for multiple business-process orchestration needs. This will also enable the service provider to govern and scale data services independently of business process services.

Validate Service Requests
You should validate service requests to restrict bad data from entering your downstream systems. Whether you do XML schema-based validations or introduce decision services to execute business rules, ensure that you kick bad data out as early as possible. This practice reduces the amount of validation logic in downstream components throughout your SOA stack. On a related note, this practice also reduces the burden on back-end system resources such as application servers and database servers.

Leverage Automated Testing Tools
Manually testing services might be okay to start with but is unsustainable. As you expand your service capabilities, you will want to leverage automated testing tools for unit, integration, and performance tests. Adding your unit tests as part of a regression test suite that executes as part of a continuous integration build process is a strong recommendation as well. As things constantly change in the environment - server upgrades, database migrations, operating system patches, and vendor packages - you want to make sure your services don't break. If they do break, you should know as soon as possible so you can fix the code and prevent defects from leaking into the future phases of your development process. Likewise your support team will need automated tests to validate releases, smoke test deployments, and perform routine checks to make sure that services are performing as designed.

Make Integration as Painless as Possible
The success you will have with your SOA efforts is directly proportional to the ease with which your consumers can discover, integrate, and deploy code into production. You want to make it as easy as possible for your consumers to discover services. Provide comprehensive documentation about each service and service capability including functional behavior, error codes and exception handling, limitations, and SLA characteristics. Similarly, provide integration tools and documentation that consumers can use to generate data bindings, service proxies, and even automate test data that can be used to test their client code. Finally, try to truly understand what your consumers are doing with your services so you can use that as input into the service design and development process.

Too many organizations jump head-on into service development without considering the ramifications of design and development choices and practices. This article showed how important it is to embrace the SOA metaphor from data format, schema development, services implementation, and consumer integration perspectives.

More Stories By Vijay Narayanan

Vijay Narayanan is a software development team lead, building reusable data services and business process automation components for a financial services firm. He has worked on several software projects ranging from single user systems to large, distributed, multi-user platforms with several services. Vijay blogs about Software Reuse at

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.