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.
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!
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.
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.
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.
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.
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:
• Literate modeling
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.1 He further argued that virtuality is about designing software conceptual structure and feel.2
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.
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
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.
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.3 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?
The service-oriented anthropomorphic modeling approach provides easy mechanisms to address analysis, design, and architectural challenges and perceives software assets as having human characteristics. In the virtual world that we are commissioned to create, services “interact,” “behave,” “exchange information,” and “collaborate;” they are “retired,” “promoted,” “demoted,” and “orchestrated.” Inanimate software entities are often treated as though they had human qualities. This “literate modeling” approach obviously enhances the strategies that are pursued during business initiatives and projects.
The service-oriented modeling paradigm regards all organizational software assets as candidates for modeling activities. We not only conceive them as our service-oriented modeling elements, meaning services, but we also evaluate them based on their contribution to a service-oriented environment, in terms of integration, collaboration, reusability, and consumption capabilities. These assets are also subjected to the modeling discipline activities depicted throughout this book. They are the enduring artifacts of the service-oriented modeling process and are regarded as units of concern, discovery, analysis, design, and architecture in a business initiative or a service-oriented project.
Exhibit 1.2 illustrates the various service-oriented software assets that can be involved in providing solutions to organizational concerns: concepts, foundation software, legacy software, repositories, and utility software.
Business or technical concepts embody an organization’s formalized
ideas, which are regarded as
components of propositions to organizational concerns. These abstractions
typically capture enterprise problems and offer remedies to alleviate negative
effects on business execution. Concepts characteristically offer direction and
strategy to the service-oriented analysis, discovery, design, and architectural
disciplines. They also contribute to the establishment of a common
organizational business and technical terminology that can be employed to fill
in the communication gaps between business and information technology (IT)
Organizational empowering middleware and platform products are the basic software ingredients of the service-oriented modeling practice. Middleware products offer integration, hosting, and network environment support, including message orchestration and routing, data transformation, protocol conversion, and searching and binding capabilities. This software asset category may include application servers, portal products, software proxies, SOA intermediaries, gateways, universal description, discovery and integration (UDDI) registries, and even content management systems. Message-oriented middleware (MOM) technologies are also regarded as middleware, which may include traditional message busses or enterprise service busses (ESBs). Conversely, software platforms are akin to frameworks that enable languages to run. This category may also include operating systems, runtime libraries, and virtual machines.
“Legacy” refers to existing software assets that are regarded as applications. These include business and technology software executables that already operate in the production environment. The term “legacy” also includes deployed organizational services such as Web services and even services that are running on a mainframe or other platforms and do not comply with Web service technologies and standards. Third-party vendor applications, service consumers, and partner services that operate outside of an organization are also conceived as legacy software assets. Customer Profile Service, Accounts Payable Application, or Trading Consumer are examples of existing and operating legacy software products, offered by third-party vendors or custom built by an organization’s internal development personnel.
Repositories play a major role in most service-oriented modeling activities. This software category is characteristically provided by third-party vendor products that require organizational adoption and integration policies. These are software entities that offer storage facilities, such as relational databases, data warehouse repositories, and various database storage management products, such as data optimization and replication. The repository category can also include data-about-data, meaning repositories that do not necessarily store the actual data but describe it. These are known as meta-data repositories. We employ these storage facilities for a variety of management and data organization purposes. For example, meta-data repositories are used for governance rules, service life cycle management, security policies, search categories, and document management.
Utility executables are typically regarded as nontransactional software assets employed to facilitate flawless system operations in a production environment. These utilities chiefly offer performance-monitoring services, enforce service-level agreements (SLAs) between consumer and producers, track security infringements, and provide alert mechanisms in case of contract violations or system intrusions. Moreover, software utilities also provide provisioning and asset portfolio management facilities and even message mediation policy management between message exchange parties.
The service-oriented modeling process is characteristically overseen by SOA governance and SOA Center of Excellence enterprise bodies that provide best practices, standards, guidance, and assistance to service-oriented modeling activities. Moreover, the modeling process involves two major stakeholders, the problem and the solution domain organizations, typically managed by business and IT personnel that partner in an array of business and technological initiatives, such as a small project or a large service life cycle venture that may include a number of smaller projects.
The involvement of two major stakeholder groups is
anticipated, each of which represents a different perspective; they are both
vital contributors to a service-oriented modeling effort. In addition, they
must collaborate and jointly facilitate alignment between business and IT
organizations. Exhibit 1.3 illustrates these two major views that
collaboratively contribute to the service-oriented modeling process: the
business view and the technological view. Note the overseeing governance and