Click here to Skip to main content
13,093,720 members (61,258 online)
Click here to Skip to main content
Add your own
alternative version


7 bookmarked
Posted 9 Apr 2009

Top 5 Ways to Simplify Your SOA

, 9 Apr 2009
Rate this:
Please Sign up or sign in to vote.
SOA-style solutions can seem complex; however, doing a few easy things can make SOA projects a lot simpler.

SOA-style solutions can seem complex; however, doing a few easy things can make SOA projects a lot simpler. In this article, I describe the top five ways in which you can simplify a new SOA project, or bring some more order to an SOA project that has gone astray.

Apply SOA to the Right Type of Problems

SOA is not the solution to all integration problems. Applying SOA to the wrong types of problems can contribute to creating more problems.

Think in terms of organizational boundaries – departments, satellite offices, trading partners. Organizations often duplicate data across organizational boundaries to make it easier for departments to extract and transform relevant information. SOA makes it easier to share enterprise assets – like customer, order, and product information. SOA is ideal for addressing problems related to acquiring and distributing information of interest to a range of business processes.

Focus on Business Processes before Buying Tools

Tools are designed to address the needs of a class of users working on a known range of common problems.

There is excellent tool support for SOA-based applications, and availability of components of SOA-based applications: tools are available at all price points and levels of expertise. Examples of SOA tools include service registries, master data repositories, and orchestration engines and platforms.

While the choice of tools may seem overwhelming, and may make SOA appear to be very complex, not all are necessary. When focusing on business processes, you’re likely to find that not all business problems have technical solutions because the business process is very complex. In some cases, the business process could be ‘flawed’ from a purely functional point of view, but may be a great tactical solution for your purposes.

Therefore, focus on understanding your organization’s business processes before thinking about tools – start thinking about a toolset once you have your overall approach in place.

Design and Build the Right Services

When deciding on services to build, focus on services that provide value to your business and organization. Focus on sharing information (not data) across departmental, and trading partner boundaries and office locations.

Begin with your ideal model without considering timelines, technical capabilities, etc., and work backwards from there – always focusing on business and organizational value.

Expose your Services the Right Way

SOAP and REST are two key means of exposing services. Consider service clients, calling patterns, security, and network architecture.

Consider your business processes – are they complex enough to need orchestration services? At the other extreme, are your business processes simple enough that you can implement them using your organization’s technical infrastructure? Do legacy systems participate in your business processes, and what are their messaging requirements?

Establish an SOA Platform

An SOA platform is a framework that supports:

  • Service management – Health and activity tracking, deployment capabilities
  • Reliable messaging – Transaction support, durable messaging, reliable queuing
  • Service Registry – Support your business’ means of defining and locating services, provide human and programmatic/system access
  • SOA Security – Leverage existing infrastructure, introduce a new security infrastructure, or integrate to create a hybrid solution

The framework is more than a technical solution – it is a platform on which to build, deploy, and manage your organization’s services. As a result, you could end up writing documentation to satisfy some facets, and implement a messaging system for others. The key is that you define the platform’s capabilities and behaviour, and design your solution and toolset to meet those needs.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Erik Westermann
Software Developer (Senior)
Canada Canada
Erik is a senior developer-writer with more than 14 years professional programming experience designing and developing large scale database and Internet-centric applications for organizations including, ADP, Nortel,, EDS, Merrill Lynch, ePost, CIBC, TD Securities, IBC, CIHI, InnovaPost, etc.

Erik has been specializing in BizTalk Server-based solutions for five contiguous years to date. His experience includes many SOA and ESB-style applications using technologies like Commerce Server, SharePoint, ASP.NET and advanced .NET Framework.

You may also be interested in...


Comments and Discussions

-- There are no messages in this forum --
Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.170813.1 | Last Updated 9 Apr 2009
Article Copyright 2009 by Erik Westermann
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid