Functional Design

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 different Internet protocols, e.g., HTTP, SMTP, etc. WSDL serves to describe interfaces and

106 Technology-aware Web Application Design 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.

WCSI

BPEL WS-Transaction WS-Coordination

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.