Hands-On Scenarios for Starting SOA

Clark Richey, a Principal Systems Engineer with BEA, takes architects and developers through hands-on SOA user scenarios in Part II of his SOA series for Integration Developer News. Learn how to map your SOA plan to your current IT architectures -- client / server, web services and service-oriented.

Tags: SOA, Integration, Architecture, Building Blocks, Applications, Enterprise, Business,


So you want to build a SOA? Great!

Let's look at two starting scenarios and discuss strategies for getting your SOA off the ground in each one.

[This is the second in a series of articles aimed at helping developers, architects and managers navigate the ever - shifting SOA landscape as you search for solutions to your SOA issues. Read Part I]

However, first, we'll review some SOA basics.

When building Service Oriented Architectures (SOAs), we strive to create loosely coupled services, each of which performs a logical, discrete business function. These services act as the building blocks for our application and ultimately, our enterprise-wide SOA. The loose coupling between our building blocks allows us to add new building blocks and replace others as our business needs change.

SOA: An Incremental Process
Developing a SOA is typically an incremental process, even when starting from scratch. Unless you have extensive experience building SOAs prepare to take an extensive period of time to architect, design and build a true SOA.

This is because it is difficult to correctly identify the dividing line between our services, or building blocks, and to join them together in a coherent way. Most projects do not allow for enough time in their schedule for this level of effort. Therefore, as you progressively move toward a true SOA, you must providing demonstrable, increasing value along the way.

A Step-by-Step Path
The chart below shows a possible path to an SOA, beginning at a client / server architecture. In addition to indicating three major architecture types, client / server, web services and service-oriented, the chart describes major characteristics of each type of architecture. Typically, systems should undergo new releases as progress along this chart so that increased value can be realized.





One final note about Chart 1: Not all applications require a full SOA complete with human workflow, data mapping, etc. It is just as important to evaluate your architectural needs as it is to determine the current state of your architecture. Not every application is an enterprise application requiring a full SOA implementation.

In Detail: The 1-2 SOA Scenarios
In every scenario, we must begin by determining where on this chart our current architecture falls, and what steps must be taken to move closer to our goal of achieving a service-oriented architecture.
After deciding where in the architectural continuum your existing applications lie, determine which integration would deliver the highest return on investment and tackle that integration first. Depending on the architecture of the applications being integrated, you will require different integration approaches.

Scenario 1 --Use Case Example: Legacy-to-SOA
Most existing applications can be integrated with a minimum amount of difficulty using web services as the initial integration point. However, you should use the integration technology most appropriate to your environment. If you have advanced message-brokering capabilities in place, it makes sense to take advantage for those capabilities for your integration.

  • As you perform this integration, resist the temptation to expose the details of each service being integrated;
  • Ensuring that your integration points between services are coarse grained is a standard best practice of enterprise application integration, especially important when your ultimate goal is to create an SOA fabric for your business;
  • Once you've made the initial integrations, start making them more flexible by progressing your architecture along the path shown earlier, toward a true service-oriented architecture;
  • Your goal is to reduce the coupling between the integrated systems so that as your business needs change, you can easily add or remove new services without having to re-write existing application code;
  • As you progress along this path, spend some time examining the individual applications within your burgeoning SOA fabric.

    The Next-Step: Enterprise-Wide SOA
    Now that you've integrated these applications and are moving toward an "enterprise-wide SOA," an examination of your individual applications will likely reveal a duplication of services internal to each application. You can take those duplicated services and promote them from internal, application-specific functions to enterprise services.

    To clarify this, let's look at a very simple example. Suppose you integrate applications X, Y and Z. Each application uses its own internal logging framework. Instead of continuing this duplication of logging within each application, consider creating a logging service and making it available to every other service within your SOA framework. Now, not only have you eliminated a point of redundancy, thereby increasing the maintainability, but you now have a central repository for logging information for your entire SOA fabric.

    Scenario 2: Building Enterprise SOA from Scratch
    The key in this scenario is to not bite off more than you can chew.
    You undoubtedly have a ton of work facing you to implement the necessary business requirements for your first release without the added burden of attempting to implement a sophisticated SOA infrastructure such as a robust data-mapping layer.

    You must create a system that meets your business requirements. Then, you can worry about creating an SOA fabric for your enterprise. After all, if your application doesn't meet the business requirements, there is no point in exposing it as a service available to your enterprise! Even though it should not be your first concern keep your SOA goal in mind as you build your initial application.

    Here are some key points to remember as you move forward with your design and implementation. With these guidelines, you should take your application to the next architectural level with minimal difficulty.

  • 1. Build your application out of smaller building blocks: Just as your applications will be a building block upon which your enterprise-wide SOA is built, so should your application be built on smaller blocks, each of which performs a specific, discrete service that helps to meet your business needs. While your application will be called on to perform many functions, you can almost always segment off portions of functionality into their own subsystems, or building blocks.

  • 2. Plan for change: Once you know what your building blocks are and how they fit together, make sure that you provide yourself with the ability to change blocks. For example, if one of my building blocks is Payment Processing, I want to make sure that I can remove the existing Payment Processing block and replace it with a new implementation of a Payment Processing block in the future as my payment processing needs change. I need to be able to do this without having to change the code that uses the Payment Processing block. Typically, this is done through increased abstraction in your code, most often by coding to the contract (or Interface) of the Payment Processing block, and not its implementation.

  • 3. Don't over-engineer: Grow gradually. Don't try to build a sophisticated infrastructure using dynamic routing, human workflow and data mapping layers right out of the starting gate. Solve the business problem first, keeping in mind the first two rules, and then take your infrastructure to the next level. This rule still applies after the first release (or two!) of your system, when most of your business logic has been built. To avoid introducing unforeseen problems, grow your infrastructure gradually.

    SOA Scenario Summary
    Whether you're building your SOA fabric from the ground up with brand-new applications, or integrating existing applications as the core of your SOA, the basic principles and pathways for creating your SOA don't change. You have to figure our where your architecture is now and where you want to be when you're done. Next, you have to create a plan for getting there, one step at a time, while realizing added value with each step. To achieve success, you don't have to reach the far right of the chart—just create an SOA fabric that meets your business needs.

    Clark D. Richey, Jr. is a Principal Systems Engineer with BEA Systems' Government Systems Group. Prior to working for BEA, Clark worked as an architect and technical lead for several systems integrators, including Aquilent and High Performance Technologies. Clark has designed and implemented enterprise systems in both Java and .NET, and is the author of the Java Developer's Journal article, "Clustered Timers For Robust Scalable Systems." Clark has also authored an Open Source framework called StopLight, based on the concepts in this article, which will soon be available at Java.net.



    back