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