Software construction and integration continues to be a labor intensive task. As the state of computer science progresses, we are continually finding new tools and techniques to reduce the efforts and increase the return. The rise of a ubiquitous service oriented computing theme has brought new opportunity for productivity and new challenges for architects and designers. The problems and solutions can be organized into a few overarching groups:

1. Working with services units (focus on loose coupling)
2. Working with networks (focus on resource virtualization)
3. Networking services together (focus on agile composition)
4. Doing 1-3 economically (focus on scalability across several dimensions)
5. Enabling new offerings based on the new technology (focus on the future)

1. Consumers and Producers are Loosely Coupled
Loose coupling is a primary enablement of reuse and integrate-ability. Attempts to enable reuse in platform specific, object oriented have failed. Modern WSA (Web Service Architecture) programs spend extra effort to provide an atmosphere where functionality can be reused.

A. Provide Functional Encapsulation
Functional encapsulation is the process of hiding the internal workings of a service to the outside world. This is a concept that was highly promoted in the object oriented world and continues to be a primary consideration in designing a service.

B. Factor Out Non-Functional Concerns
One of the primary problems with reuse was that the remedies to the non-functional concerns glued the components together. Common concerns were: reliability, security and integrity. The remedies were things like: atomic transactions, triple-DES encryption and reliable messaging. Unfortunately, references to these remedies were often hard coded into our components, making them more difficult to tear off and reuse. The SOA model encourages the use of standardized policies that advertises the remedies to the non-functional concerns. Here, a consumer can read the policy and determine if it is works with there needs. If so, they can move forward in using the service. If not, they can query the network to determine if a mediating device is available to provide translation.

C. Force Ubiquity at the Edge of the Service
The Web Services umbrella is a collection of standards. SOAP, WSDL, the WS-* specifications take anything that IS NOT functionally encapsulated and turns them into a standard. The goal of these standards is to provide ubiquity in the programming model at the edge of the service. Introducing a new protocol or format that lives on the outside of the service but can’t be recognized or consumed will reduce the reusability of the service and force a tight coupling between the intended consumer and actual producer.

2. Leverage Network Computing and Resource Virtualization
In the 1990’s, a significant focus was placed on virtualizing the machine; this effort produced the “virtual machine”, or VM. The web service computing paradigm takes this concept one step farther; now the emphasis is on virtualizing many machines across a network. This “virtual network of machines” is usually referred to as a ‘grid’. Although the web services architecture doesn’t mandate full resource virtualization, it does offer a stepping stone to this capability. This is attractive to organizations that are interested in implementing autonomic or on-demand operational models.

A. Network the Services
As services are created, their interfaces and policies are advertised using ubiquitous formats. This advertisement of capability becomes the software contract. As more and more contracts are created and placed on the network, a Service Network is created. The services along with intermediaries become the basic building blocks for creating and integrating software. In network computing, a single programming style is often used for both the ‘local network’ (the local computer) and the ‘remote network’. (This is the virtualization of the network itself).

B. Provide Mediation in the Network
SOA enables a ‘network programming model’. This allows intermediaries or ‘bumps in the network’ to provide value added functions to the messages that are traveling between producers and consumers. Mediating functions include: message transformation, content based routing, load balancing, authentication and many others. These intermediaries not only help in the decoupling effort, but they can also be used as remedies to non-functional concerns like availability and integrity.

C. Resolve Resources at Runtime
Resource oriented computing focuses on the virtualization of computing resources. This means that special attention is placed on discovering resources at runtime and using those resources in a fashion whereby they can be released and regained.

3. Systems are Loosely Bound in the Large and Small
The use of web service contracts (interface + policy), enable systems to be loosely bound for both the composition of systems as well as the integration of those systems.

A. Integration and Composition are One
Historically, different programmatic mechanisms have been used to compose software versus integrating it. Software was traditionally composed by using objects and language-specific contracts or interfaces. Applications were integrated by using proprietary messaging systems. As messaging and interfaces standards become ubiquitous, the movement is towards using a single unified model that embraces standardized messaging across standardized interfaces. The use of a unified programming model blurs the distinction between integration and composition. The primary distinction will be a matter of programmability. Current compilers and platforms are tuned to the language specific composition problem. Work is still needed to make the programmability of a single model as easy as the current state of the art in the object oriented world.

B. Functionally Structured, Operationally Amorphous
In the WSA, sub-system functionality is exposed as a set of contracts. These contracts are bound through architectural and compositional patterns (runtime location, correlation, leasing, eventing, etc.) which are implemented in the language of choice and are executed in an operational location that may be determined at runtime.

B.1 Enterprises Architect the Manageability of their Critical Service Network
Systems which are deemed critical to the enterprise are ‘designed-for-manageability’. That is, the system, the services and intermediaries that it depends are checked to verify that the entire loosely bound system will work as designed. The compilation of loosely bound systems is significantly more important in mature networks where services are shared and new versions of shared services are introduced.

B.2 Non-Critical Service Networks Grow Organically
Systems which are deemed non-critical can easily be introduced and removed from the service network without a significant negative impact. Metcalfe’s law states that, “the usefulness, or utility, of a network equals the square of the number of users.” A variation of this law is applicable to the Service Network, that is, “the usefulness, or utility, of a network equals the square of the sum of the number of easily consumable and valuable services available on the network.” A significant amount of the services available on a network will be simple, user centric services which may be managed in a much more organic method.

4. Enterprise Service Networks Scale Efficiently
Unlike many other computing styles, the service network is meant to scale. It should facilitate hundreds or thousands of different applications. Object oriented, RAD and platform specific systems faced difficulty in scaling the number of applications due to reuse of a common infrastructure. Packaged Applications faced scaling obstacles in regard to extensibility, configurability and integrate-ability. The web service architecture incurs additional upfront burden to facilitate massive scaling.

A. The Enterprise Vocabulary is Managed
The primary vehicle for a programmer is his language. Teams of programmers extend their languages by adding functions (or services). These services introduce terms that more closely resemble the task at hand (e.g., shipOrder, bookFlight). Enterprises create vocabularies of nouns (Flight, Order, etc.), verbs (ship, book, etc.) adjectives (the flight attributes) and now adverbs (reliably, securely, etc.) Corporations have placed significant attention on managing their nouns and adjectives (mostly for their databases systems), but have placed virtually no emphasis on managing their verbs or adverbs. As the enterprise shifts into a service oriented computing paradigm, managing the verb and adverb will become as important as the nouns and adjectives in the last generation. Also, the managing of the nouns will need to span even more partitions, for example: 1. Service Messages, 2. Objects, 3. Databases and 4. Specialized containers (e.g., rules engines, orchestration engines, etc.) The creation of a common enterprise vocabulary allows distributed departments to leverage prior works and build out a common semantic and functional vocabulary.

B. Facilitate Service Use and Reuse
If a programmer can’t find a service, they won’t use it. If they find it, and it doesn’t fit their needs, they won’t use it. If it does fit their needs, but they have to jump through hoops to incorporate it, they won’t use it. Make it easy for developers to find and use the services. Conversely, make it easy for the developer to contribute their services back to the shared pool. This means that the intent of the code should be self revealing or explicit, enabling asset harvesting.

C. Create a Federated Solution
The Service Network conjoins a number of traditional enterprise computing boundaries. This includes network and administrative domain boundaries, organizational and operational boundaries as well as the boundaries of time and space. The capabilities of - and services in - the service network will evolve and mature with independence. Nonetheless, cohesion across the nodes in the service network is advantageous in order to minimize impedances. Balancing these concerns, and there associated remedies, requires that control and evolution of the capabilities (and associated services) in the service network be federated. A closer look at this dynamic bears out an interesting conclusion. The capabilities of – and relationships between – services in the service network are inherently symbiotic. The dynamics of this relationship can be summarized as a form of inversion dependency – all of the capabilities of and relationships between – services in a service network are nodes on the network and all service networks are comprised of service nodes. There are interdependent on each other’s existence and capabilities and neither exists without the other. Therefore, the services in the service network are in no way autonomous but rather they comprise a federation of service nodes with varying capabilities and relationships to each other that evolves symbiotically across enterprise computing boundaries, time and space.

5. WSA Enables New Opportunities
In each major paradigm shift we’ve witnessed where technology was able to easily solve a business problem. The advent of the WSA is no exception. At the core of the opportunities is the ability to share information – between people, systems and corporations.

A. Enterprise Boundaries are Removed
The Internet and the Web demolished enterprise boundaries. By deploying ubiquitous protocols the information systems quickly became geared at communities of interest, regardless of where the corporate boundaries were drawn. Web services hold the potential to further destroy the ‘intranet thinking’. The ability to quickly share information between consumers and retailers, distributors, manufacturers, professional service providers and other members of the value chain enable just-in-time decision making that is optimized across boundaries. The efficiencies gained by ‘self-service applications’ will be extended past the single corporation. The concept of “one face to the customer” will now be available across corporations and consumers will likely come to demand it.

B. Unstructured Data Finds Structure and Meaning
The activities associated with moving towards service network overlays, managed enterprise vocabularies and enterprise-scope metadata repositories has a natural set of consequences. Information models in this environment are inherently descriptive. We see standardization on schema-based grammars for defining, modeling and advertising the artifacts of the service network. As a result, we are beginning to organically close many of the semantic impedances that have traditionally impacted the drive towards ubiquitous, business-driven, information and process integration. By using schemas and semantic knowledge, we are further enabling the power users to find the natural pivot points that exist in their day-to-day information systems.

C. Systems are Tolerant to Change
Enterprises implement a wide variety of enterprise information systems that support different aspects of planning, execution, monitoring and analyzing business processes. Some of these systems take the form of packaged enterprise applications while others are custom applications and yet others were at some point packaged and through time have been extended and modified to the point that for all intents-and-purposes they are now fully customized applications. For the most part these systems were designed, developed and deployed as a result of the IT-based initiative du-jour that was synonymous with their respective eras of computing.

Examples of these initiatives include data warehousing and OSS, ERP, CRM and SCM. These initiatives evolved an matured over time from stand-alone, custom applications developed and integrated using proprietary languages and interfaces; designed with inherently-centralized architectures and deployed onto mainframe-based computing platforms; to networked, packaged applications developed and integrated using standardized languages and interfaces; designed with inherently-decentralized architectures and deployed onto commodity-based computing platforms. Therefore, the IT-driven responsiveness required by enterprise-scope business initiatives has been inordinately constrained by these “bottom-up”, language, platform and API-specific approaches to evolving these systems.

As a result, enterprises have viewed the art (or voodoo) of evolving these systems as the exclusive domain of “rocket scientists”. Accordingly, IT as whole – and in particular the systems infrastructure supporting enterprise initiatives and their corresponding business process – have been mostly misaligned with the operational goals and strategic objectives driving the business. With a move toward design-by-contract, contract-first-construction and protocol-based interoperability and integration there is an opportunity to enable tolerant evolutions through malleable abstractions and mediate impedances at run-time.

D. Power Users can Impact the System
As is the case with the other phases of enterprise computing, the age pervasive business-driven, service-oriented computing is beginning to mature with respect to strategic enterprise adoption and applicability. This maturation is driving the next natural set of evolutions with respect to preferred architectural approaches, patterns, methods, processes and roles. As service fabric overlays, enterprise-scope application-oriented service networking and managed service networks rapidly enter the mainstream we are seeing that the traditional notions applications and platforms is being recast around “network application platforms”. We are moving the “center of gravity” from server-based containers, registries and consoles to network-centric run-time intermediaries, metadata management services and goal-directed interaction interfaces.

As the network becomes smarter the abstractions and interaction mechanisms become closer to the capabilities of the average business worker. Just as employees became an integral part of Intranets by feeding and consuming information, a similar dynamic is beginning to occur with the service network. Power users are able to access information through desktop productivity tools and are able to easily share the information and collaborate with their co-workers.

Concluding Remarks
The transition to a Web Service Architecture is more significant than “just using SOAP” or adopting distributed computing. If properly applied, WSA has the potential to provide a sustainable competitive advantage to any corporation that successfully adopts it – and poses an equally daunting fate for those organizations that fail to adopt it.

About the Authors
Jeff Schneider is founder and CEO of MomentumSI, a consulting firm that specializes in transforming organizations into a “Service Oriented Enterprise”.

Frank Martinez is founder and CEO of Blue Titan, the leading provider of service-oriented infrastructure which enables enterprise architects to control, share and scale services and applications, driving business innovation across the distributed enterprise.