| home / programming / enterprise / 1 |    [previous] [next] |
|
|
|
Software development, although a field unto itself, belongs in the general discussion of EAI and SOA. The reason: the area of software development that touches on SOA and web services is that of application integration, the development of software for the purpose of connecting two software applications together. In this arena, web services’ potential for code reuse makes it a relevant topic of discussion.
Web services embody the true reusability of code that has been the great dream of computer programmers from the beginning. When object-oriented computer programming languages emerged in the 1970s and ’80s, their developers had in mind the goal of abstracting the function of a piece of software from its actual code. In contrast to earlier software development practices, where a software developer would have to hardcode every line of a program to accomplish a given functional task, with an objectoriented language the developer only has to access an interface that fronts for the underlying code. In practical terms, this means that the really time-consuming work of coding a piece of software will have to take place only once. After that, the code will then become an object that can be invoked without the necessity of coding it all in again.
Though it is far from simple, object-oriented programming has streamlined software development in many ways. Web services take object-oriented programming to the next level. Web services are, in effect, “universal objects” or components that can be understood by any piece of software running on any operating system—they are truly “reusable code.” Let’s look at what this means for the future of software development.
To illustrate the obstacles that to date have hampered the creation of truly reusable code in object-oriented languages, let’s take an extremely simple example of objectoriented programming: a calculator. Say that we need to develop a calculator software program using an object-oriented programming language. As shown in figure 5.10, our library contains Visual Basic (Windows) objects for the mathematical operations of addition and subtraction. We also have Java objects for division and multiplication. If we want to have a calculator that adds, subtracts, multiplies, and divides, we have to rewrite at least two objects. You cannot access the functionality of a Java object from Visual Basic, and vice versa. The requirement that objects “match” programming languages has been the number one barrier to the advent of objects as reusable code. Objects are partially reusable. You can reuse them if you stay within a specific language environment: Java with Java; Microsoft languages (Visual Basic, C++, ASP) with Microsoft languages, and so on. Additionally, traditional objects had to communicate with each other over compatible message transport protocols. Incompatibility between message transport protocols was another barrier to the potential for objects to become universally reusable code.
Putting web services to work in our calculator example, we can expose each of the four existing objects as web services. (Note: This example is hypothetical and not meant to indicate an actual recommended use of web services in the real world.) Figure 5.11 presents this new object-oriented programming paradigm. Using SOAP and Internet
protocols, each object can now be used by any web service consumer program. In our example, we create a new calculator web service—itself an object that can be used by any web service consumer—that sends and receives SOAP message requests for mathematical functions to each of the original objects. It makes no difference to the calculator web service that addition is a Visual Basic object while division is a Java object. It only “sees” the SOAP interface.
Of course, if you are developing new software from scratch, you may expose your new objects as web services. Then, you don’t have to go back and “expose” them later with standardized interfaces. It should not be a knee-jerk reflex to do so, though, because opening objects up to universal use also brings about some challenges. For instance, the functionality of an object may have to differ from what you originally intended if you decide to make it available to a much broader group of consumers than planned. Still, by encouraging reuse on a practical level for the first time, web services have great potential to make software development more efficient.
Web services also have the potential to reduce one of the greatest hassles in the IT world: the redevelopment of software to conform to migrating hardware and operating system criteria. Take the situation presented in figure 5.12, which is all too common in corporate IT. A COBOL application, developed in 1975, is rewritten in C when the company modernizes and switches to minicomputers in the early 1980s. When the minicomputer becomes undesirable for any number of reasons, the company rewrites the software in Visual Basic for Windows in 1999. Then, in 2003, a
merger with an “all Java” company necessitates the rewriting of the application again because the Windows hardware and operating systems will no longer be supported in the new company.
This continual rewriting process is costly and time consuming on many levels. Not only is it costly in real dollars—someone has to do this hard work—the process distracts from improving systems and accomplishing other pressing tasks. Each time that you migrate an application to a new language and platform, you may accidentally create bugs that elude discovery until after the new system has gone live. Rewriting the VB application in Java is an option, but rewriting is problematic. Every CTO has a nightmare story of finding out, months after launching a system, that it is calculating sales tax the wrong way, or incorrectly for a set of customers, or some such problem that might easily cost the company millions of dollars. Or the new system might cause some unforeseen conflict with other systems in the enterprise architecture, creating a breakdown in critical business processes.
By exposing the application as a web service, you can, in many cases, avoid having to rewrite programs for new platforms. In our example, when the company merges with the “all Java” company in 2003, instead of rewriting the program to create a common platform, you can instead expose key capabilities as web services. You then create web service consumer programs in your Java environment that enable the Java systems to interoperate with the Visual Basic program without “caring” if the underlying code is Visual Basic or anything else.
It is important to note that in this scenario you have to continue to support this Windows machine for as long as you support consumers of the web services it offers. Some people do not like having to manage that kind of heterogeneous operating system environment in their data center. However, when you weigh it against the issues involved in rewriting the program, web service exposure probably starts to look like a pretty good idea.
| home / programming / enterprise / 1 | [previous] [next] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: March 27, 2003
Revised: December 2, 2005
URL: http://webreference.com/programming/enterprise/1
