is positioned at the top of the hierarchy.
5.5
Functional Design
The functional design will also have to weigh technological aspects that have a strong impact on the Web application under development. We have to observe the commensurability of our means, but our applications should be expandable, scalable, and maintainable, among other things. Particular difficulties are seen in the interplay of components. Web applications like
news tickers can normally do without transaction support, while online shops may have to
map many product phases, from configuration over ordering to repair. This requires transaction and workflow support and the integration of legacy databases and software systems. Chapter 4 discussed appropriate approaches in connection with Enterprise Application Integration (EAI).
5.5.1 Integration
We can integrate systems on three levels, which are to be interpreted as sub-levels of the functional design: the data level, the application level, and the process level.
In integration on the data level, we make sure that the data between the representations of different applications are transformed and copied. Examples include primitive transformation steps between the data export from one application and the data import into another application, or the use of JDBC to link databases. This approach doesn’t involve the applications themselves, and it doesn’t let us validate the data.
In integration on the application level (also called object level), the interplay occurs over APIs, which means that time and semantics are closely interleaved. However, many details depend on the middleware used for coupling; this issue will be discussed in the next section.
Integration on the process level is normally seen as the highest level, because it models business models independently of the infrastructure used.
5.5.2 Communication Paradigms and Middleware
Middleware has been mentioned above as a technology to link applications. Existing approaches differ strongly in their complexities and objectives, as discussed in Chapter 4 and section 5.2.3, where we briefly described Inter-Process Communication (IPC), Remote Procedure Call (RPC),
Event-Based Communication (EBC), Message-Oriented Middleware (MOM), and distributed object-oriented approaches.
The XML-based approaches mentioned in different places in this book will be summarized below in preparation for the following sections. XML as an emerging lingua franca of the Internet is the basis not only for a “better Web/HTML” and the portable specification of semi-structured data, but also for new distributed application standards, particularly the Simple Object Access
Protocol (SOAP), the Web Service Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI), to mention a few. SOAP handles messages and calls over
address Web services, and UDDI provides a sort of database to publish and search for Web services (see Chapter 6 for details).
5.5.3 Distributed Cross-corporate Web Applications
The distribution aspect has gained increasing importance in the software-side implementation of Web applications. Just as links to remote Web pages are common today, distributed software will emerge from the meshed access to remote Web applications in the future. This can be interpreted as service-to-service communication, where the term service characterizes functionality offered over a well-defined interface. Web services have increasingly been implemented on the basis of XML. For example, eBay provides not only one single authentication system, but also supports Microsoft’s Passport, and Google allows you to integrate their search function into external applications via SOAP. This “coarse-grained open component market” has dramatic consequences for system designers. The use of externally developed functionalities saves development costs, and the quality of components (services) may be better but this typically comes at the cost of losing “control” over these services. For example, security holes in Passport have dampened the initial enthusiasm, and the acceptance threshold for external services in security-critical applications is very high. On the other hand, a component-based approach can help to justify the money we spend for high-quality software products due to their high degree of reusability, and establish confidence in the quality of these components. Over the medium term, we therefore expect a market for Web Services, comparable to the wealth of services offered in our daily lives. Building on XML and basic technologies like SOAP, WSDL, and UDDI, other protocols are currently emerging, of which some are complementary and some are competing. These are protocols of the type necessary to handle business across the boundaries of a company. Figure 5-3 gives an overview of how these protocols depend on each other.
SOAP WSDL WS-Coordination WS-Transaction WCSI BPEL UDDI WS-Security
Figure 5-3 Protocol stack for Web services.
The Web Services Transactions Specifications (WS-Transaction) describe an extensible framework to coordinate actions in distributed applications (WS-Coordination) and specific coordination types for atomic transactions and business transactions (IBM 2005a). Atomic
Transactions allow you to coordinate short actions based on the 2-Phase-Commit protocol. This
approach is suitable particularly to encapsulate proprietary formats of current transaction-oriented systems. Business activities in contrast are intended for long-lived actions, since they do not block resources over a lengthy period of time.
5.6 Outlook 107 The Web Service Choreography Interface (W3C 2002a) and the competing Web Services Conversation Language (W3C 2002b) offer a way to specify messages participating in a service and their structures as well as the sequence in which these messages should be exchanged. BPEL4WS (Business Process Execution Language for Web Services), or BPEL for short (IBM 2005a), builds on the former, allowing describing complex business processes (workflows). BPEL can be used to describe control flows and dependencies between participating processes.
In addition to BPEL4WS and WSCI/WSCL (which is suitable not only for the purpose discussed here), a number of other manufacturer-specific protocols are available to describe business processes in XML. (Bernauer et al. 2003) includes a more detailed comparison of the protocols mentioned here and other protocols, which are not based on the Web services protocol stack.
Another important issue for business over the Internet concerns security aspects, briefly outlined in Figure 5-3 with WS-Security as an example. Authenticity, confidentiality, integrity, and non-repudiation play a central role in this issue. Chapter 13 will discuss this issue in connection with Web services.
Based on the business-to-business (B2B) approach, Web applications appear to evolve into huge systems distributed over many computers. This approach integrates not only a company’s internal applications, but also third-party applications (services). Some companies already have extensive access to third-party applications under the catchword Supply Chain Management (SCM). Web services are expected to standardize this approach on the Web. Some research work has already been undertaken to select services on the fly as needed, depending on the situation. The Service Provisioning Markup Language (SPML), which can be used for the billing of services used, represents a first step towards this direction.
5.6
Outlook
The so-called post-PC era is no longer dominated by one single class of devices (the PC), but characterized by a large number of different devices. During the next few years, mobile devices will be of major importance, as mentioned in section 5.3.2. Therefore, in order to be
sustainable, Web applications have to be prepared for this trend today, namely by considering two
important concepts, i.e., context awareness and device independence, which will be discussed in sections 5.6.1 and 5.6.2, respectively. Since the first of these two concepts is still in the research stage, section 5.6.1 will just explain aspects that should be observed in the design of context-aware Web applications. Section 5.6.3 will exclusively focus on giving an outlook on new or missing concepts in engineering that could generally promote the sustainability of Web applications in the future.
5.6.1 Context-aware Applications
A context-aware application is an application that takes user-specific knowledge – a user’s context – to optimally customize both its interaction and its function. In addition, context awareness leads to new types of applications, e.g., Location-Based Services (LBSs), to mention
about restaurants in a user’s neighborhood. An almost unlimited wealth of more sophisticated variants is conceivable, e.g., a user’s culinary preferences, or electronic local traffic information. A number of problems will have to be solved to be able to broadly introduce this type of sophisticated application. These problems are not only of technical nature, e.g., with regard to making the required context information available. Telecom operators have begun only hesitantly to provide third parties with technical measures and interfaces for LBS, and they normally ask high prices. In view of the enormous sales potential, telecom operators seem to be interested in offering context-aware services themselves or through selected partners. The lack of competition and, consequently, the low quality of the services currently offered make this business model appear doubtful.
Another major hindrance to the introduction of context-aware Web applications is that users want confidentiality. LBSs in particular have been discussed by arguing whether or not third parties could reconstruct and misuse the location of users. The benefits of context-aware Web applications as well as a growing confidence and better technical security should help overcome these obstacles over the medium term.
Clear progress has been observed in the technical support for context-aware Web applications. As described in section 5.5, there are platform-independent protocols to describe and combine Web services. Also, there are public databases to register Web services and to search for suitable services. However, this merely creates possibilities to collect information about user contexts and link services. The problem regarding uniform context descriptions remains unsolved. For example, a telecom operator can collect a user’s location from the cell ID, and supply the GPS coordinates of the mobile base station with which that user is registered. Triangulation can be used to some extent to narrow down the location. However, many applications such as local traffic information systems or pedestrian navigation require street names (or even landmarks) instead of geographic coordinates. Corresponding standardization efforts are under way, but many details still have to be clarified in research projects. If we look at the example of a restaurant guide, then ubiquitous Web applications would require accepted classifications of restaurants or dishes across all gastronomic outlets. Such issues demand for efforts in the field of the semantic Web (see Chapter 14). The two examples used in this section show that extensive standardization is one of the most important prerequisites for ubiquitous context-aware software.
5.6.2 Device-independent Applications
The manufacturers of Web Engineering tools have long understood the problem of device- independent applications but they have suggested too optimistically that the problem could be solved by transforming a generic (XML-based) presentation to the markup languages used by devices (HTML, WML, etc.). Different implementations of user agents, operating system guidelines, and physical and technical differences of the devices represent major obstacles in practice. To mention a few examples: partly incomplete implementations and different HTML versions, different extent of available user interface elements (e.g., list boxes, radio buttons), screen size and orientation, and limited computing power or network bandwidth. These restrictions have led to several proposals, including WML as a specific markup language for mobile devices.
We can basically identify two alternative approaches in the development of device-independent applications. The first is a “minimalist” approach, which reduces the elements used to a minimum,
5.6 Outlook 109 assuming that all potential devices will support these. A major drawback of this approach is that both the usability and the look and feel of applications are knowingly reduced. The second approach develops adaptive applications, integrating the user context on several levels. In this approach, device independence considers not only the aspects of the actual physical device, but merges seamlessly with the context awareness discussed in section 5.6.1. For the implementation itself, various technologies and standards are available and others are in the works at standardization bodies. Building on the work of the CC/PP Working Group, the Device
Independence Working Group (DI WG) (W3C 2001c) of the W3C defined the CC/PP standard
and a pertaining transmission protocol to describe and transmit user and device contexts. CC/PP can be used to uniformly describe context profiles and transmit them to an application server.
Current adaptation modules interpret parts of the HTTP protocol (e.g., the user agent identification) as an alternative to yielding – proprietary – context information. And different technologies are used to actually adapt applications. Script languages (e.g., JSP/ASP), combined with transformation models (XML, XSL, XSLT), are frequently used for adaptation on servers, while standards like XHTML and CSS in connection with scripting (JavaScript) are used for transformation on clients.
Transcoding servers use an alternative approach for the adaptation of applications, where
the adaptation transforms a generic description of an application into a new destination format. Initially, people tried to transform an existing HTML-based description into a new destination format (e.g., WML) without adding semantic information, which didn’t produce satisfactory results. Today, adaptation occurs on several levels of a Web application. For example, (1) the complexity of the entire application is adapted to the user context and the available device (adaptation of the application logic); (2) the content and layout of pages are optimized; and (3) the presentation is optimized to the addressed/existing implementation of a markup language. 5.6.3 Reusability
Reusability has received less than its fair share of Web application technologies, and some technologies even lack conceptual prerequisites for reusability. The fact that appropriate concepts play an important role in the design can be seen in object-oriented programming or in object- oriented design. The following subsections will briefly discuss three fields of research and development that promise to substantially promote reusability as representative examples. Concepts for Meshes
The current support for concepts that allow to elegantly designing meshes composed of elements
and links is poor; it is insufficient for the software design and for the information design of Web
applications. What’s required are particularly concepts for aggregates (see section 5.2.2) and hierarchies thereof.
Mature Type Concepts
Types of elements and links similar to those introduced in section 5.2.4 were fairly common in information design during the HTML era, and they are now experiencing a revival with XML
(though not yet popular). In software design (see UML), types (classes) of elements are supported satisfactorily, and they are also supported by class hierarchies and modern component concepts in object-oriented software technology. However, no current design notation has uniform concepts to typify elements and links in integrated Web design. While type concepts for elements and links (and also for anchors, which are not discussed here for reasons of space) are relatively easy to develop and have been used by Web designers, type concepts for meshes are still a challenge for further research work (see M¨uhlh¨auser et al. 1998a, M¨uhlh¨auser 1998b). In particular, the design of reusable meshes should be of primary importance in this research, so that, for example, best
practices could be modeled in the design of extensive Web sites, corporate presences, Web-based
training concepts, etc. Such mesh design concepts should allow describing the dynamics, i.e., changes to the number and arrangement of elements and links, both over a mesh’s lifecycle and in different incarnations of a mesh type. At best, the Resource Description Framework (RDF) can be considered a rudimentary approach towards this direction.
Alternative Composition Concepts
The meshes discussed here represent directed graphs. In view of advanced programming concepts, e.g., event-based communication and advanced hypertext concepts liken-ary links (which are
partly supported in XML-based standards), it is assumed that the concept of a “mesh” as such would have to be enhanced. However, no current work in this direction is known to the authors.