Java SOA Cookbook

Introduction

This chapter briefly introduces the landscape of service-oriented architecture (SOA) and illustrates some organizational challenges that SOA can precipitate. While you are likely familiar with a variety of SOA definitions, the solutions outlined in this book—and indeed, the construction of the book itself—are in some part predicated on a specific understanding of how we define the various constituent parts of SOA.

Heterogeneity is a fact of life in the modern IT landscape. There are hundreds of programming languages in the world, all used to write applications that populate the modern enterprise. Sometimes you need these applications to talk to each other, which can become a tricky proposition very quickly.

Aging systems written in languages with waning platform support must work in conjunction with applications written in disparate modern languages. These systems may have many apparent warts and wrinkles, and it may be tempting to simply rip out the systems and replace them. This can be prohibitively expensive, however, and rarely goes as smoothly as originally envisioned. It can also make you very vulnerable from an operational standpoint. These applications have stood the test of time. They have been vetted in the battlefield of daily use. And while we would like for our systems to look as neat and tidy as possible, many times what naive developers see as code sprawl is simply the reality of handling the many twists and turns and exceptional cases that the real world demands our applications account for.

There certainly is plenty of bad code in the world that isn’t worth saving. Many legacy applications were written with principles in mind that have since changed dramatically. Sometimes well-intentioned programs are written in such a snaky way that it can be very difficult to reuse them in other applications. But for those legacy applications that are mission-critical, that serve as the backbone of an organization, there is a way to modernize, reuse, and enhance their power.

By wrapping legacy systems with web services that operate within the supporting framework of a service-oriented architecture, you buy yourself time. This extension of time comes in the form of vendor neutrality, which allows you to defer migration decisions, or simply extend the life of aging but otherwise solid software.

Mergers and acquisitions can very quickly create integration problems. Heterogeneous platforms with potentially redundant or overlapping functionality can undermine the agility, responsiveness, and service delivery capability of an organization. In the web-based world of global commerce, no opportunity remains for stop-the-world migrations, and the “Sunday at 3 a.m.” cut-over opportunity is more costly than ever.

SOA represents a way to seize new business opportunities and reduce time to market by embracing, rather than denying, differences in your organization. Perhaps it is not necessary to rip out and replace these legacy applications, or throw yourself at the mercy of a vendor, signing up in desperation for their entire unified stack in the hopes that you will never again have this kind of problem. A service-oriented architecture allows you to address your integration needs in an evolutionary, rather than revolutionary, way.

An evolution toward services seeks to align the work of IT more closely with business goals and ensure that the enterprise is responsive to change and ready to tackle new opportunities.

The problems and solutions presented in this chapter offer some prescriptive solutions with the intention of starting you down a good road; they are subject to modification as appropriate within your environment. The scenarios are more general and subjective than you are probably used to seeing in a cookbook. Because SOA represents a kind of architecture, it is useful for developers to understand the larger business context in which the services they create will operate. In order to realize the benefits of SOA, and to code meaningful services that offer real business value, any given service implementation needs to work harmoniously with defined overarching business goals.

The recipes in this chapter do not have code-based solutions. They are presented as conceptual challenges that apply across implementations. While it is possible for a Java developer to skip this chapter altogether and jump into code with the next chapter, within an SOA it’s very useful for developers to think like architects, and vice versa. In fact, depending on the size and structure of an organization, these roles are sometimes even collapsed altogether. Whether or not this is the case for your organization, it is advantageous to use the recipes in this chapter to define common terms as a foundation for the remainder of the work in this book.

Defining a Service

Problem

What is a service?

Solution

A service is a software component with the following properties:

It is defined by an interface that may be platform-independent.
It is available across a network.
The operations defined in the interface carry out business functions by operating on business objects.
Its interface and its implementation can be decorated with extensions that come into effect at runtime.

A service can mean other things as well. Sometimes the definition is broader, to include, for example, a distributed component whose interface is designed by the business. Sometimes the definition is more narrow, such as a SOAP-based web service.

Discussion

One initial difficulty in approaching SOA is that people don’t always agree on what is meant by its fundamental building block, the service. Many definitions of a service refer to slippery or very abstract concepts, such as “adaptability” and “agility,” that are too vague to be useful to the developer. Presumably, given the choice, no one wants to make unadaptable, leaden software that doesn’t meet business needs. But the fact of the matter is that, despite best efforts, this happens all too often. Knowing that SOAs should be “adaptable” and “agile” may be laudable, but that alone doesn’t help make a state change. Let’s unpack these terms a bit.

Other definitions are too narrow for the real world. It is tempting, for example, to indicate that a service must be a software component that talks SOAP. But this limitation is artificial; there are many practitioners using REST who believe, quite reasonably, that they are doing services. Perhaps our definition should include something about messages being XML-based, as this is a common denominator between RESTful web services and SOAP-based services. But this is also too limiting for a general definition.

So how do you arrive at a definition that is specific enough to be useful and yet general enough to admit the wide variety of approaches that people take in the real world?

Let’s examine each aspect of the service definition before proceeding.

Platform-independent interface

The work a service can do must be described with an external interface. Some architects allow that such an interface can actually be tied to a specific platform, as in the case of a Java interface describing the operations on a remote session EJB. Services can certainly be approached in this manner, and such an approach may be justified within a given business context. Dictating that consumers must use a certain platform, such as Java or .NET, to consume a service can save valuable time and money and drastically simplify your implementation.

Many SOAs operate within a company, behind a firewall, in a known environment that is relatively static. I have talked with architects in such circumstances whose entire SOA is defined on EJB. That’s a very specific platform, and they think they are doing SOA, and they are smart and experienced people.

Their view is that it would introduce unwarranted developer effort, offer more complexity than benefit, and garner unnecessary runtime overhead to use SOAP and its many attendant specifications given their business context. So while many authors are tempted to indicate that a service must be defined in a manner that does not dictate platform, and while that sort of service is the chief topic of this book, my definition does allow for platform-specific implementations.

However, a service is generally created to address a systems integration problem, or at least has an eye toward integration issues. A WSDL is one way to describe functionality in a way that does not dictate implementation. While WSDLs may commonly use SOAP over HTTP, this is not a requirement; other protocols can be used for bindings, and the same abstract WSDL can address a variety of bindings, offering even greater flexibility.

HTTP is perhaps not the ideal transport layer for web-based services, but its simplicity and pervasiveness have made it the default choice. Consequently, there is considerable support for such service implementations.

RESTful web services use XML and native HTTP methods to define their interfaces, and this approach has many proponents who cite the complexity and “bloat” of SOAP-based services. I want to avoid this argument for now, and just indicate that REST sufficiently satisfies the condition of platform independence. It is less clear that it satisfies an emphatic interface that can operate as part of a service contract, however.

Because a service is not merely a piece of functionality, but something describable by a contract that constrains consumers, it is important that a clearly defined interface work within contract automation. Without a clear interface, service reusability opportunities shrink. Without platform independence, possible consumers go down and service components become more tightly coupled.

Of course, nothing is free, and you pay for platform independence with performance and complexity.

Available across a network

The world is filled with very useful programs whose functions can be invoked only from within the same virtual machine or within the same physical machines. These programs simply do not qualify as services. Just as in the real world, your customers have to be able to contact your business to contract for your cleaning or consulting or catering services. If you’re the only one who knows your phone number, or if you don’t have a phone, then there’s no show. If your function is not available remotely, it is simply not a service.

Operates on business objects

My third criterion for a service is that it generally carries out business functions, and generally does so by operating on business documents. What does this mean? A calculator that adds two numbers together may not be a good candidate for a service because integers are not business objects. They can never be defined in a particular way for your organization.

A “business object” means an instance of an entity in your business domain, such as a Customer, a Product, an Invoice, a Student, or an Application for Employment. You can decide for yourself what these will mean, as they are the entities that differentiate your business from others. Further examination of your add operation must question whether the idea of adding is particular to your business. It is not. Anyone in the world can add all day long, and will do so (presupposing any basic mastery of the task) in a manner identical to everyone else. Moreover, you have no opportunity for innovation in the method in which you add; you cannot conceive of and employ some custom scheme for adding within your operation’s implementation to gain a competitive advantage in the market. Unless you have a very creative accounting department, you don’t decide for yourself what integers and adding mean.

There is certainly a wide array of popular services publicly available that operate on facts. These include determining the distance from one location to another, or performing calculations such as shipping costs based on weight, or finding the location of the nearest store. While a zip code or a weight in ounces may not in themselves appear to be business objects, such services do perform a business operation that is distinguishable from something absolutely generic such as adding two numbers together.

This is just a general guideline. Consider a service that converts currency. There are many such publicly available web services, and a euro is the same for everyone, so these don’t appear to be business objects. But there is always the matter of perspective. At a bank, the idea of currency might be considerably more detailed in its definition than it is at a pet food store, making it a kind of business object to the bank.

Note

There are always exceptions to the rule. The idea here is to think in terms of services exchanging business documents, rather than accepting lists of simple values.

You probably don’t need an SOA if you don’t have a business of some size, or at least of some length of history. While programmers might enjoy writing a video game for their own personal use, no one builds an SOA out in the garage on Saturday afternoons. If you’re talking about an SOA, you’re talking about a business of some measure. And your SOA will realize its potential ROI (return on investment) if its constituent services operate at the appropriate level of granularity in order to maximize their reuse. Of course, this begs the question what is meant by “appropriate level.” That will depend on the business processes that define your services, and what related processes might be able to reuse them.

I must stress that this guideline is open to a wide variety of interpretations, and is presented as a starting point so that you can make some distinctions. You want to avoid being so vague that you do not have enough to work with. Indeed, there are utility or functional services that operate in the realm of technology alone; these are described in Identifying Service Candidates.

Decoratable

This refers to the idea that you must be able to decorate the service operation in some way in order to provide for functional and non-functional requirements. It is this aspect that elevates the service to something meaningful with an SOA.

If you are using SOAP, a variety of WS-* specifications (such as WS-ReliableMessaging or WS-SecureConversation) add capabilities to your service that do not impact the core business functionality, but make your service adaptable for use within an SOA. The ability to add HTTP headers, for example, is one way of decorating a REST-based service implementation. EJBs make the cut because, while the mechanism is not based on WS-* standards, interceptors do allow for decoration of like functionality.

The point here is that you want to be able to provision your SOA, and by necessity its constituent services, with technical means of governance (which we will discuss later). You want to be able to include policies at runtime that augment how the service can be used. The ability to interact securely, to allow for transactional operations, and, in some cases, to accept monitoring instrumentation are non-functional requirements that bridge the gap between a theoretically pure implementation of your Invoice Processing service and the real world that involves this particular network with these external constraints that must be accounted for. Baking such items into your service can severely curtail or obliterate its possibilities for reuse, especially in federated environments. But the need to deal with them remains; when possible, move such requirements into decorators.

This requirement may guide your choice of platform or implementation. The fact that there are so many non-functional requirements that so often come into play in software components (and the fact that so many of them are recognized by WS-* specifications) is a leading reason why I have chosen to focus on SOAP-based services in this book (and in building a real-world SOA). To have such common requirements dealt with in a standard way within these specs offers a boost to interoperability and maintainability, and allows developers to focus on their business problem.

Other considerations

What else might be true of the operation if it is to qualify as a service? It seems that a service is worth all the trouble to define and create only if it will be reused. A chief aim of SOA is that its components are self-contained and do not represent overlapping functionality. Its components should provide a degree of reusability. That is, they must not be limited to a narrowly defined business context that has little or no relevance elsewhere in the enterprise. It is possible that you will write a service that does not get reused. It is possible that your business will change directions, or that a service is too poorly defined, either too granular or too broad in scope, to ever fit into another use case. Sniffing out such matters is where architects are valuable.

Some architects will add the requirement that a service must be stateless. I agree that in general it is a good idea to ensure that your service operations are stateless, but I would not require it as a defining feature of services. If they must maintain state, they can do so externally through a database or other temporary serialization mechanism. Conversational state is often best avoided if possible, but when it must be maintained within the service composition, it can be handled through a specification such as WS-SecureConversation and WS-Conversation. This is a spec that has been around for a few years now, and is implemented in containers like WebLogic 10gR3.

Defining SOA

Problem

The term “SOA” is surrounded by hype, hyperbole, and generality. You want a definition that you can work with.

Solution

You must define SOA with some modicum of care before proceeding in order to set expectations appropriately. This is made somewhat difficult given the avalanche of hype surrounding SOA in recent years. But it can be done. There are many possible definitions of SOA. Here is my offering:

SOA is a kind of architecture that uses services as building blocks to facilitate enterprise integration and component reuse through loose coupling.

Let’s unpack that a little bit, shall we?

SOA is a kind of architecture

While this is perhaps overstating the obvious, there is a small lesson here. Simply creating a set of services does not automatically render an architecture. Architecture, while it should guide the creation of services, is a diverse matter separate from the implementation of the services themselves.

In the term “SOA,” “service-oriented” modifies “architecture” as an adjective. That is, an SOA describes a sort of architecture one can undertake. It is not a development mode. You cannot simply annotate an EJB to indicate that it’s a web service and decide that because you now have a web service, you must have the felicitous beginnings of an SOA. If you are not very careful with your approach, you could indeed have the beginnings of a very elaborate, very expensive mess.

One point that must be made is that you cannot simply buy an SOA. You cannot expect a single vendor to hand over an SOA once your CIO writes a check. Building an SOA involves considerable analysis and integration.

SOA is built with services

This is the “service” part of “service-oriented architecture” and I rely here on my definition in Defining a Service. It’s not an SOA if it’s not an architecture, or if that architecture doesn’t use the service as the common unit of measure (just as an object-oriented system uses the object or class as its common unit).

Without services, there is nothing to build on, monitor, or govern, and nothing to execute to provide your business value. But at the other extreme, one can labor long and hard, producing a perfectly lovely set of architectural diagrams with little relation to the real world. If you focus narrowly on cranking out a set of service implementations and forget the architecture—or, more likely, leave it out on purpose while dismissing the “astronaut architects” with their heads in the clouds—you will not only have no SOA, but you’ll have something even worse. You will have spent considerable time and money over-engineering a solution to the wrong problem. There is actually a name for this sort of furious work: the anti-pattern known colloquially as Just a Bunch of Web Services (JaBoWS). In addition, cowboy developers operating without architectural guides can inadvertently cause the business to fall prey to another SOA anti-pattern: Rogue Service, wherein there are services operating on the network that are not part of the known, governed set of services in the catalog. So a bunch of services without architecture or governance does not an SOA make.

In my view, it is debatable whether a “service” that is wholly outside the context of an architecture is actually a service at all. It is in part the contextual role within a supporting architecture that elevates an operation to the level of a service. This status is afforded, but not directly stated, by the last criterion in my definition of a service: it can be decorated with runtime extensions that handle certain technical non-functional requirements.

SOA facilitates integration

SOA represents a way of thinking about systems integration. An SOA serves to offer increased or new business functionality or opportunities by connecting multiple systems together. In its most straightforward form, this means that you can do B2B work more quickly.

CORBA, connector architecture, EDI, and point-to-point EAI efforts over decades have all demonstrated the ability to integrate diverse systems. But such efforts can be costly and brittle. They can distract developers and IT departments from addressing their real business problems, as they work for months getting systems to talk. These solutions all define their own formats for message exchange. SOA, in general, reuses XML as a standard means of message format, allowing integration efforts to leap into action more readily.

Some CIOs, in frustration with previous EAI projects and in an honest attempt to address their problems quickly and decisively, have thrown in the towel, called up their favorite vendor, and signed up for their entire stack in an attempt to avoid the integration problem altogether. But this can be a very expensive proposition indeed and it has the drawback of tying your organization to that vendor, locking you into operating on their time tables, and you’ll be able to provide only the functionality they expose.

So while integration happens, SOA attempts to address the pain points of integration efforts.

SOA facilitates reuse through loose coupling

The idea that SOA facilitates reuse through loose coupling is a key modification of the point that it simply supports enterprise integration efforts. SOA suggests two distinct ideas: it facilitates reuse in the first place, and it does so by creating loosely coupled components.

Early enterprise integration or primitive service provider efforts have not focused quite so specifically on the idea of reuse. But it is now possible, given the new standards and the employment of a generic format such as XML in message exchanges, to realize enterprise services in a sufficiently general way that services can be reused.

This reuse can come in the form of general interoperability. If two software components can interoperate, that in no way means they are loosely coupled. But loosely coupled components have a greater chance of interoperating.

Note

One of the foundational aspects of SOA is that services are created from the ground up with the intention of having them interoperate with unforeseen or unknown components. This makes a sharp distinction from typical integration efforts, which likely target a single set of known interfaces.

While reuse can be achieved as a side effect of ensuring that your services are loosely coupled, it is not a necessary aim for every service. It is possible that you have certain services that you know have little likelihood of being reused in a composition or within an unforeseen business context. Such services may have been created as pilot projects; or it may have made sense given the circumstances to create some functionality as a service in order to tap into a larger architectural infrastructure to make it more visible, for example, through a service inventory; or to take advantage of centralized schemas; or to quickly gain runtime metrics afforded by SOA monitoring tools.

Reuse is not strictly necessary within any given service. However, an SOA entirely populated by non-reusable components is likely not an SOA at all, but rather a fancy, bloated, over-engineered collection of point-to-point EAI dinosaur bones.

Invoking services

Be careful allowing a service to directly invoke another service (that is, to have itself be the client of that service), as this can strikingly reduce the business contexts available for reusing the service. Sometimes it seems necessary to make one service the client of another service within its implementation. But you are introducing a degree of coupling here that you might not want later. If you find yourself in this situation, consider using an orchestration technology such as BPEL (covered in Chapters 9 and 10).

Also, it can be difficult without service-level agreement (SLA) monitoring software and metrics in place to keep track of how much traffic a service is receiving from where. If your service crosses business domains, it becomes particularly important to consider that it could see sudden, unexpected explosions in traffic due to compositions external to your current subject. Another problem with direct invocation is that it adds complexity to your topography without allowing visibility through tools. There are tools by the big SOA suite vendors that show dependencies across the service-related resources stored in your enterprise repository, but they can be very expensive.

The architectural solution to this problem is that when you want to have one service directly invoke another, consider whether you can create an orchestration (or process service, as defined in Identifying Different Kinds of Services) instead. As a service wraps a system or subsystem, an orchestration wraps a set of services that together make a flow. But the orchestration is itself exposed as a service, so it looks just like any other service to the client.

Other considerations

An SOA will mean something different to different organizations, and I encourage you to consider your specific definition and decide what elements to emphasize within your own business context and its attendant constraints.

Identifying Service Candidates

Problem

You need to identify whether or not a proposed software project makes a good candidate for a service. This process is sometimes called “service discovery” or “service elicitation.”

Solution

Start from the top down or the bottom up to zero in on a set of possible candidates, and know that you will likely approach development from the middle out, according to business process requirements.

Recalling that the term “service” does not imply any specific implementation platform, a proposed piece of software might be a good service candidate if you can affirm at least some of the following criteria:

Could this functionality be appropriately designed to satisfy the definition of a service as stated in this chapter?
Is this service likely to be consumed across multiple platforms? Does it need to interoperate? Would external business partners have any use for this service? Does it need to cross functional barriers or firewalls? Can it use a popular protocol such as HTTP or SMTP?
Would implementing this functionality as a service help you break an integration barrier? Would it wrap or replace a proprietary point-to-point interface? Would it operate in front of ERP, CRM, financial applications, or other systems?
Does it clearly map to one or more business processes? Or is it simply a program? (It is generally accepted that services can map to a single process, but mapping to more than one process can offer more opportunities for reuse.)
Does the function that the proposed service represents cross business domains? This could point to a greater opportunity for reuse.
Does the service exchange business documents or fall readily into one of the three general service categories identified in Identifying Different Kinds of Services.
Would a business person be interested in reports on the output of this service? Would IT be interested in monitoring its life cycle or runtime? Or perhaps it represents a functional or utility service that in the long term could increase general business agility. (If none of these, it may be too small an operation to merit a place in the service catalog.)
Does it offer business value? Is there an existing service commodity that already performs this function?
Is the proposed service the right level of granularity? (If it is very fine-grained, this will weaken the interface aspect of the contract, shrink the possibility of reuse, and promote undue chattiness. If it is very coarse-grained, it could be a candidate for a process service that decomposes into other entity or functional services.)
Would making this function a service allow it to be composable? That is, can it participate as a seamless blackbox with other services behind a unifying contract (like an orchestration)? Or does it represent just an isolated function, with little relation to other system components?
Does the candidate represent an idea with an identifiable life cycle? Can the business define the interface?
Is it advantageous if the software can be discovered dynamically (as from a registry/repository)?
Does it present an opportunity to aid in the goal of providing a “single version of the truth”?
Depending on the implementation, would the benefit derived from using XML to represent your data outweigh the performance hit for marshaling and unmarshaling to and from XML? Is human-readability of the documents exchanged a factor?
Would implementing this as a service lower the cost of future integration projects? Would it facilitate new products or business services?

Again, these are just points to consider. There are no hard-and-fast rules in this area. The idea is to make sure that you don’t run out and make everything into a service. I know of companies that did this years ago; they now have more than 5,000 “services” and they’re in a lot of pain. Just use this as a guideline.

Discussion

Not everything in your enterprise can or should be made a service. Do not fall into the “tool trap”: if you have a hammer, everything looks like a nail. There are many real and important problems that services and SOA simply do not address. Once you have established SOA as a goal within your organization, it may be tempting to declare that every new project coming down the pike should be written as a service. This is not going to aid in the creation of a functioning SOA that gives you a real return on investment in the long run. It will, however, start the process of building out Just a Bunch of Web Services, the anti-pattern mentioned earlier.

But the fact of the matter is that you do have some services to build, and some SOA infrastructure to get in place, and so the question remains: “How will I know a service candidate when I see one?” As you start building out your service catalog, it is important to have solid criteria for determining what should and should not be a service.

It is important to conduct interviews with business segment leaders and use other information gathering techniques to understand the business models that you will use as the basis of your service elicitation analysis. Ultimately, such models will be the real key to deriving service candidates. It is this model that can be iteratively refactored in order to determine if the appropriate boundaries have been defined for the service, and that it meets an appropriate level of granularity.

As you begin to populate your service catalog, and through the life of your SOA, there are two basic approaches that you can use in analyzing and assessing your enterprise to discover service candidates.

While the checklist just shown features a number of useful questions, it should be viewed only as a guideline. When you as a developer/architect are asked to determine if some proposed software should be written as a service, refer back to this checklist, and you’ll be well on your way. In time, you will likely start to tailor your own set of criteria.

Now let’s turn to the matter of how to approach discovering service opportunities within your organization.

Top-down or bottom-up approach

A top-down approach starts from a high-level business view. Using this approach, you examine a road map laid out by the business that sets established business goals for a given time frame. You then evaluate the goals for potential service creation. This is not a process that simply maps a list of prioritized business projects directly to services. It requires instead that you use existing architectural documents and business process modeling techniques to determine what in your enterprise would make the most sense if written as a service.

The architects, CTO, CIO, or other responsible party in your organization should have an IT roadmap that is based directly on a business roadmap. That roadmap may exist at various levels of granularity or span a variety of timelines or departments within IT. But such documents can serve as the basis for identifying hot topics that can be examined as candidates for service creation. The roadmap itself, if it exists, will be too high level for service design. But once items on the roadmap are approved for work, start with identifying the business processes that are involved. Mapping the business processes required by a project will often point to an external system that you might be able to integrate via services, and will frequently point to internal systems that can be wrapped as services.

Note

Many IT projects include a user-facing presentation layer. Often, only certain aspects of a project should be written as a service on the backend. Service-oriented architects need to communicate with project managers across projects or products to coordinate their efforts. This can be challenging in an environment used to dedicated project teams.

Businesses that are relatively young, have few disparate systems, or are generally very forward thinking might benefit most from this approach. It is easier for businesses to champion SOA efforts in such a scenario, as they get new products delivered that have been on their wish list.

A bottom-up approach starts from the view of a legacy technology. It takes existing functionality and wraps it in a service in order to achieve more general business goals such as increased agility, interoperability, or eased integration. This can sometimes be termed “service enablement”: the basic functionality exists already, but you make it available as a first-class citizen within a service-oriented architecture.

This approach starts by identifying “pain points” within the enterprise that could be usefully addressed as a service. This is a common approach if you have had no architects doing forward planning work with your systems integration, and find yourself with an “accidental architecture” of rampant, undocumented, proprietary, or generally ugly point-to-point communications. If this is the case, you must approach such an effort with caution, taking care to understand the processes that are already using this tightly coupled functionality.

The business realizes value with this approach by freeing up previously complicated intersections of technology for greater agility and flexibility going forward. This can translate directly into shorter time to market.

This approach may work best for companies that have been in business for decades, have lots of legacy systems, use a wide range of disparate platforms (possibly as the result of many mergers or acquisitions), or have many existing point-to-point connections. But beware of simply taking the existing interfaces of these legacy systems and then making a web service out of them. A bad interface that runs with SOAP over HTTP is still a bad interface. Designing the interfaces so that they will be usable going forward often means that you have to do some overhaul within current state business models (that you might have defined using a top-down approach for something else).

A bottom-up approach rarely works. IT can end up being the driver, which you don’t want. The business needs to be aware of SOA and assist in the governance and the definition of processes. The interfaces of the future are not likely to be found in legacy code. Legacy code can be wrapped with new interfaces. And this usually means that you start not at the top or the bottom, but in the middle, according to the requirements of your business processes. You can then find ways to reuse existing systems with a new facing appropriate for the process.

Identifying Different Kinds of Services

Problem

You need to identify the different kinds of services you can build in order to design them with appropriate levels of granularity and proper division of labor.

Solution

There are three basic kinds of services: entity, functional, and process services.

Discussion

The three basic categories into which your service candidates might fall are as follows:

Entity service

An entity service represents one or more business entities. An entity is a noun that makes up the objects in an enterprise. Examples of entities include Customer, Invoice, Employee, Product, and so on. An entity service might feature CRUD (Create, Read, Update, Delete) operations for basic entities that are fundamentally decomposed. Just because something is a noun doesn’t mean it is an entity service. For example, CustomerAccount might be created by a number of different systems interacting. In such a case, you may need to promote the creation of accounts to a workflow process service. Keep service autonomy as a goal, and that should help steer you to the appropriate service type.

Because many entities are referred to throughout the enterprise, they can be easy to identify, and services based on them afford a good prospect for reuse. These can be employed as a “single source of the truth” strategy within a master data management scheme.

Functional service

A functional service does not represent either a business process or a business entity, and it has no representation within a business model. It can be represented within a sequence diagram, however. A functional service is a technology-oriented service, not a business-oriented service. Its purpose is to provide reusable, centralized functionality that other services will rely on.

A functional service may be required to perform a given function, such as sending an email, or handling exceptions in a standardized manner that supports them with logging or notification capability. A functional service might act as a centralized rules engine or security service.

It is important for such services to be as autonomous as possible.

Process service

A process service represents a series of related tasks. These tasks may be carried out within the boundaries of a single business domain, across multiple business domains, or across organizations. A process service can be represented as an orchestration invoked by an ESB, with a coarse-grained contract that causes the process service to appear as a unified whole to clients.

One example is the processing of an invoice. Process compositions may become even more complex, composing other processes. An example of this might be a New Hire service that defines a process around intake of new employees, which is an entity service. But such a service might also call on an IT infrastructure provisioning service to light up a new workstation for the employee. Along the way, it could also use a functional service to send an email and another functional service that handles errors.

While such categories may not organize your physical service inventory or development project setup, it can be useful to understand what kind of service you are working on in order to help organize your approach and steer conversations with other developers and analysts. Architects may want to note such distinctions on their models.

Modeling Services

Problem

You have determined a service candidate and want to begin modeling the service.

Solution

Employ established architectural modeling techniques such as generalization, decomposition, and aggregation.

Discussion

Once you have determined a reasonable candidate service, model the service using a set of techniques, refactoring its definition until you know what kind of service it is, you feel comfortable with its definition and level of granularity, and you’re sure it’s still a service.

To aid in this effort, employ these information modeling techniques:

Generalization

Analyze your service to determine what it represents conceptually, in general terms. In object-oriented (OO) programming, this is called finding IS-A relationships. You want to find the appropriate level of generalization for your service. You may determine that a Customer is a Person and an Employee is a Person too. This could be a useful degree of generalization within your enterprise. But the fact that a Person is a Homo sapiens may be the wrong degree of generality for your dot com. Perhaps the more common problem is that you do not get general enough in your design, failing to realize what aspects of different components truly align and differentiate them. Designing services at too specific a level can shrink their possibility for reuse, and make for very complicated interfaces and orchestrations, defeating the very purpose of your SOA efforts.

It doesn’t matter what kind of service you’re working with. The Person example shown earlier regards an entity, but it’s the same for a process service.

Decomposition

Analyze your service to determine what other elements it composes. Such analysis can reveal functional or entity services that may be worthy of standing alone in their own right. In some cases, your process will be composed of other independent processes. Note that the finer grained your service is, the better chance of composability and reuse it has. The coarser grained your service is, the more interoperable it is, and the more suitable it is for a client-facing endpoint.

Aggregation

Analyze your service to determine what other elements it may be a part of. These elements may be existing processes, services, or service candidates themselves. In object-oriented programming, this is called finding HAS-A relationships. Employing this technique can help you discover composable services.

These are foundational techniques and will serve you well. But for service modeling, you need to look beyond these basic principles and consider these additional aspects:

Reusability: This is often considered in object-oriented design, but not to the extent that it must be within a service model. To determine how to write the contract, you need to perform a systems analysis that gives you the best guess on how it will be reused throughout your enterprise. When it’s not certain how the service will be reused, keep it sufficiently generic to promote the possibility of reuse.
Security: This is typically dealt with at the application level for objects, but it must be modeled at the individual service level when you’re creating services. You will have an overall security model for your SOA that might include SAML, a Policy Enforcement point, transport security, digital signatures, Kerberos, or other related measures. These are typically indicated in policies enforced by tools to support the contract.
Interoperability: Java objects only have to work with other Java objects. But services are intended to interoperate. As you model a service, you must consider it from this viewpoint, identifying other platforms you’ll be working with. Adhering to the Basic Profile (discussed later) helps here.
SLAs: Services, like the systems they wrap, should have defined service-level agreements. The business process your service participates in might need to respond within 100 milliseconds, or a flag should be raised. This is particularly important in an SOA because eventually your well-designed service will be reused by many processes, and analysis at the process level will be important to helping the business understand what it can expect.
Granularity: Your service will participate in an evolving landscape of many services. Getting the proper level of granularity is key to ensuring that you can reuse a service, that you can expose it successfully to your business partners, and that your security constraints will be appropriate.
Contract: Within your model, identify what elements you will need in your overall service contract. Some of these may be direct attributes of the service, and others may serve as metadata that you make available within the context of WS-MetadataExchange. Some elements will be non-functional, and some can be declared and enforced within the sorts of SOA runtime environments offered by commercial vendors.
Process: Process analysis is a discipline all its own, probably unfamiliar to many OO developers. Because business processes can be represented as services, and because business processes will make use of services, it’s important to understand the IT world from this perspective. A real discussion is beyond the scope of this book, but if you have business analysts and Lean or Six Sigma professionals in your organization, they can be a very valuable resource.

Consider these things when you are modeling a new service, in addition to the object-oriented analysis skills you bring to bear.

Note

I only touch on the subject of SOA modeling briefly here. As mentioned earlier, the ideas surrounding SOA, service modeling, process modeling, and so on fill entire books. This chapter is intended to give a grounding in some of the key concepts. If you are interested in SOA modeling, you might check out Michael Bell’s book Service-Oriented Modeling: Service Analysis, Design, and Architecture (Wiley).

Service documentation

Document the service candidates you elicit with an enterprise view. Do this as an iterative process, using a standard format, in order to visualize your service-enabled enterprise. This documentation must ultimately be composable into a larger enterprise service catalog.

Be careful of attempting to model your entire business up-front. Circumstances are likely to change before you complete such an effort. It is reasonable to take a more modular approach here, working with a single business domain, system set, or problem, and model that using an iterative approach. Eventually your models will meet at domain or functional borders.

Making a Service Composable

Problem

You want to make sure that your service is designed in such a way that it can be reused within a composition.

Solution

Do not tie your service interface or implementation to any specific business process. Instead, move business process-specific code into an orchestration or new process service.

Discussion

A composed service is an aggregate of other existing services. While you can realize reuse for a service by invoking the same service from different applications, a service is composable if it is defined in such a way that it can be reused by inclusion within another service’s implementation.

There are two matters here: the service interface must not negatively impact its composability, and its implementation must not inadvertently do so either. In order to provide business value, a service must perform work specific to some business use case. But you must consider the distinction between the execution of a specific unit of work (a service call), and the workflow around that operation that makes it available and valuable to the business in the form of some given business application.

The general idea of composability in software is not very different from its colloquial use. Because of their design, Lego bricks can be used to form a variety of exciting shapes. A Java Address class can be used to compose both an Employee object and a Company object. Likewise, the composability of services must be included as an initial consideration in the design process.

Consider a software company. There programmers type code on different, specific aspects of the system—one for user interface, one for database, and so on. These are roughly analogous to the member services. Then there are the programming managers. They don’t type anything into an IDE, but they coordinate the activities of their employees to ensure that eventually all of the programmers’ efforts are incorporated as features in the single software product that customers are interested in. Each programmer does important work on his own, but the addition of the manager presents an interface to the business that coordinates the activities, as a process service might. The process service doesn’t do any independent work: its single function is to direct the activities of other services, and in so doing, creates something new.

In a more service-oriented example, imagine you are a retail company, and need to write a service that your point of sale application will invoke to perform pre-approvals of a customer’s credit during checkout. If the customer is credit-worthy, your salesperson can offer her a discount for filling out your private label credit card application. Your requirements dictate that you must first check your customer database to determine if the customer already has your credit card, so the salesperson doesn’t offer her something she already has.

If you already have a Customer lookup service that indicates, among other things, whether a customer has your private label card, that service can perhaps be reused by, and composed into, your CreditCheck service. That assumes that the Customer lookup service was designed for general purposes and includes all of the relevant data. Likewise, you want the service that performs the basic CreditCheck to do only the credit check, and nothing else. You don’t want that service itself checking the local customer database, even if it is doing so by reusing the existing customer lookup service. Doing so would dilute the composability of the CreditCheck. In object-oriented programming, this idea is called “high cohesion”—the design restriction that dictates that the operations of a class must be very closely related.

It may seem that the customer lookup and the credit check are closely related, but that is debatable. Getting customer data is a simple operation, with no apparent business case other than the fact that you need to know stuff about your customers. Likewise, the act of performing a credit check says absolutely nothing about whether you must first check your local customer database to see if the customer already has your card. That is a requirement that a specific IT project must fulfill, but it is not relevant to the act of checking credit. To conflate these ideas is to make a category mistake, and limit the reusability and flexibility of your SOA.

So now you are left with three separate ideas and therefore three separate services:

The Customer lookup service that you already had and which you designed to be free of any particular use case, so it is available for further composition.
The basic credit check service that simply hits the credit bureau with a name and address and returns a result.
The overall credit check process service as described by the business analyst, which does no work itself other than coordinating the activities of the worker (member) services.

It is the job of this third composing service to coordinate the activities in such a way that the business requirements are fulfilled. That is, it is the job of the workflow to know that you want to check if the customer already has a card before wasting cycles invoking the credit check service. In this workflow, this is the consumer-facing service, and consumers will be wholly unaware of how their result is delivered behind the scenes.

This is useful because it helps push the business requirements that are incidental to this particular use case up into a customer view that is specific to this use case, allowing the member services to retain their independence. It is possible, for example, that you want to reuse the CreditCheck service in some new way. Your business may want to perform credit checks of prospective new hires, who would not be in your customer database. This would be difficult to deal with had the customer check been baked in at the service level. A frequent goal in object-oriented programming is to isolate what might change; it’s the same thing here.

The bottom line: the business process service must be defined outside the worker service, which can be other process services, or entity or functional services. Services are not always composable, but as you design your services, remember that composability is something to strive for; at the least, perform a check to see if your evolving design helps or hurts your possibility for composition, even if you don’t see an immediate need.

Note that service composition is particularly hard on runtimes. It is important to ensure that your SLAs are always met, and this becomes somewhat tricky when you have a set of services composing a variety of basic services that also compose to varying degrees another set of services.

Chapter 9 covers how to define and create orchestrations technically.

Supporting Your SOA Efforts

Problem

You want to develop a set of guidelines and principles for designing and implementing your service-oriented architecture. It should not only record the decisions you make but also serve as an educational tool for others in your organization.

Solution

Create a reference architecture, which is a representation of your real-world implementation. Internally, you can build on this to include a collection of roadmaps, conceptual blueprints, guiding principles, and standards and conventions that will serve as the foundation of your service-oriented architecture. If you have established a Center of Excellence (CoE) or SOA Team (which is a very good idea), they will be the custodians of these resources, and will likely be responsible for sharing them with the larger development teams for educational purposes.

You could use your reference architecture documents as the cornerstone for an online resource to aid in the education of others. This could be an internal website, wiki, or portal that establishes a single entry point into your architectural blueprints and other supporting resources.

Note

In April of 2008, OASIS published a document it called the “Reference Architecture for Service Oriented Architecture Version 1.0.” You can read the PDF at http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf. It is written for enterprise architects, and covers governance, social structures, service modeling and ownership, security, and more. It’s very abstract, but worth a read. You will find many such documents online that you might want to screen and contextualize for your internal use.

Discussion

A reference architecture (RA), as defined within the Rational Unified Process, is a predefined set of architectural patterns, designed and proven for use in particular business and technical contexts, together with supporting documents that enable their use. These can grow organically from architectural documents, standards, and conventions you have in place already. But it is useful to tailor them for SOA as appropriate.

A reference architecture serves as a blueprint across multiple projects or within a single project. Architects and developers can verify that a subsequent implementation adheres to established guidelines and will have increased likelihood of meeting business goals.

Note

You can think of the reference architecture as being analogous to the United States Constitution. It serves to establish a variety of abstract bodies, such as the three branches of government, each of which has different responsibilities, as well as a set of revisable guidelines that ensures that people operate according to principles that support the overarching goals of the republic. (Of course, all analogies have limited usefulness and can be misleading. Your mileage may vary!)

Aims of the reference architecture

The reference architecture can help ensure the success of your architectural efforts in a variety of ways:

Act as a blueprint

The reference architecture can capture the intersection between your IT infrastructure, your code, and your models. Because these different aspects are implemented by different teams, they can inadvertently act in isolation, rendering the enterprise unable to take advantage of a potential wealth of existing work.

The blueprint can assist solutions architects to view the SOA not only from a coding or system perspective, but rather to take the more holistic view required to ensure quality-of-service levels.

Your SOA reference architecture might link to other existing enterprise architecture documents, such as network and hardware IT infrastructure, and add to this the idea of service layers. For example, within Oracle/BEA, it defines an SOA RA containing the following service layers:

Data Services and Connectivity Services: These provide flexible access to underlying data tiers and enterprise applications.
Business-Oriented Services: A logical layer above Data Services where business processes are conducted.
Presentation Services: Package business capability services, repurposed for a variety of channels.

While Oracle/BEA’s list may not be the one you choose (you might collapse Data and Connectivity Services and you might throw out Presentation Services altogether, or add another layer of your own), the point is that it is useful to conceptualize your services on this level, and not simply on the level of Entity, Process, or Functional, as these are complementary classifications.

Promote best practices

The RA can declare that services and clients must be created and consumed following certain guidelines. Perhaps there are design patterns that you want consistently implemented in certain situations. Perhaps you want to require a set of acceptable methods for service creation, messaging, encoding, and so forth.

By declaring guidelines, standards, and conventions, the RA will help to ensure consistency across the board in service implementation. Architects have an easier task in enforcing the guidelines when they are spelled out clearly in a living public document. Once everyone is used to consistently implementing services in a given manner, this will mean quicker time to market. Developers can create new assemblies with confidence that the services they are reusing will fit well together.

The RA should address how to deal with cross-cutting concerns such as security and rules engines, which are sometimes themselves implemented as services.

Clarify trade-offs

You cannot do everything. Certain requirements are always at odds with each other. Reconciling terrific performance with strong security is a continual struggle.

Enable governance

The governance of your SOA is highly dependent on the creation of an RA. The RA serves as a constitution of sorts for your SOA Center of Excellence or governance board to follow.

Reference architecture site

Your SOA reference architecture can be a deliverable, a living set of resources that can be used for a variety of purposes, and not simply some documentation that accompanies your code. As a deliverable in its own right, it works well when implemented within a website that is easy to update, such as a wiki. Members of the SOA team or governance board or the architects involved at your organization can create a site that they populate with architectural models, standards and conventions documents, and resources for evangelizing and education, and that can perhaps serve as a gateway to runtime tools.

Note

The size and shape of your RA site will be dictated by the size, organization, and distribution of your development teams.

As a suggestion, the items outlined in the following sections might be useful within a reference architecture.

Conventions

Conventions enable clearer communication. They are a matter of subjective taste initially, but once established, they must be followed to make things easier to find and understand. Here are some examples of conventions you might consider creating guidelines for:

Document names, including schemas, WSDLs, and binding customization files
File locations and physical project structure of service implementation projects

Standards

These are more strict than guidelines, and are less a matter of taste. They have a functional purpose, such that if the standards are not followed, degraded performance or functional side effects can occur.

Note

If you are unfamiliar with WSDLs or Schema design patterns, consult Chapter 2.

It can be useful to standardize the following:

Allowing use of binding customization files, such as for JAXB or JAX-WS (see Chapter 3)
Whether customizations are allowed, inline or external (see Chapter 3)
Importing WSDL bindings versus defining them inline
Importing schema types in WSDL versus defining them inline
Default protocol choice, and when other protocols are acceptable
Choosing which “start from” method (see Chapter 2)
Appropriate use of schema design patterns (see Chapter 2)
Using interfaces
Using optimization methods, such as FastInfoset and MTOM/XOP
Using headers
Using attachments
If using SOAP, to dictate acceptable style, use, and parameter style values, such as document/literal wrapped
Using one-way methods
Using asynchronous clients
Encoding for binary data
Centralized schema

These guidelines should ideally include examples of correct and incorrect use of each item.

There are many more items to consider depending on your implementation choices, system maturity level, and environment. While the focus of this book is on Java, you might need to determine standards relating to service creation in RPG, .NET, or what have you. This list indicates the appropriate scope of guidelines for your service implementations and SOA. Failure to adhere to such guidelines can cause interoperability problems and severe performance degradation, and can waste development time.

Note

Keep your standards up-to-date. Make sure to include your team members in determining guidelines. Receive their feedback openly and incorporate their suggestions as appropriate. Create new items, drop old or obvious ones, and make updates as necessary to ensure that the guidelines are fresh, relevant, and useful.

Specifications

There are dozens of specifications that can come into play very quickly in the world of SOA and Java-based web services. Linking to the specifications can help ensure that everyone can quickly find the definitive answer to a question, and it helps implicitly direct people to what they must understand to be productive within the SOA environment. Relevant Java specifications might include the following:

JAX-WS
JAXB
SAAJ
JAXR
Web Services
WS-Annotations
DOM, SAX, StAX

These are only the Java-specific specs. Important SOAP and WS-* specs, some of which we will examine in detail later on, include the following:

XML Schema
XSLT
SOAP
WSDL
OASIS UDDI
WS-Policy
BPEL
WS-Security
WS-Trust

WS-ReliableMessaging
WS-Transaction
WS-MetadataExchange

Centralized bookmarks

Create a wiki page that encourages developers to bookmark web resources publicly so that it’s easy for everyone to find and use them. Invite others to participate.

Industry standards

In addition to the various specifications you will be using, include links to a set of industry standards that everyone would benefit from knowing. These might include:

Basic Profile 1.1
OASIS XML Catalog
W3C Web Services Architecture
OASIS Web Services Implementation Methodology

This is where you should indicate what BP 1.1 guidelines you are following, or state your position on them. Define a set of best practices for your organization based on accepted industry best practices, and incorporate them into your design. Some of these can be elicited from standards such as the WS-I Basic Profile. For example, the BP 1.1 requires that WSDLs use a target namespace. Use this opportunity to explicitly state such conventions so that other developers in your organization can quickly adhere to them.

Security

Create one section of the site devoted to security. This is a large and complex topic in the world of web services, and there are many standards that make this work. Vendors are at different stages of implementation with respect to these standards, and it could be very useful to sort this out for your team. Finally, these guidelines can be important for ensuring interoperability, and can indicate items such as:

Use of particular cipher suites
Use of digital signatures
Transport layer security
Authentication methods

As your SOA grows, it will be useful to have an aggregate list of roles allowed within each service, as this will help organize process orchestration efforts.

Cookbook

Depending on your team’s level of experience, you might include working examples of code that illustrate how to create services and the attendant assemblies.

Note

Consider establishing your architecture concurrently alongside your pilot projects. Developing an architecture entirely up-front without really seeing how the tools work together and how the standards are implemented can have a devastating effect on your deadline and ultimately your product. This is particularly true when you’re in a learning stage, such as during pilots. Make a general plan with the understanding that you probably won’t stick to it. Do a little and then revise your plan. Architectures can be agile too, and don’t have to be complete to get people working in the right direction. You can also, as Frederick Brooks wrote, “Make one to throw away.”

Glossary

Consider creating a list of important terms and their agreed-upon definitions that you will go by so that they are clear in your team’s mind. Some concepts within SOA are contentious, vague, or hype-laden, which can make it difficult to know that everyone is actually talking about the same thing. Using a glossary for terms, such as service, contract, governance, and so forth, can aid meaningful communication.

Documentation

Here you can link to JavaDoc, project documentation, vendor documentation, requirements, use case documents, modeling analysis documents, and other such items.

If you have IT or business roadmaps or other enterprise architecture documents that might play a role in building out your SOA, you can link to them here as well.

Artifacts

If your infrastructure allows it, you might consider having a view into the runtime artifacts within your SOA. These might include centralized schemas, business process modeling documents as derived from a modeling tool, visual representations of BPEL orchestrations, and other items. Offer appropriate users insight into monitoring tools so that they have the information necessary to make good decisions about new service candidates, SLAs, new compositions, or infrastructure changes.

News

You might consider establishing a feed that aggregates various SOA-related websites into your reference architecture portal. This helps to keep everyone abreast of industry trends and give your team the best chance to keep one another informed.

Conclusion

While some of the items indicated here may seem excessive, remember that the purpose of the reference architecture is manifold: it serves to instruct newcomers on the way that you want web services done in your organization; it helps experienced developers find and use web services that your organization has written or endorsed; and it helps the governance board or Center of Excellence make decisions regarding service candidates and future architectural directions.

Selecting a Pilot Project

Problem

You are ready to get started with SOA and therefore need to select a first project. You are not sure how to make your selection.

Solution

Use the following criteria to measure how viable a particular project might be as a pilot:

Does the project create business value?
Does the project have limited scope?
Would the project make a good service?
Do the team members have a good understanding of the problem domain the project addresses?
Is the project useful but not mission critical?

Discussion

Considering these criteria should help you make a good decision about which project to use as a starting point. In this section, we’ll examine each criterion in greater detail.

Does the project create business value?

SOA is in many ways about aligning IT with the business so that eventually there is a blurring of lines between the two. How this emerges will be very dependent on your organization and its culture. But SOA requires considerable support. It represents a new way of thinking about systems, and there are many APIs to learn. While there are free and open source tools to use as application servers, enterprise service buses, business process execution and more, many organizations will make expensive software purchases. That process can require lots of time and input from the business. The investment that the business must make in education of the team and evangelizing to the larger IT group means real time and money that initially are not spent getting something new. It is frequently viewed as a sunk cost in infrastructure that the business hopes will pay off in the long run.

For these reasons, it is important to win the business over; otherwise, the investment upon which an SOA team is dependent could dry up. The way to win the business over is to show them the money. Choose a project that will have some immediate return so that the business can remain supportive. Illustrate clearly that the real return on SOA is realized over the course of several years, as IT may be more responsive and ready to quickly address changing business needs.

Does the project have limited scope?

The project should have limited scope. It should represent functionality that is somewhat isolated from systems that are not well known. But you will get the most out of your pilot project if it does span multiple systems. It cannot be merely a proof of concept about web services, but must be a full-blown, real-world project. Otherwise, you run the risk of underestimating scalability requirements and overall complexity.

Note

Some practitioners recommend starting with a basic service set, and introducing the ESB and orchestration services later. In my view, you want to choose a project of limited business scope so that you have the time and clarity to simultaneously introduce the ESB initially. You don’t want to over-engineer your solution, but if you are planning to connect your work with an ESB at some point, you won’t have to revisit this. Moreover, because ESB is not standardized, products offer very different features or different means of providing certain functionality. You want to understand this central piece of your architecture early on.

Introducing SOA can lead to a lot of new APIs for developers, new application servers, new languages, and new infrastructure. It represents a new way of thinking about development. Thinking in services is different from thinking in objects. Making a switch from functional or procedural programming to object-oriented programming can take time, and represents a dramatic change for developers. I have seen Java classes in excess of 15,000 lines of code, with a single method 700 or 800 lines long. Just because you’re writing in Java and a program compiles and runs doesn’t mean it’s object-oriented, and doesn’t magically make it good. Do not underestimate the difference that services can represent for OO developers too. You need to take the time to educate everyone on the team (though not necessarily at the same time). That takes development time away. If the project has a very large scope, it might never be completed when you have so many external considerations.

You want to be able to isolate unknowns so that you can more easily identify problems during the development and quality assurance phases of the project. Be careful of choosing a product that uses brand-new products. The team will already have a number of mysteries to deal with when working with new infrastructure and APIs. Isolate your changes so that the SOA enablement work can be a leading focus. Consultants can help here.

Consider the target consumers for your initial service. You mitigate your risk by choosing something that is internal to your business, rather than customer-facing. This gives you time to build out a little infrastructure before the external world gets involved, introducing new and unanticipated issues. Internally consumed services will help you focus on implementing your first services properly, and shield you, for a time, from more advanced and complex issues such as federated security. Internal services may also represent an opportunity to gauge traffic with greater confidence.

Would the project make a good service?

This may be obvious; consider whether the functionality really satisfies the criteria highlighted in Defining a Service. Be careful to not have external forces choose a pilot for you if the proposed project wouldn’t actually make a good service. This happens—SOA teams get formed, and then the boss insists that the pilot must be whatever the next thing on the project list is, regardless of whether it is actually a useful service candidate. Writing services initially adds considerable complexity and expense to a project in the hopes that the benefits will outweigh such costs in the long run. If the service will never be reused or never be invoked from another platform, you might not have a very good service candidate on your hands, which means you might not realize much ROI.

Make sure that the service you choose will give you an opportunity to explore the full development life cycle. If you plan on utilizing a “start from schema” approach, for example, you want to address this head-on in your pilot, as it precipitates work surrounding the custodianship of the schemas, modifies the build process, and so forth.

It might be an overarching SOA goal of your organization to move your work in an architecturally neutral direction. This can be the case in companies with decades of legacy data tied to a specific platform. Finding a data service that wraps some central entity representations can help reduce ETL (Extract, Transform, Load) or data movement operations.

Do the team members have a good understanding of the problem domain?

If you have subject matter experts for the given problem domain available, you can mitigate considerable risk. Introducing new systems, new software, new processes, and new problem domains at the same time that you introduce services and SOA creates a dangerous concoction. If you are working with vendors or consultants, make sure they have a background in the vertical business area you’re addressing (financial, retail, etc.).

Is the project useful but not mission critical?

While it is important to realize business value early in establishing an SOA, be careful not to bite off too much in the initial stages. SOA pilot projects often lose track of their deadlines, miss certain requirements, or fail altogether. Choose a project that won’t undermine your business if it takes some extra work to get it up and running as a service.

This makes service enablement of existing pain points an attractive pilot project. There is already a process or functionality in place to fall back on should it prove necessary. Obviously I am not recommending that you plan to fail, but things happen, and it’s smart to be realistic about it up-front.

Note

The fact of the matter is that services are hard. They are hard conceptually, and they are hard practically. There is enormous complexity added to an environment to make your services portable, reusable, composable, and interoperable. They are difficult for both the business and IT to wrap their minds around.

Do some research on architectural frameworks, methodologies, and design patterns, and select some that will support you best given your environment.

The second pilot

Once you have completed the initial pilot, the second project, which should probably be considered a pilot extension, becomes very important. The chief goal of the pilot is to establish a foundation for SOA, understand the technical implications, and create something of value using new constraints and new strategies.

The second project provides a key opportunity to build out some of the organizational and cross-cutting concerns that SOA precipitates, such as governance (see Establishing Governance). The second pilot will, for this reason, need to have a similarly limited business scope as the initial pilot. Don’t leap into rewriting your payment infrastructure with your second SOA project. You need time to learn the behavioral patterns of your new tools and time for the education and daily reality of running the production services environment to set in.

You can also use the second project to build on your initial architecture. You may add functional or meta services, such as a rules service or security service. You may introduce BAM tools at this stage, or deepen your work with WS-Policy or security concerns in general. You might clarify and refine how you will handle service versioning, which may not have been a central focus of the pilot. You might take advantage of some more robust features of orchestration than you may not have had time or need to explore initially.

These things should have been laid out in your SOA roadmap. The roadmap will change, but keep it updated, and remember that SOA is a long-term investment. Plan big, but start small.

Establishing Governance

Problem

You need a reliable organizational mechanism to transfer knowledge, enforce standards, provide infrastructure for growth and change, and in general offer strategic leadership regarding your service-oriented architecture.

Solution

Establish a Center of Excellence, sometimes called a “Competency Center” or SOA governance board, comprised of stakeholders from the business and technology sides of the house, whose job it is to provide the enterprise this support.

Discussion

Depending on the maturity level and size of your company you may already have IT governance standards in place. SOA governance is an extension of IT governance, specialized for the particular needs of SOA. Because SOA represents a strategic initiative of which a set of tools and techniques is only a part, you need to have a way to gradually introduce the strategy into your organization.

Note

This book does not address much of the organizational or business aspects of SOA. While they are very real and important parts of SOA, there are many good books that address SOA from that angle, and this book is intended to address the technical side. But it is important as a developer/architect to be clear that SOA is not merely a collection of web services.

SOA requires new processes. It must be clear to your organization how to design SOA-based solutions, elicit service candidates, and coordinate a new development cycle to support your incubating SOA.

You might include solutions and systems architects, as well as business stakeholders in the Center of Excellence. This helps ensure that IT acts in alignment with the business and has access to its current priorities and future plans.

Note

Keep the governance team somewhat lean. As long as the SOA governance team has enough resources to remain aware of the activities of the enterprise and enforce and grow the reference architecture, that should be enough. Grow it responsibly. You don’t want your SOA to die by committee.

The responsibilities you might assign to such a governing body are as follows:

Establish business case: This may be performed early on during SOA adoption by the enterprise architect and others. The business case for SOA includes the vision, the goals that SOA will accomplish, and probably a plan to fund the initiative.
Outline roles: SOA will introduce new roles within IT, and they should be clearly stated. You need people to be responsible for carrying out the governance work, make architectural decisions, establish the reference architecture, vet services, process service candidates, and establish and grow new infrastructure such as the ESB. You may also decide who will support and maintain services after they are deployed, and ensure that your knowledge transfer plan accounts for this.
Assist in setting the roadmap: The governance team has a special purview that may make them key elements in helping the enterprise architect or technical executives set the IT roadmap. The roadmap may go so far as to map defined activities to larger goals, and map those goals to a larger set of aspects of your business vision.
Maintain the reference architecture: The CoE can also have the maintenance of the reference architecture under its purview, which will aid in building and linking process models into the larger enterprise.
Facilitate development at design time: Architects in this context act as a guide to developers, enforcing the reference architecture and supporting their efforts. They might select tools, frameworks, and infrastructure applications, and adopt and adapt methodologies to support the service-oriented enterprise.
Facilitate services at runtime: The subjects of SOA governance include developers and services too. Runtime monitoring tools should be in place to ensure that SLAs are being met. It is under the purview of the governance team to keep track of this and plot for future growth so needs are met just before they arise.
Facilitate services’ life cycles: The governance team can see when services may need to be versioned, and assess the impact of that versioning. Versioning is a more complex issue in SOA than in traditional development because of its distributed nature. The person or team who develops a given service may not have any clear view into the larger set of processes that now compose this service. It is the job of the governance team to understand and prepare for this and oversee its proper implementation.
Enable knowledge transfer: The CoE can support the knowledge transfer effort. The learning curve on SOA and on web services APIs and infrastructure can be considerable. Even if some members of your team are not building services, they should be aware of the language and familiar with the ideas in order to work in a complementary manner. Eventually such developers may move on to create and consume services, and they need to be prepared to understand and follow the guidelines laid out in the reference architecture.

Common pitfalls governance helps you avoid

Organizations that attempt SOA without governance in place can fall victim to a variety of ailments, including total failure of the SOA initiative. There are a few common, avoidable pitfalls.

You can’t govern what you don’t know about. So, to ensure that all of your service-related code and documents are visible, implement a central repository that has the documents of record for each version of each service. This will help track these important documents during design and runtime.

Service redundancy

A common pitfall, particularly within large or decentralized organizations, is service redundancy or overlap. The same or similar service is repeatedly created throughout different groups in the enterprise. This is expensive, wasteful, and confusing. As a result you can find yourself with sharply increased maintenance costs. It is the job of the CoE to prevent this by monitoring what’s getting developed, encouraging collaboration between implementation teams, and establishing and using a centralized repository for service discovery.

Sundry artifacts

On a practical level, ensure that governance is in place to manage the many new kinds of artifacts that SOA can introduce, such as WSDLs, schemas, SCA configurations, policies, and more. Left to their own devices, developers will view such documents as simply part of the code like everything else, and bake them directly into their project files. The artifiats will end up scattered across the enterprise, and versioning and client dependency management will quickly get out of control.

DBA (Death by Acronym)

While Death by Acronym is a syndrome we see in IT and is not particular to SOA, SOA practitioners are among those most vulnerable to it. To die by acronym is to erroneously believe that one understands whatever the acronym represents. Because acronyms act as stand-ins for very complex concepts, they gain the status of sound bites and lead us to affirm to one another only the most bare, surface, and general meanings of the concepts at play. The result is strangled communication that undermines collaborative efforts. At its most insidious, companies looking to claim market share for a rising buzzword will rebrand a collection of only marginally related products with the buzzword. SOA is susceptible to both of these kinds of problems.

Education is the only known cure. In the case of SOA, it means not trusting any single source, and cross-checking with a variety of references.

Resume padding

This is a reality. Beware of developers and architects who seek to advance their careers at the cost of populating your SOA with frivolous functionality or over-engineered solutions. You can recognize these types by their endlessly new answers to problems that have already been solved.

Governance can handle this problem by making all service-related development efforts transparent, and by managing solution implementations.

Bunny services

One bunny is pleasant to find in your yard. Two bunnies are even better, chasing each other hither and yon. Fifty bunnies is a problem. Just because something is good doesn’t mean that more is necessarily better. The cake you’re baking might need half a teaspoon of salt; add a tablespoon and it’s ruined.

Once you get good at services, it will be tempting to make lots of them. Review your landscape. Not everything should be a service. Allow services to proliferate in your organization in the manner of multiplying bunnies, and expect performance, maintenance, and management problems. Remember the old saw, “just because you can, doesn’t mean you should.”

Summary

In this chapter, we established working definitions of central terms such as service-oriented architecture and services themselves. We started from a very general level and addressed chiefly matters of organization, such as how to establish a reference architecture and choose a pilot project. But we also examined fairly specific criteria useful in determining worthy service candidates as well as specific guidelines to establish to support the goals of SOA within your organization.

While there are additional design considerations we will address, most of the rest of this book is very practical, and addresses coding problems with coding solutions. Even coding problems have more than one solution. But in the case of the topics in this chapter, there are many other legitimate points of view, and many people who might disagree with some of my conclusions in it.

There are many good books that cover these topics and others in greater detail. If you are interested in high-level service design and organizational considerations, you might read Thomas Erl’s SOA: Principles of Service Design (Prentice Hall) and Nicolai M. Josuttis’s SOA in Practice (O’Reilly) (http://www.oreilly.com/catalog/9780596529550).

Chapter 1. Introduction to SOA

Introduction

Defining a Service

Problem

Solution

Discussion

Platform-independent interface

Available across a network

Operates on business objects

Note

Decoratable

Other considerations

Defining SOA

Problem

Solution

SOA is a kind of architecture

SOA is built with services

SOA facilitates integration

SOA facilitates reuse through loose coupling

Note

Invoking services

Other considerations

Identifying Service Candidates

Problem

Solution

Discussion

Top-down or bottom-up approach

Note

See Also

Identifying Different Kinds of Services

Problem

Solution

Discussion

Modeling Services

Problem

Solution

Discussion

Note

Service documentation

Making a Service Composable

Problem

Solution

Discussion

Supporting Your SOA Efforts

Problem

Solution

Note

Discussion

Note

Aims of the reference architecture

Reference architecture site

Note

Conventions

Standards

Note

Note

Specifications

Centralized bookmarks

Industry standards

Security

Cookbook

Note

Glossary

Documentation

Artifacts

News

Conclusion

Selecting a Pilot Project

Problem

Solution

Discussion

Does the project create business value?

Does the project have limited scope?

Note

Would the project make a good service?

Do the team members have a good understanding of the problem domain?

Is the project useful but not mission critical?

Note

The second pilot

Establishing Governance