Welcome!

Microservices Expo Authors: Liz McMillan, Pat Romanski, Carmen Gonzalez, Elizabeth White, Jason Bloomberg

Related Topics: Microservices Expo

Microservices Expo: Article

Avoid SOA Pitfalls!

Don't find yourself S.O.L with your S.O.A!

Software architects, developers, and project managers who've worked "in the trenches" of SOA design and implementation over the last few years have learned some hard and valuable lessons. Some of these lessons can help you avoid the serious traps and pitfalls associated with SOA design and implementation. Most of the gotchas that can run your SOA project into the ground are issues that can be addressed early in your project and revolve around proper project management and planning, architecture, and design.

This article offers seven guidelines for keeping your SOA projects on track, based on lessons learned in past SOA projects. Ignore them and you may find yourself S.O.L (SOA Outta Luck)!

1.  Understand the Requirements and Manage Expectations
Proper requirements analysis techniques aren't unique to SOA, but they should be mentioned, because this is where you run the greatest risk of failure. For any project, requirements analysis, communication, and project planning are vital. To build and deploy a SOA properly, you must understand the enterprise requirements, you must know what has to be done technically, and you must understand the business processes, current policies, and current infrastructure of the organization(s) involved to meet their needs. The bottom line is - you can't solve somebody's problems if you don't know what they are.

Throughout your project, you should be in constant dialogue with your customer. Manage expectations by letting the customer know what benefits a Service-Oriented Enterprise (SOE) will bring, but also let him know that SOA won't magically bring world peace or solve all their problems! If there are problems with the organization's business processes, these have to be addressed first. Otherwise, they'll blame you and the SOA.

If you take the time to listen to your customer and ask the right questions, you'll be in a better position to deliver a solid solution. Based on the requirements you collect in this phase, you'll know what to plan for in your project. Enterprise standards, SOA management and governance techniques, business process management, security methodology, performance requirements, and scalability requirements all evolve from the initial requirements phase.

2.  Restructure Your Development Organization by Service Area and Application
Traditional development organizations are typically stove-piped application teams that develop the end-to-end functionality for an entire end-user application. This leads to duplicate functionality so separate your development organization into services teams and application teams.

Services teams develop the services that expose related functionality for a specific area of the business. The services they design and develop may be fine-grained, such as an inventory update service, or business process services that aggregate many of these fine-grained services, such as a service that creates a purchase order.

Application teams develop the user interfaces and business processes for the end-user solutions needed in various areas of the business. These interfaces and business processes consume the services developed by the services teams.

Structuring your organization this way provides several benefits. First, you have one services team creating services that can be used by every application that needs this functionality, promoting service reuse. Second, each services team becomes a mini "center of excellence" in the area it's focused on. If you need to update product inventory in your specific application, for example, you have one team to talk to. Third, each functional area is centralized. If supply chain business processes have to be changed, the services team responsible for this area of the business can make the changes in its set of services, and these service changes get automatically propagated to each application using them. Restructuring your teams this way realizes the benefits of service reuse, forcing loose coupling between the user interfaces and business logic in your enterprise applications.

3.  Create a Standards-Based Infrastructure
A common pitfall related to building Service Oriented Architectures occurs, when developers focus exclusively on standing up Web Services for each application, missing the "big picture." This focus leads to creating a large number of services that speak a different language (i.e., a SOAP message schema), providing no infrastructure to manage the provisioning and lifecycle of these Web Services, providing no auditing capabilities, and failing to use the same service standards versions. This situation is the equivalent of "spaghetti code" in traditional applications. Here we'll call them "spaghetti services."

A solution to spaghetti services is the Enterprise Service Bus (ESB). There's been a lot of industry debate about what an ESB is and isn't, and whether or not an ESB is required in an enterprise SOA. For purposes of this article, an ESB is a distributed infrastructure that's based on existing service standards and provides the means to:

a)  create a single implementation of your organization's "plumbing" services, such as message routing, message security (i.e., single sign-on, non-repudiation, etc.), multi-service transactions, and guaranteed message delivery;
b)  provide a canonical message schema that lets any application easily "plug in" to the ESB and talk to other applications that are already plugged in;
c)  provide the message transformations necessary for application-specific data to be transformed into the canonical message schema;
d)  monitor and audit all message traffic to provide network administrators with accurate metrics, complete visibility into how the services are being used, and how performance can be tuned.

Using a distributed ESB also allows application teams to plug in to the enterprise SOA with the best tools for their specific applications. So, an application team can choose .NET, J2EE, Ruby, C++, or any other tool as long as it supports the defined service standards.

4.  Create a Multi-Layered Services Architecture
There's one thing as sure as death and taxes: requirements change (...and change ...and change again). A multi-layered approach to your Service Oriented Architecture can help you isolate yourself from these constant changes. Define fine-grained services that provide exactly one function (say, calculate shipping costs) and higher-level services that aggregate these fine-grained services into course-grained business processes using BPML/BPEL (for example, create purchase orders). This will allow your business processes to change more easily when your business changes by allowing the coarse-grained services to aggregate different fine-grained services into the process and/or change the order in which these fine-grained services are called.

When you separate services into multiple layers, you can make the most of object-oriented design patterns. The Session Façade J2EE design pattern and the "Gang of Four" Mediator design pattern are two design solutions that map very well to Web Services. These two design patterns can be used to allow higher-level business services to centralize, control, and coordinate complex interactions with lower-level, fine-grained services. Separating your services into multiple layers will make your architecture more flexible and manageable.

5.  Design Interfaces for Flexibility
Architectural flexibility revolves around the design of your interfaces. Here's where well-intentioned developers go wrong:

  • Putting SOAP on Top of a Stove Pipe: Many poor excuses for "SOA implementations" just put SOAP abstractions on top of existing poorly designed stove-piped applications, mapping legacy interfaces to service interfaces one-to-one. Putting a Web Service wrapper around a brittle application with tight interdependencies is like putting lipstick on a pig, and when you do this, you miss the point of SOA. If you have to use an existing system, use only components of that system and take the time to rewrite the interfaces.
  • Implementation Details Tightly Coupled to Implementation: It's important never to expose the storage mechanisms or implementation details of your services in the interfaces, and it's important to focus on standard schemas when defining your interfaces. If you have a Web Service method called "insertTieValueIntoTargetTableThree," for example, it will be impossible for someone who doesn't know the internal database schema to use your Web Service correctly. For that matter, if you ever migrated to a different database or changed your schema, you'd change your SOAP interfaces as well. Maintainability and version management could be nightmare in your SOA.
  • Lazy Web Service Generation: Using point-and-click developer tools that automatically turn your current application's objects into Web Services may be convenient and easy-to-use, but if the methods in your objects are poorly designed, you may be deploying non-intuitive WSDL. That's why you should use standard enterprise schemas in doc/literal SOAP messages.
It's important to plan to be flexible, and designing your interfaces properly will lead to architectural flexibility. Design your interfaces knowing that the implementations could change. Services should be loosely coupled and standards-compliant.

6.  Design Your Services with Purpose, Expecting the Unexpected
Make the point of your Web Services simple, intuitive, and clear, so the results and consequences of the service calls are well known. Don't make assumptions on how they will be used - instead, design them so that the effects of calling them are clearly defined. Relating to Rule 4 (Create a Multi-Layered Services Architecture), both higher-level services and lower-level services should be clearly defined and described as such in a service registry.

Since Web Services are "black boxes" with published interfaces, they'll be called and used together in ways that we may not anticipate. In an earlier article that I wrote this year ("Six Basic Rules for Securing SOA-Based Projects" in the October issue of the SOA/Web Services Journal), I mentioned a previous SOA project I was involved in where the SOAP faults didn't contain data about the Web Services in which errors occurred. When end-user applications call Web Services that call other Web Services that combine the results of other Web Services, it will be incredibly hard to troubleshoot your enterprise applications if you don't know where the SOAP faults are coming from. This is one example, but it demonstrates what can happen in a dynamic Web Services environment. Expect orchestration, expect Web Service chaining, and embrace the fact that your services will be used in ways that you may not have thought of. If you've planned for this, you'll avoid a lot of the traps that can cause chaos.

7.  Plan for Scalability and Performance
At the end of the day, the users of your enterprise applications probably won't care that a SOA is in place. Users want functionality, and they don't want their applications to run at a snail's pace. As a result, your deployed systems will have to scale to meet the load required by the intended number of applications and end users. Enterprise architects will need to analyze the scalability requirements and start planning at design time, because the risks of not planning for scalability are huge - exposing a SOA to an organization that can't handle the load promises to ruin your entire project. Some of the issues here involve estimating service usage patterns, scalability planning for data resources, managing session state, and planning for security requirements that may involve CPU-intensive cryptography.

Certainly, there are off-the-shelf products that aid in scaling simple stateless services, and some ESBs come pre-packaged with scalability options. If you need strong cryptography, you may want to consider using a hardware appliance to offload cryptographic and XML processing. Depending on your requirements, you may also want to look at using a grid computing platform that's inherently scalable and robust. As you can see, there are many choices as you plan for scalability. All of these choices, however, are dependent on understanding the true requirements (see Rule 1), and involve planning up front. Don't wait until the end of the project to try to "fix" scalability and performance issues - trying to retrofit scalability into your SOA can cost more time and money than the initial implementation!

Conclusion
This article has focused on best practices in SOA project planning, design, and implementation, and we have provided seven guidelines to help keep your SOA projects on track. Some of these guidelines (Rule 1 and Rule 7) focus on understanding the requirements, customer expectations, and enterprise application use, so that your SOA is purpose-driven and meets the needs of the users and applications in your enterprise. Other guidelines revolve around forming a successful development team's structure (Rule 2), using a standard SOA infrastructure (Rule 3), and important design guidelines for building services (Rules 4, 5, and 6). If you plan and architect your projects with these guidelines in mind, you'll find yourself in SOA's sweet spot, realizing the benefits of what SOA can truly provide.

More Stories By Kevin Smith

Kevin T. Smith is a technical director at McDonald Bradley, where he leads the SOA and Semantics Security Team (S3T) focusing on securing Web services for multiple projects. An author of several technology books on XML, Web services, Java development, and the Semantic Web, he is a frequent speaker at many conferences, such as JavaOne, OMG Web Services, Association for Enterprise Integration (AFEI), and Net-Centric Warfare.

More Stories By Lou Blick

Lou Blick is a SOA Architect at a large, multinational consulting firm, where he focuses on the design and development of Service Oriented Architecture for a number of civilian, intelligence, and military organizations in the federal government. He was a member of the team at Celera Genomics that sequenced the Human Genome, where he helped design and build scientific applications for visualizing and researching the information contained in the genomic sequence.

Comments (1)

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.


Microservices Articles
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
"NetApp's vision is how we help organizations manage data - delivering the right data in the right place, in the right time, to the people who need it, and doing it agnostic to what the platform is," explained Josh Atwell, Developer Advocate for NetApp, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, will discuss why containers should be paired with new architectural practices such as microservices ra...
In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
The Software Defined Data Center (SDDC), which enables organizations to seamlessly run in a hybrid cloud model (public + private cloud), is here to stay. IDC estimates that the software-defined networking market will be valued at $3.7 billion by 2016. Security is a key component and benefit of the SDDC, and offers an opportunity to build security 'from the ground up' and weave it into the environment from day one. In his session at 16th Cloud Expo, Reuven Harrison, CTO and Co-Founder of Tufin, ...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...
Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again. Unfortunately, we've seen this movie before, and we know how it ends: badly.
TCP (Transmission Control Protocol) is a common and reliable transmission protocol on the Internet. TCP was introduced in the 70s by Stanford University for US Defense to establish connectivity between distributed systems to maintain a backup of defense information. At the time, TCP was introduced to communicate amongst a selected set of devices for a smaller dataset over shorter distances. As the Internet evolved, however, the number of applications and users, and the types of data accessed and...