Architecture Evolution: Service-oriented Architecture versus Web Services

Service-oriented architecture (SOA) is not the same as Web services: the latter is one concrete way to achieve some benefits of SOA, and specifies a collection of technologies using protocols such as simple object access protocol (SOAP), and languages such as XML. Web services are invoked over the Internet by means of industry-standard protocols, including SOAP; extensible markup language (XML); hypertext transfer protocol (HTTP), Web services description language (WSDL); and Universal Description, Discovery, and Integration (UDDI). These are defined through public standards organizations such as the World Wide Web Consortium (W3C). For example, SOAP is an XML-based messaging technology standardized by the W3C, which specifies all the necessary rules for locating Web services, integrating them into applications, and communicating between them. UDDI is a public registry, offered at no cost, where one can publish and inquire about Web services.

Part Three of the series Architecture Evolution: From Mainframes to Service-oriented Architecture.

For more background information, see Architecture Evolution: From Mainframe to Service-oriented Architecture and Architecture Evolution: From Web-based to Service-oriented Architecture.

SOA can in part be defined and explained by Web services, which according to Microsoft are "self-describing software modules, semantically encapsulating discrete functionality, wrapped in and accessible via standard Internet communication protocols like XML and SOAP." Web services are revolutionizing how applications talk to other applications (or, more broadly, how computers talk to other computers) by providing a universal data format that lets data be easily adapted or transformed. Based on XML, the universal language of Internet data exchange, Web services can communicate across platforms and operating systems, regardless of the programming language in which the applications are written. Although each Web service is a discrete unit of code that handles a limited set of tasks, and although Web services remain independent of each other, they can loosely link themselves into a collaborating group that performs a particular task.

But, unlike Web services, SOA is a broader concept that runs independent of any specific technology, and even if one uses Web services and object-oriented (OO) approaches, one may not necessarily achieve the holistic state of loosely coupled, autonomous, and reusable components that are essential to true SOA. Nonetheless, Web services also make it possible for developers to choose between building (providing) all pieces of their applications, or consuming (using) Web services created by others. This means that an individual company does not have to supply every piece for a complete solution. The ability to expose (announce and offer) its own Web services creates new revenue streams for any company, whether it is an independent software vendor (ISV), a reseller, or even a user enterprise.

Business-oriented Web Services

A business-oriented definition of Web services would be an approach that helps the business connect with its customers, partners, and employees. In other words, it should enable the business to extend existing services to new customers, help it work more efficiently with its partners and suppliers, and unlock information so it can flow to every employee who needs it.

Efficient business management practices describe span of control as a critical mass beyond which a single manager or management team cannot effectively manage people or facilities. This is why manufacturing facilities that become too large are typically split into smaller units, and why large corporations generally tend to have multiple manufacturing and distribution business units operating independently. These enterprises not only need to be managed effectively, but must collaborate and interoperate with each other.

Collaboration and interoperability are critical where multiple business units reside under one larger corporation, or where there is a requirement to integrate the system into a supplier's or customer's disparate system when a business-to-business (B2B) or business-to-consumer (B2C) extension is desirable as part of the business model. These connections can be made easily using Web services which, again, allow the applications to share information through the Internet, regardless of the operating system or back-end software that the application is using. By enabling applications to share data across different hardware platforms and operating systems, Web services provide many more benefits, including reduced development time and expense for new projects. They also deliver more personal, integrated experiences to users through the new breed of smart devices—including personal computers (PCs).

A good illustration is a stand-alone inventory system, which, if not connected to anything else, is not as valuable as it could be. In other words, the system might be able to track inventory, but not much more, and users may have to enter inventory information twice—once in their accounting system and once in their customer relationship management (CRM) system. The inventory system may be unable to automatically place orders to suppliers, and the benefits of such an "autistic" inventory system are diminished by high overhead costs. However, if one connects such an inventory system to an accounting system, whenever one buys or sells something, the implications for the inventory and cash flow can be tracked in one step. Furthermore, by connecting with a warehouse management system (WMS), a customer ordering system, supplier ordering systems, and the shipping company, suddenly the inventory management system is worth much more, since users can perform uninterrupted management of their business while dealing with each transaction only once, instead of once for every system it affects. That represents a lot less work—and a lot less opportunity for error.

Prior to the development of Web services and application servers, linking disparate systems required a massive amount of programming, and many manual steps for the interaction to occur. And when it did, system speed was often sacrificed. Conversely, modern platforms should much more easily allow companies to automate processes once done manually, thereby reducing labor costs, and facilitating accuracy by eliminating human error. For example, it should be possible for orders placed over a company's Web site to be processed automatically virtually in real time, with the appropriate pricing allocated according to customer status. Accounts can thereby be created on the fly before the order is processed, while orders can be automatically printed out, and items automatically relieved from inventories in real time—all with no human intervention.

The implementation of an application on such a Web services-based platform can even shift the transaction load from the front-office e-commerce system to the back-office enterprise resource planning (ERP) system. For instance, an e-mail thanking the buyer for a purchase can be initiated from the back office after the XML transaction is consumed by the ERP system. In this manner, the information sent can be more informative, including data such as expected production time frames and ship dates, which is especially pertinent in a B2B manufacturing environment. What is important is that the usually silent feedback received in a customary B2B e-commerce environment can be enhanced through the ability to seamlessly extend the information to the back-office ERP system. The result should be a richer customer experience, in turn resulting in happier customers and increased long term revenue.

The SOA Environment

There are many similar applications where Web services-based solutions can replace time-consuming and error-prone manual tasks to speed order turnaround. But to take advantage of that, enterprise applications vendors need to re-educate users to think "outside the box" or "outside in." In the early 80s and the days of the mainframe, system architects spent a huge amount of time with customers developing system specifications prior to writing the customized, tailored system. Users were urged to think "outside-of-the-box" functionally, bur "inside the box" technologically, to push the technology to the limit (of what the box could do at the time). Users became accustomed to demanding functionality and getting it delivered, even at a hefty price. To the end of mitigating this, application servers have become the middleware for the enterprise as they increasingly provide more hooks into legacy applications. In an SOA environment, an application server hosts the application services and also plays the role of a fundamental enabling technology. Transaction-processing monitors (TPMs) and object transaction monitors (OTMs) are examples of native application server products.

Before Sun Microsystems pioneered the application server concept in the late 1990s (although some might argue that the Microsoft Transaction Server [MTS] pre-dates the application server work by Sun), software was still largely treated as unfathomable lines of monolithic code, stovepipe legacy applications, or at best collections of vaguely recognizable objects. Mainframe and early client/server applications also had complete control of the stack from top to bottom, including user interface (UI), process logic, integration logic, application logic, and database. The advent of application servers began to change this by promoting a subtle but profound shift in how software should be designed (and perceived). For the first time, developers started to think of code in terms of functions and services such as transaction management, load balancing, and security. Since such services are common to all systems, regardless of platform, software developers began to pursue seriously the idea that functionally identifiable components can be re-used and shared across multiple different systems.

The intent here is to address the ever-increasing market awareness of the following facts:

1. Almost every business changes, and that software must change with the business (see What's Wrong With Application Software? Business Changes, Software Must Change With The Business).
2. Even small businesses are really unique—one size can never fit all, and thus, custom software is a requirement for many enterprises, even for the smaller ones (see What's Wrong With Application Software? Businesses Really Are Unique—One Size Can Never Fit All).
3. The high cost of development, support, and enhancements in term of money, time, and quality all limit the ability of installed legacy software to meet many demands of business (see What's Wrong with Application Software? It's the Economics).

However, it takes excruciatingly painstaking efforts, industry domain knowledge, and resources (often estimated in hundreds of "labor years") to devise and build an enterprise system from scratch. In deciding how to write it, every software vendor makes a big, expensive commitment to the technological underpinning it has to select at the beginning of the project (for example, programming language, operating system platform, and data access technology). Often, the selected language and the data access technology are tightly integrated and not easily separated later.

If one does not count some open-source proponents and pioneers and IBM System i zealots (formerly AS/400—see Server Platform Situational Analysis: IBM AS/400), there has long been an informal demarcation between Unix-based enterprise systems for larger enterprise and Microsoft Windows-based systems for the lower end of the market. With the advent of application servers, and the vendors' and users' forays into Web services and SOA-enablement, this opposition has been transformed into Java 2 Enterprise Edition (J2EE)-based application servers versus Microsoft .NET (see Understand J2EE and .NET Environments Before You Choose).

While much has so far been said in our research about the J2EE camp (see Oracle Further Orchestrates Its SOA Forays, Multipurpose SAP NetWeaver, and Contributing to the Rejuvenation of Legacy Systems in the Enterprise Resource Planning Field), look for forthcoming articles that will also analyze the state of affairs of the Microsoft-centric enterprise vendors.

If suffices to state here that the most basic case, and possibly the most prevalent, would be that of mere .NET-compatibility in the market. Namely, that means only that legacy software simply runs on .NET branded servers (Microsoft Windows). While such technologically laggard Microsoft-centric products can run on the latest Microsoft operating systems and database platforms, the aforementioned benefits of Web services are typically not easily achievable.

Conclusion and Recommendations

When a compelling new technology does appear, it is quite common for an enterprise application provider to surround its old ERP or accounting core software in a "wrapper" of newer technology, of which the goal is to effectively obfuscate the old technology, giving it the latest graphical "look." The goal is also to provide an easier means to access the core business logic and data from other, more modern systems, devices, or from the Internet. Many ERP and accounting back-office systems in the market today were originally written in—and still contain—cores written in non-mainstream, or even antiquated technologies. Strategies employed to wrap older products include incorporating contemporary Windows graphical user interfaces (GUIs), often referred to as "screen scrapers" or web browser-based UIs, or lately, providing new Web services layers to rejuvenate their aged products by accessing the old business logic components and databases.

As long as the "old" software is meeting business needs, new technology is not the change driver, which makes building replacement products on a new framework a riskier strategy. Some of the venerable products are now in their umpteenth generation, which has given the vendors the chance to optimize their code and solve many security and other conflicting issues. Product functionality still matters quite a lot, and while it is important for enterprise applications providers to implement the latest computer science "quantum leap," there is no guaranteed correlation between first-to-market and ultimate success in the market. Many vendors have also felt the displeasure of the client bases that were far from being ready to make a significant technological leap. Hence, having been burdened with a large customer base still running on a slew of older product that support possibly obsolete technologies, even the largest vendors had to backpedal and rethink their older product release discontinuation strategies.

By way of conclusion, it is always the business rationale that should drive any technical decisions. Every business should focus on optimizing processes and core competencies such as lowering costs, improving customer satisfaction, achieving faster deliveries, and so forth. Then, some painstaking exercise should be conducted to determine the technological enablers. For the vast majority of enterprises, their future IT asset portfolio will still feature a mix of packaged and homegrown legacy applications, and not a total SOA rewrite.

This concludes the series Architecture Evolution: From Mainframes to Service-oriented Architecture.