Identification, Specification, and Development of Web-Oriented Architectures

Introduction

In the technology dependent world of today, where most business workflows are supported through IT, the quality of software is a key factor for economic success. Indeed, the development of IT systems has been following the current paradigm of the software industry at all times. The abilities and chances of distributed systems have been recognized in the early 1990s and have become an integral part of many system architectures ever since. Moreover, the cross-linking of systems has been supported and been made easier through the invention of the Web.

Many concepts have been proposed for distributed systems, including Remote Procedure Call (RPC), the Common Object Request Broker Architecture (CORBA), alternatives like Remote Method Invocation (RMI) and others. At present, the most commonly accepted, yet controversial architecture is the Service-oriented Architecture (SOA). This architecture has been discussed intensively in science and industry since its first appearance in the mid-90s, but there is still no generally accepted methodology for modeling a SOA. It has even been declared “dead” by Burton Group analyst Anne Thomas Manes in the beginning of 2009¹. The various approaches that have been described in the literature aim at methodologies for planning and implementing a SOA, but none of them has become a “standard” in any form. On the other hand, there are several existing technological standards which are commonly used for implementing a SOA, e.g., Web Services for the communication between software components, Universal Description, Discovery and Integration (UDDI) as a repository of services, and SOAP as an XML based message format. Even with the support of code-generating frameworks and tools the implementation of a SOA still stays complex.

Recent developments in the context of Web 2.0 show how easy it can be to link or compose IT components dynamically, so that the original SOA goals of flexibility, reusability, or reduction of complexity can indeed be achieved by relatively simple means (Thies & Vossen, 2008). At this point, the idea of Representational State Transfer (REST) by Fielding (2000) is often used in a Resource-oriented Architecture (ROA), which uses the Web in a way it was originally intended: by using the Hypertext Transfer Protocol (HTTP) methods as actions only. An interesting concept in this context is that of a Web-oriented Architecture (WOA). It represents a specialization of a SOA obtained by using simple technologies and standards (e.g., HTTP, SSL, and JSON) which have existed for years but recently got pushed by the Web 2.0 boom. A WOA can be positioned between SOA and ROA and uses technological standards from both these concepts where applicable. The main aspects of our understanding of a WOA are subsumed by the following definition: A Web-oriented Architecture is taking SOA to Web APIs by using simple Web standards and try to source out as much functionality as possible.

In this article² we first describe the building blocks of a WOA as well as a method for its design and implementation. Thus, three aspects of WOAs are characterized: at first the identification, then the specification of a WOA. The third part deals with the development of such an architecture on the basis of an agile development method, which also includes an economical outlook in the form of a cost model. Note that there is no specific requirement dictating the usage of a specific methodology such as Feature Driven Development (FDD). However, by using an agile methodology, we gain several advantages not only for the design and implementation process, but also for the computation of the costs for planning, implementation, and operation.

Our first goal hence is to develop a systematic understanding of what a WOA represents at a conceptual, technical, and architectural level when compared to SOA and ROA. After that, integration scenarios as well as an important architectural aspect, the so-called Web Architecture Controller (WAC), are described. The main idea behind a WAC is the distribution of control instruments in the cloud that are able to connect Web procedures with each other and the application relying on them. Building on this, we sketch an agile methodology for designing WOAs. We favor an agile approach since it seems to be a perfect match for implementing a WOA, in terms of adaptability, speed of development, and cost control. Next, a sample case is presented that indicates how the management and monitoring of a WOA can be achieved. Finally, a brief overview of a cost model for WOA is given.