SOAP

Agility seems to be the buzzword du jour. There are "agile enterprises," "agile manifestos," "agile programmers," and "agile architectures." Slap "agile" in front of just about anything and marketers believe it will sell better. Yet, one of the primary goals of using service-based architectures was to create "agile systems." This begs the question, was it just marketing or is there something to it?

Let's cut to the chase. If you are responsible for a system and a user requests a change to that system, how long will it take to make the change and move the revised system back into production? If it takes a long time, then your system probably isn't agile. If you can do it in a matter of days - well then you have agility! Marketing bologna aside, agility is directly related to the time and effort required to create new functions or to modify existing functions - and then to re-release those functions to the customers.

Small systems are usually agile. As systems grow in size and the dependencies increase, it becomes hard to make changes and re-release. Service-oriented architectures (SOA) are thought to hold the potential to improve this scenario, but do they? More important, does your instantiation of an SOA provide agility?

Finding the Problem
Imagine a system with 100 parts. Pick a random number from 1 to 100. The number you chose was the part that needed to be changed. How many other parts used that part? How many did it use? In a random world we say that statistically all changes are equal; however, the world isn't random.

Take a software system that has been in production for an extended period of time and review all of the user-initiated change requests. Create categories for the changes, such as:

• Create a new system function/capability
• Capture new data in an existing function
• Add or change a business rule

Then, determine where the time was actually spent, for instance:

• Updating requirements, documents, and specifications
• Locating the responsible code
• Making the code changes
• Building the system
• Testing the changes
• Redeploying the system

Now, add services to the mix and rerun your "change requests" to see if your situation improves. Today, for most organizations, the agility isn't increased - in fact it dramatically worsens. Why? It can be summed up as follows:

• Developers don't have the proper SOA tools
• Developers aren't designing the services properly
• Developers aren't building the composite application "loosely"
• Some systems are not good candidates for SOA-infused agility

Agility and Tooling
Just when most developers were getting efficient at using their platform tooling (Visual Studio, Eclipse, etc.), a whole new set of service-oriented opportunities surfaced. For the last several years the open source community and leading vendors have rushed to bring new tools to the market. However, many organizations have been slow to adopt tools that facilitate SOA. Does your organization have standardized tools for:

• Creating XML Schemas and WSDLs?
• Rapid Service Development (contract first)?
• Intermediary-based routing and mediation?
• A registry of services? A repository of service metadata?
• Automated service testing?

Obviously, this is only a partial list of the tools needed to be productive in a service-oriented environment. The point is, don't expect developers to be productive in an SOA environment using last-generation tools. It won't happen.

Agility Techniques
Having the right tools is an easy way to increase productivity, but it will only get you so far. Ultimately, we must come back to the techniques we use to create the services, combine them, and redeploy them.

Agile Service Design
Designing services is no easy task. We are faced with many of the same questions that we saw in object-oriented design: How do we design services so that they can be easily maintained? How do we refactor for reuse? We are also faced with new questions such as, "How do we keep our platform-to-schema bindings synchronized?"

With regard to refactoring for reuse, it is clear that we must implement the same basic rules of commonality that we applied to object-oriented design - that is, using Venn diagrams to identify commonality and carve it out. It is clear that "fat services," or services that contain too much logic, are likely to have lots of change requests issued against them. This has a ripple effect that causes the entire service to be versioned as well as all of the clients, depending on that service to be versioned. This doesn't sound very agile, does it?

Alternatively, server-side code that is specific to a client can be refactored into a service that reduces the impact of changes required by a client. The goal is to reduce the impact of a change while leveraging common code. If we refactor our scenario into four services (one common and three services containing client-specific features), we are able to preserve the reuse and reduce the impact of making a change.

Now we all know that this type of extension mechanism won't always work. Luckily, the software community has seen this type of problem on more than one occasion and the design patterns to remedy the variations of this problem are abundant. For virtually every "Gang of Four" pattern that discussed an object-oriented solution, there is a minor modification that can be applied to create a service-oriented variation. Remember though, on occasion - the answer isn't service-oriented at all. Don't go throwing out your favorite OO patterns and trying to solve problems in a service-oriented way. Services are a mechanism to complement your current bag of tricks. Implementing best practices in design (service, object, or otherwise) is essential to creating systems that are easily modifiable.

Composite Applications
Service-oriented systems are composed of three primary elements: the service infrastructure (SOAP routers, firewalls, etc.), the services, and the clients. However, there is a special breed of the client that is worth observing - the composite application. In loosely coupled systems, we identify certain portions of the system that seem to pull it all together. Aside from executing the business services, composite applications interact with the user interface and external gateways. The composite application is the brain of the service-oriented system.

Composite solutions focus on three different areas: agile controllers, reflective metadata, and WYSIWYG/RAD.

Agile Controllers
The agile controller is a piece of business logic that dictates business logic relative to code that is likely to change. Typically, agile controllers focus on the flow of information between humans (workflow) or systems (orchestration). The goal of the agile controller is to give the programmer an easy way to make a change to the portion of the code that is most likely to change!

Reflective Metadata
As the enterprise continues to refactor substrate out of applications and put it in common infrastructure, it becomes more important to gain access to that infrastructure. Modern enterprise IDEs place a significant emphasis on accessing enterprise metadata - everything from simple WSDLs to semantic message descriptions and run-time policies. Metadata is the new data.