As human beings, we are passionate about new ideas that promise to transform our lives and create new opportunities. We also tend to rapidly replace old technologies with new ones. Ours is a versatile society that runs on tomorrow's software piled on top of the technology layers of yesterday and today.
Try to imagine the next breakthrough that will supersede today's examples of human ingenuity. Will it be miniature software installed on microwave ovens or refrigerators that monitors a diet prescribed by a personal nutritionist? Could it be a smart software component that not only designs itself but also architects its own operating production environment? Or perhaps a virtual software development platform that enables business and technology personnel to jointly build applications with goggles and gloves?
These futuristic software concepts would probably contribute yet another layer to our already complex computing environments, one requiring resources to maintain and budgets to support. This layer would sit on top of technological artifacts accumulated over the past few decades that are already difficult to manage.
Not long after the new millennium, discontent over interoperability, reusability, and other issues drove the software community to come up with the service-oriented architecture (SOA) paradigm. Even readers who are not familiar with SOA will probably agree that it is rooted in traditional software development best practices and standards. To fulfill the promise of SOA, superb governance mechanisms are necessary to break up organizational silos and maximize software asset reusability. The SOA vision also addresses the challenges of tightly coupled software and advocates an architecture that relies on the loose coupling of assets. On the financial front, it tackles budgeting and return-on-investment issues. Another feature that benefits both the technological and business communities is a reduction of time to market and business agility. Indeed, the list of advantages continues to grow.
But does the promise of SOA address software diversity issues? Does it offer solutions to the integration and collaboration hurdles created by the accumulation of generations of heterogeneous computing landscapes? Will the SOA vision constitute yet another stratum of ideas and technologies that will be buried beneath future innovations? Will SOA be remembered as a hollow buzzword that failed to solve one of the most frustrating technological issues of our time? Or will it serve as an inspiration for generations to come?
It is possible that SOA may fail to deliver on its promise, but if it does, we, business and IT personnel, must shoulder some of the blame. SOA may turn out to be little more than a technological fire drill if we are ambivalent about the roles and responsibilities of legacy software in our existing and future organizational strategies; if we fail to tie together past, present, and future software development initiatives; and if we disregard the contributions of previous generations of architectures to today's business operations. Indeed, the idea of properly bridging new and old software technologies is a novel one. But what about establishing a more holistic view of the technological inventory that we have been building up for years? Can we treat all our software assets equally in terms of their analysis, design, and architectural value propositions? Can we understand their collaborative contribution to our environment without being too concerned about their underlying languages and implementation detail? Can we name these assets services? Can we conceive of them as service-oriented entities? Are they not built on similar SOA strategies and principles?
This book introduces service-oriented modeling mechanisms that will enable us to conceive software products that we have been constructing, acquiring, and integrating during the past few decades as service-oriented constituents. These entities-either legacy applications written in languages such as COBOL, PL1, Visual Basic, Java, C++, C#, or diverse empowering platforms and middleware-should all take part in an SOA modeling framework. Most important, they should be treated equally in the face of analysis, design, and architectural initiatives, and should simply be recognized as services.
A new SOA modeling language will be unveiled in this book that is not based on any particular programming language paradigm, constrained by language structure barriers, or limited to a language syntax. As a result of this universal language, the modeling process becomes more accessible to both the business and technology communities. This SOA modeling approach is well suited to provide tactical, short-term solutions to enterprise concerns, yet it furnishes strategic remedies to persistent organizational problems. So what is service-oriented modeling?
Service-oriented modeling is a software development practice that employs modeling disciplines and language to provide strategic and tactical solutions to enterprise problems. This anthropomorphic modeling paradigm advocates a holistic view of the analysis, design, and architecture of all organizational software entities, conceiving them as service-oriented assets, namely services.
SERVICE-ORIENTED MODELING: WHAT IS IT ABOUT?
Modeling activities are typically embedded in the planning phase of almost any project or software development initiative that an organization conducts. The modeling paradigm embodies the analysis, design, and architectural disciplines that are being pursued during a given project. These major modeling efforts should not center only on design and architectural artifacts such as diagrams, charts, or blueprints. Indeed, modeling deliverables is a big part of a modeling process. But the service-oriented modeling venture is chiefly about simulating the real world. It is also about visualizing the final software product and envisioning the coexistence of services in an interoperable computing environment. Therefore, the service-oriented modeling paradigm advocates first creating a small replica of the "big thing" to represent its key characteristics and behavior-in other words, plan small, dream big; test small, execute big!
A VIRTUAL WORLD. How is it possible to simulate such a business and technological environment that offers solutions to organizational business and technology problems? "Simulating" does not necessarily mean starting with the construction of a software executable. It does not imply instantly embarking on an implementation initiative to produce source code and build components and services. The service-oriented modeling process begins with the construction of a miniature replica on paper. This may involve modeling teams in whiteboard analysis, design, and architecture sessions, or even the employment of software modeling tools that can visually illustrate the solutions arrived at. Thus, the simulation process entails the creation of a virtual world in which software constituents interface and collaborate to provide a viable remedy to an organizational concern.
A STRATEGIC ENDEAVOR GUIDED BY MODELING DISCIPLINES. Creating a miniature mockup of a final software product and its supporting environment can obviously reduce investment risk by ensuring the success of the impending software construction initiative. This can be achieved by employing analysis, design, and architectural disciplines that are driven by a modeling strategy that fosters asset reusability, a high return on investment, and a persuasive value proposition for the organization.
Service-oriented modeling disciplines enable us to focus on modeling strategies rather than being concerned with source code and detailed programming algorithms. By employing this modeling paradigm we raise the bar from the granular constructs of our applications, yet we must accommodate the language requirements of the underpinning platforms. We focus on identifying high-level business and technological asset reusability and consolidation opportunities, but we must also foster the reuse of software building blocks such as components and libraries. We rigorously search for interoperability solutions that can bridge heterogeneous technological environments, but we also concentrate on integration and message exchange implementation detail.
A LEARNING AND VALIDATION PROCESS. By producing a small version of the final artifact we are also engaging in a learning and verification process. This activity characteristically would enable us to validate the hypothesis that we have made about a software product's capability and its ability to operate flawlessly later on in a production environment. We are also being given the opportunity to inspect key aspects of software behavior, examine the relationships between software components, and even understand their internal and external structures. We are involved in a software assessment process that validates the business and technological motivation behind the construction of our tangible services.
To better understand the key characteristics of a future software product and its environment, the assessment effort typically leads to a proof-of-concept, a smaller construction project that concludes the service-oriented modeling initiative. This small-scale software executable, if approved and agreed on, can later serve as the foundation for the ultimate service construction process.
EVERYBODY'S LANGUAGE: A UNIVERSAL LANGUAGE FOR BUSINESS AND TECHNOLOGY. We are often driven by tactical decisions to alleviate organizational concerns and to provide rapid solutions to problems that arise. The proposed service-oriented modeling language is designed to ease time to market by strengthening the ties between business and technology organizations. This can accelerate the delivery process of software assets to the production environment. Furthermore, the service-oriented modeling language can also be employed to fill in communication gaps and enhance alignment between the problem and solution domain bodies.
To achieve these goals, the service-oriented modeling language offers an intuitive syntax, a simple vocabulary, and a taxonomy that can be well understood and easily employed by various business and technology stakeholders during service life cycle phases and projects. The language can be utilized not only by professional modelers, architects, or developers, but by managers, business executives, business analysts, business architects, and even project administrators.
Exhibit 1.1 depicts the service-oriented modeling activities, language, disciplines, and benefits.
DRIVING PRINCIPLES OF SERVICE-ORIENTED MODELING
Service-oriented modeling principles capitalize on devised SOA standards already in use by organizations and professionals. These are best practices that are designed to foster strategic solutions to address enterprise concerns, and to overcome the shortsightedness that is frequently attributed to organizational tactical decisions. The following modeling principles promote business agility, software asset reuse, loosely coupled service-oriented environments, and a universal modeling language that can address software interoperability challenges:
Virtualization
Metamorphosis
Literate modeling
VIRTUALIZATION. Modeling software is essentially a process of manipulating intangible entities. These are typically nonphysical assets that reside in peoples' minds or appear on paper. An effective modeling process should be as visual as possible, enabling business and technology personnel to view software elements as if they were concrete assets.
The virtuality and reality aspects of our surroundings have been debated by numerous philosophers going back to the eighteenth century. The traditional assertions that "everything has a reality and a virtuality" or "everything other than what is virtual is reality" are in agreement with sociologist, philosopher, and information technology pioneer Ted Nelson's claim that virtuality is the focal point of software design. He further argued that virtuality is about designing software conceptual structure and feel.
The visual aspect of the service-oriented modeling paradigm is driven by the construction of a virtual world in which elements seem almost as tangible as real physical objects. This world that we create to simulate reality is made up of two major elements: (1) the landscape that "glues" all pieces together; meaning the environment that empowers and executes services and (2) the services that communicate, interact, and exchange information to provide business value. Moreover, a virtual world can effectively simulate a heterogeneous computing landscape by treating software assets as equal partners in a modeling endeavor. This effect is called federated modeling.
The visualization process that we pursue enables us to model relationships, structures, and behaviors of services that would provide satisfying solutions to organizational problems. These goals can be achieved by fostering asset reusability, promoting a loosely coupled computing environment, and resolving interoperability challenges across organizations.
METAMORPHOSIS. The business environment that we all share is a dynamic market that keeps evolving and changing direction and also influences technological trends and application development. This vibrant business landscape often dictates alterations to a service's behavior, structure, and relationship to its environment during its life span. These modifications typically start at a service's inception, when it manifests as an intangible entity-an idea-and then continue as the service evolves into a physical software asset that executes business functionality in production. This transformation process is the essence of the metamorphosis paradigm driven by service-oriented modeling disciplines that ensure software elasticity, and ultimately, business agility.
But the transformation process does not stop with the deployment of services to production. Imagine how frequently a valuable application is involved in multiple project iterations that lead to software upgrades. Think about the myriad instances of a service finding its way back to the drawing board to be redesigned and then ferried back to the production environment again. This is typical of the software development life cycle, during which software products are upgraded, enhanced, and redistributed.
LITERATE MODELING. Should a programming language offer a simple syntax that is easy to understand, and is intuitive and readable? Or should it offer formal grammar, rules, and symbols that only developers can handle? Should a programming language be based on machine-readable source code that is easy to debug and optimize? Or should it be considered a scientific artifact, a mathematical formula that only experts on the subject can deliver?
This long-running debate is believed to have begun in the early 1980s and encompasses two major approaches to software development that have major ramifications for the service-oriented modeling paradigm. The first was introduced by Donald Knuth's theory of "literate programming" in which he argues: "I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title: 'Literate Programming'."
The second approach was introduced by Edsger Dijkstra in his 1988 article "On the Cruelty of Really Teaching Computer Science," in which he claims that programming is merely a branch of mathematics. He writes: "Hence, computing science is-and will always be-concerned with interplay between mechanized and human symbol manipulation, usually referred to as 'computing' and 'programming' respectively."
This debate further informs the discussion about the modeling paradigm. Should service-oriented modeling be founded on a specific programming platform structure that only developers and modelers can utilize? Or should modeling disciplines offer universal and easy to understand notations that are independent of language? Should a service-oriented modeling approach be tied to fashionable technologies? Or should a modeling language offer tools to design and architect multiple generations of legacy platforms, applications, and middleware?
(Continues...)
Excerpted from Service-Oriented Modeling (SOA) by Michael Bell Copyright © 2008 by Michael Bell. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.