by Donald F. Ferguson, Dennis Pilarinos, John Shewchuk

Summary: Web applications are an extremely common application model, and they will become increasingly dominant. Almost all applications in medium to large businesses offer a Web user interface. In this article, we will use the term enterprise to encompass medium to large enterprises, and the software vendor and integrator companies. Desktop and client/server applications are increasingly using the browser for the UI engine and making calls to data and services through Web protocols.

Software, application models and the Web itself are undergoing a revolutionary transformation. This transformation will have as large an effect on computing as the client/server model or the initial emergence of the Web itself. The Web will evolve from connecting users to applications provided by sites into a model in which:

·         The application executes “in the Web.”

·         End-users develop their own applications for accessing the Web, transforming it into an end-user developed workspace for access to Web services.

This paper focuses on a small number of elements of the transformation. Other papers will expand the vision.

Several technologies and trends provide the impetus for the revolutionary transformation described above. Some examples are: multi-core processors; virtualization; application scenarios that federate many devices, such as mobile phones and tablets; Service-Oriented Architecture (SOA) and Web services; Web 2.0; and Software as a Service (SaaS).

We will discuss the effect of some of these trends, but our primary focus is SOA, Web 2.0, and Software as a Service (SaaS). These concepts and their relationships are not well understood. The technologies often appear to conflict. The paper describes the elements of a high-level reference architecture that brings the concepts together into a consistent whole.

Many of the preceding technology trends have broad acceptance and awareness. This paper discusses a third trend that is more controversial: ubiquitous programming ability. A large percentage of high school and college graduates have basic programming skills when entering the workforce; many students have developed simple PHP or Visual Basic applications and built Web sites. The professionals’ primary job responsibilities may not include programming, but in many cases professionals will do simple programming if it makes them more productive. They may also develop simple applications because it is “cool.” We will use the terms end-user programming for this concept.

End-user programming is an extreme case of opportunistic development, which occurs in departments and Lines of Business (LOBs) in enterprises. LOBs and teams often build simple, “quick and dirty” SharePoint or PHP applications that solve an immediate business problem by extending packaged applications or enterprise-wide core applications.

Opportunistic development contrasts with systematic development. Systematic development is model-driven, replete with requirements gathering, use cases and stakeholder interviews, an application development life cycle that includes quality and assurance, and so forth. Systematic development is the predominant model of the enterprise development team (“the CIO team”). Many packaged application developers (independent software vendors or ISVs) and Systems Integrators (SIs) also produce systematic solutions.

There is a tension in enterprises between opportunistic development and systematic development. This tension will increase if end-user programming becomes common. End users will not be content to wait for the systematic development teams to develop or modify solutions. The reference architecture we describe provides an approach for reconciling the extremes of opportunistic and systematic development.

We use a scenario to illustrate the reference architecture. A core element that emerges and underpins the architecture is an Internet Service Bus (ISB). The reference architecture encompasses many elements, however, this paper provides detail only for the ISB. Other papers will describe other elements.

Contents

The Scenario and Opportunistic and Systematic Development
Software and Services, and an Internet Service Bus
Conclusion
Resources
About the Authors

The Scenario and Opportunistic and Systematic Development

Dave travels frequently on business, and uses preferred hotels and airlines. He uses local town car services in the cities he visits and makes reservations at restaurants. Collaboration with friends, family and colleagues is also important. Dave uses the various travel providers’ Web sites to make and change travel plans.

Dave’s managing of trips involves a lot of manual tasks interacting with travel providers through their Web sites. He has to manually coordinate tasks that span sites and cut and paste data between fields. There is also some sequencing logic, for example booking a restaurant reservation and car service to get to the restaurant. Dave acts like a composite application or Enterprise Application Integration (EAI) solution. The manual work is tedious and error prone. Dave has basic programming skills and decides to write a little mashup. The mashup uses the travel providers’ Web sites through client-side Web page scripting or simple HTML clipping (Figure 1(a)). The mashup makes Dave’s life a little easier and makes Dave more productive at work because he spends less time managing his travel and more on his job. The mashup is also cool, which impresses his friends.

Mary and Ludwig like the application and get the code from Dave. They want to have different UIs but share code. So they improve the application by separating the UI from the Web site access, scripting, and caching by implementing a simple model-view-controller version (Figure 1(b)). The improvement also enables code reuse for access through other devices like PDAs or mobile phones (Figure 1(c)). Finally, they decide to move the model layer to a department Web server and implement a simple Web application. This enables multi-person access to information, for example for assistants.

The friends have opportunistically built a composite application, which is a simple pseudo-EAI solution. As programming-capable professionals enter the workforce, these ad hoc and just-in-time applications will become more common. There is the “cool factor” and the applications will simplify tedious tasks. Professionals may also build the applications “just in time” for short duration business problems, such as a convention. The applications are analogous to the role of spreadsheets when a user performs a business task by accessing existing databases and core enterprise applications.

Opportunistic situational applications will have a profound effect on enterprises’ systematic application delivery. One effect will be on enterprise application development. The situational applications may “pound on” core enterprise applications, or use the core systems in unexpected ways. This will cause the IT organization to move some of the “model layer” to enterprise servers to improve performance and integrity.

In essence, the situational applications have defined use cases that can drive systematic enterprise application transformation. The situational applications can replace simple mockups for documenting use cases, and can drive formal modeling.

Many pressures will move as much of the situational applications to enterprise servers as possible. There may be partners that need to use the application, which requires enterprise security. Some applications may be part of important business decisions like loan approval. Governance and compliance will require logging data access and input, and saving versions of the code for these applications. Moving the situational applications to the data center has profound implications. The data center will need to support hundreds or thousands of frequently changing applications in addition to the core business solutions. The data center needs to manage dozens of heavily loaded core application servers accessed by thousands of users, and thousands of virtual servers infrequently access by small teams using ad hoc applications.

There are many scenarios in which systematic solutions consume opportunistic applications. Dave will think it is very cool if IT uses one of his applications.

In summary, opportunistic applications drive systematic solutions and systematic solutions drive hardening of opportunistic applications (for example, Representational State Transfer (REST) -> Web services). These dynamics also drive software as a service, or more accurately, software and services. Software and services provides a platform for bringing together systematic and opportunistic application development and delivery.

Figure 1: Mashup Evolution (Click on the picture for a larger image)

Software and Services, and an Internet Service Bus

Enterprise Service Bus

Consider what happens if an airline cancels Dave’s connecting flight from Dallas to San Francisco while Dave is traveling from New York to Dallas. Dave will not make it to San Francisco and he will need to stay overnight in the connecting airport city. It is necessary to change hotel, restaurant, and car service reservations. Dave could use his mashup to simplify making changes when he gets off the airplane. It would be better (“cooler”) if rebooking could occur automatically while he is flying. Airlines and flight monitoring sites emit feeds with flight schedule updates. Ideally, Dave’s application would be always executing somewhere “in the cloud.” The application would monitor feeds and use simple logic to react to events and change the itinerary and plans.

It is unlikely that a simple end-user application could always repair the itinerary, but most repairs are often simple. Dave would only manually handle the complex cases, and could also approve the changes his application automatically made while he was flying.

The general application scenario of repairing the itinerary is a common type of problem within enterprises. Similar problems can occur for purchase orders and expense account approval, for example. The scenario is an example of a composite application that implements a Straight-Through-Processing (STP) pattern (see Resources). Enterprises implement a systematic approach to solving these problems. Figure 2 provides an overview of what the composite application might look like if the airline, hotel, restaurant, town car and other systems were within the enterprise firewall. A relatively long running orchestration process subscribes to events that the flight management system emits. The process sends messages to/from and calls the existing applications to cancel reservations, query availability, and make new reservations. Enterprises are heterogeneous and the existing applications have diverse message formats (C, COBOL, and so on) and communication protocols (WebSphere MQ, SAP RFC, for example).

Figure 2: An Enterprise Business Process (Click on the picture for a larger image)

The repair process design shown in Figure 2 is fragile. The business process must change if another airline application is added, for example. The business process may also be coupled to specific message formats and languages of the existing applications. It would be difficult to add a general mechanism for logging messages that match certain conditions—for example, log all messages if the traveler is an executive. This fragility has led enterprise application architectures to evolve to an enterprise service bus (ESB).

Figure 3 provides an overview of an enterprise service bus. Application adaptors convert existing formats and protocols into standard Web services. This transforms the NxN protocol/format mapping problem of connecting anything to anything into N->1 mapping problem—that is, everything into a standard. The ESB provides additional functions that process messages flowing between services. Examples include message transformation, logging, and routing.

Figure 3: An Enterprise Service Bus (Click on the picture for a larger image)

If the enterprise development and business units of Dave’s company decided that implementing his travel application were important enough to fund, the enterprise team could implement an application similar to Figure 3. There are several problems with developing this systematic solution:

1.      There is no guarantee that the enterprise would choose to fund the composite application. There may be other, more pressing business problems.

2.      Systematic development involves use cases, some form of process modeling, interviewing stakeholders. These take time.

3.      The airlines, hotels, and other applications are external to the enterprise. Enterprises are very deliberate and cautious about setting up business-to-business connections. Even if the business partner implements Web services, the enterprise will need to establish authorization rules and auditing for Web service interactions with partners. The enterprise will need to support user identity management, federation, and provisioning because an employee will have an intra-enterprise identity and identities in the airlines and hotels.

4.      Customizing the solution for individual employees’ preferences is complex. The employee lacks the ability to perform “do it myself” customization. The application resides on central enterprise servers. IT professionals define and modify the business process, not Dave.

It would be really cool if Dave could do a simple, personal version of the systematic solution. If we generalize the ESB and think of it as one type of service bus that is optimized for systematic enterprise development, we could also imagine a type of service bus that is optimized for opportunistic development. This is the Internet Service Bus (ISB). The ISB is more like a ubiquitous fabric. The ISB links devices to each others, devices to local servers, Web sites to Web sites, and ESBs to ESBs, and is itself an ESB. The ISB is a platform for “do-it-yourself” composite applications and business processes. The ISB is also an example of Software as a Service (SaaS).

Internet Service Bus

Figure 4 provides an overview of the Internet service bus concept. (An early example of an ISB is BizTalk Services; see Resources.) An ISB provider is analogous to a PHP Web site hosting company. Both provide an application platform in the “cloud.” A PHP Web hosting site primarily provides a platform for developing dynamic Web sites and Web services that interact with a database. In contrast, the ISB provides a platform for creating and deploying composite applications that integrate services that other sites provide. ISBs, PHP Web hosting companies, and storage as a service such as Amazon’s S3, are examples of application enablement infrastructure software as a service. This contrasts with Salesforce.com, which was initially packaged application software as a service.

The core ISB concept is built around a Uniform Resource Identifier (URI) space. Dave’s team working on the application registers and “owns” the URI http://ISB.net/DaveAndTeam. URIs below this root represent application integration points, and are similar to destinations in the Java Messaging Service, queues in message-oriented middleware, or topics in publish/subscribe systems. The team develops an ISB application by associating policy and function with URIs. The composite application is a set of URIs, policies and functions. The ISB provides an identity and access function for controlling which messages can be sent to a URI, and by whom. The identity and access function is an example of associating a policy with a URI.

For example, Dave may choose to maintain a wiki page on a public Web site that shows his travel reservations. Dave will want to control access to the wiki page. Setting up and maintaining authentication and authorization databases at his personal Web site can be tedious. The problem will become more complex if Dave has pages and data at several Web sites, for example:

·         His personal database driven PHP site

·         A family collaboration portal built using http://www.twiki.org/

·         A presence on a spaces site like Windows Live Spaces (http://home.services.spaces.live.com/).

Figure 4: An Internet Service Bus (Click on the picture for a larger image)

Dave’s friend Don can register with the ISB’s identity component and create a user ID don@foo.bar. Dave can use the identity component’s Web UI to specify which of Dave’s ISB URIs Don can access. Dave can also define groups and grant access to the groups. Don can access the URIs after having logged onto the ISB. The ISB simplifies Dave’s security management because he can maintain a central database, and then authorize the “ISB” to access his wiki and other resources. The ISB protects the actual resources through access control for the ISB URIs that front them. The ISB benefit is that there is a single space for Dave to define and maintain identities, groups, resources and access policies for all of his “services” on the Web.

We’ve just described explicit user actions through Web pages. Another very common approach will be to have the applications at endpoints participating in the composite application use Web service APIs to access the ISB.

The identity component will also support WS-Security’s Security Token Service (STS) functions, and federate with other STSs. This allows Dave to manage access for identities not registered with the ISB. If foo.bar was a company that Dave trusts and implements an STS, Dave can define access policies for identities authenticated foo.bar.

Over time, ISBs will offer additional policies and implementations that can be attached to URIs. Examples may include WS-Reliable Messaging or implicit message logging. The concept is similar to associating quality-of-service policies with connections in message-oriented middleware.

The ISB builds on the identity and access capabilities to provide “secure universal connectivity” for applications – even for applications located behind firewalls. This includes support for a wide range of connectivity patterns and protocols. Examples include REST-oriented HTTP, WS-*, and the event-driven patterns found in many enterprise applications. Specifically the ISB’s connectivity component offers three core functions:

1.      Relay enables communication between the ISB and applications behind firewalls. There are many techniques for accomplishing this capability (Biztalk Labs, see Resources). The relay function eliminates the need to set up systematic cross-enterprise connections for simple scenarios.

2.      Protocol provides a set of common protocols for exchanging messages, such as WS-* or REST. The ISB also provides protocol mapping for automatically connecting endpoints using different protocols. For example, it is possible to connect an RSS feed to a WS-* message connection without modifying either application.

3.      Functions provide support for associating simple ESB-like functions to the URL. Examples could include multicast, WS-Eventing, persistent messaging, etc.

The connectivity layer operates at the infrastructure technology level. It simplifies solution development by removing complexity due to different “plumbing”—for example, REST versus WS-*. Projects that must implement infrastructure integration at this level incur significant cost and risk. The ISB eliminates these problems.

The connectivity layer is unaware of application level elements and message formats. Building a composite application requires adapting between different message formats that the connected services implement. An example of the ISB’s functions would be converting the parameters in an HTTP GET into elements in an XML message. The ISB offers a simple workflow (service choreography) that provides support for application level mapping (Figure 5).

Figure 5: ISB Message Processing (Click on the picture for a larger image)

The ISB offers a set of template “activities” for simple functions. A workflow is a graph composed of instantiating activity templates. Suppose that the airline emits flight status through an RSS feed and part of Dave’s application expects to receive WS-Eventing notifications for the updates. The connectivity layer supports integrating RSS and WS-*. It is still necessary to convert the message payload from the RSS format to the XML event format that Dave’s application expects. The ISB will typically offer a configurable, reusable activity template for RSS to XML mapping.

Another common activity template will be selection-based routing. Dave’s application may emit a cancel car reservation ID=1234 message. If one town car service’s reservation codes begin with “LE-“ and another’s begin with “OL,” Dave’s application can send cancel events to a single ISB URI. The selector then processes the message and routes to the correct endpoint.

Combining activities for more complex message processing is useful and will be a common function of ISBs. As an example, Figure 6 shows the activities at the URL that Dave defines for receiving the cancel car reservation message:

1.      Receives the cancel message in XML using WS-*.

2.      Has an activity that extracts the reservation ID element and looks the prefix up in a table.

3.      Transforms the message to the expected format of the town car service, which is

·         a) HTML email for one provider

·         b) HTTP POST for the second provider.

Figure 6: ISB Message Processing (Click on the picture for a larger image)

Building message processing functions can be quite simple. Many, many of the common application scenarios are simple instantiations of patterns and templates. An ISB provider will offer a simple Web-based application development tool that allows the developers to select activity templates and set the configuration parameters through a Web form. In the routing case, the Web form would allow the developer to specify the message field for routing and values in the routing table. Over time, ISBs will offer more powerful tools like the message processing tools in BizTalk.

Message processing (routing, transformation, and so on) is powerful enough for many application scenarios. Simple sequencing and flow of control is required for others, however. Consider the task of booking a hotel in Dallas when Dave is stranded. A simple description of the process could be:

1.      Send a reservation request to hotel chain AAA

2.      Receive a response.

3.      If success then exit

4.      Send a reservation request to hotel chain BBB

5.      If success … …

Workflow activities extend message processing with activity templates for flow of control like while, if ... then …, and so forth. ISBs will incrementally add support for simple workflow to extend the basic message processing.

Workflow can appear to be a complex concept, and systematic enterprise workflow solutions are powerful and complex. The vast majority of workflows for ad hoc, opportunistic applications are extremely simple, however. The structure is not significantly more complex than simple PowerPoint diagrams. There is a small set of “clip art” for connections and shapes, and the developer sets properties on the shapes to express the behavior of the activity.

Most workflow processes tend to have the structure of a nested list. This enables simple tools for building the workflows. A simple XSD can provide the structure for XML documents defining a nested list workflow. A visual tool allows the developer to specify the activities and their implements or connection to external services. A broad community of developers is familiar with this model because Web UI frameworks often provide a similar concept for page flows and transitions (Struts, for example).

Systematic workflow solutions are often complex because they are mission-critical and support applications that thousands of people use. The process modeling and engine must be able to express the full functions of the process and handle complex error conditions, approvals, and so forth. In contrast, for most opportunistic, ad hoc solutions, a small group of people uses the workflow, and the team is constantly tinkering with it to improve it.

Service Level Objectives

Enterprises deploying applications on the ISB will want to define Service Level Agreements (SLAs) specifying response time, throughput, availability, and so on. The SLA will determine the cost that the ISB provider charges. The general problem of achieving SLAs for arbitrary applications is daunting. The ISB’s task is simpler, however, because it does not deploy arbitrary user code. Instantiating and configuring prebuilt templates for policy, publish/subscribe, workflow activities, for example, constrains the applications. This simplifies achieving SLAs, predictable cost, and integrity.

A Reference Architecture for Software and Services for Opportunistic Applications

Figure 7 provides an extremely high-level overview of how the strands in this paper come together. First, the Internet service bus is ubiquitous and connects all systems and servers. There will be many composite applications in which some elements are on the “ESB” and others are on the ISB. Multi-organization composite applications are one obvious example that would deploy elements onto an ISB in the cloud. Another possibility is single organization composite applications with a short duration. For example, a composite application that an enterprise uses to manage an internal conference. Reusing a preconfigured and installed “in the cloud” software platform may be more efficient than acquiring, installing, configuring, and supporting hardware and software to run the application “in house.”

Figure 7: An Ecosystem and Business Model (Click on the picture for a larger image)

If the enterprise reuses the ad hoc application for several conferences, a systematic solution may emerge from the opportunistic solution. The opportunistic solution provides a concrete set of use cases for the systematic solution. It can also provide metrics for determining which aspects of the application are frequently used.

Third parties will connect value added services to the ISB. The first type of services will be infrastructure services, such as a more powerful workflow engine or an XML Query enabled database. Developers can include these services in their solutions by connecting them to URIs in their application. These infrastructure services are an example of how third parties can join the ecosystem by providing advanced infrastructure as a service.

The second type of service will be reusable business services—for example, a prebuilt service for maintaining product information and catalogs. Another example might be conference room scheduling for conventions. This is an example of a third party joining the ecosystem by adding an application “building block” service. ISB composite application can use the building block by connecting a URI in the composite application to the building block service.

Finally, system integrators and solution vendors will offer configurable, extensible solutions that are templates. A third party may offer a configurable solution that supports many of the conference/convention management functions. A packaged application vendor can offer the benefit of enabling “try and buy.” Instead of shipping a CD that requires installation of the application and prerequisites, a potential customer can simply instantiate a version “in the cloud.”

Community is an important aspect of Web 2.0. It may in fact be the most important aspect. Infrastructure services, basic application building blocks, and solution templates will also emerge through a community associated with ISBs that offer and share code. The community also provides a forum for self-service support and establishing the reputations of “software as a service” providers.

Software + Services

Total “Software as a Service” is a myth. All meaningful SaaS solutions will eventually include some on-premise software – a hybrid. Some elements of an instantiated solution will reside in the bus (workflows, for example), some will reside in services connected to the bus (such as an XML content management system), and some will “install” on premise. Almost all scenarios that use an ISB and SaaS are actually a hybrid of on premise and off-premise software.

For another example, consider a data storage provider that Dave uses to store the itineraries in his application. Always using remote access to read/update the itinerary is fragile. The storage vendor will likely provide an on-premise and on-PC software package that optimizes data access through caching, replication, versioning, and so on.  A term for the hybrid model is software + services.

Conclusion

Several trends are coming together to radically transform the Web application model. Currently, the Web primary enables connecting people to documents and applications. The fundamental transformation is thinking of the Internet and Web being the platform on which applications execute. Professionals with basic programming skills write personal applications that make their use of the Web far more efficient. They will share these applications with less computer literate friends and colleagues. Communities will emerge that provide another approach to spreading a personal solution “meme” through the community.

Inevitably, elements of the personal applications will “move into the cloud.” A major source will be the broad use of “virtual” PCs that assemble themselves based on the user and nearby devices. Instead of using a notebook in a hotel room, the PC will assemble from the traveler’s mobile phone and the TV, Internet connection and keyboard in the room. It is possible to assemble a Virtual Machine (VM) that includes just the software needed to implement a specific scenario.

The VM also provides:

·         Application isolation

·         End-user administration by implementing a conceptual model similar to how the user manages personal computers

·         Natural exploitation of scale-out processors based on multi-core.

The benefits to enterprise of the convergence of these trends include:

·         Significant improvement in employee productivity and morale. Work is less tedious, more focused on business value tasks and potentially fun.

·         Increased agility and responsiveness because application development and modification can occur in hours instead of months.

A key enabling technology for these transformations will be an Internet service bus. SOA, Web services, and mashups enable rapid development of composite applications that integrate, customize and extend base application building blocks. Enabling these composites in the Web is the next major leap and a core aspect of Web 2.0. The critical element in achieving the promise is an Internet service bus. In addition to enabling flexible application development, an ISB enables an ecosystem of software providers. The capabilities of the ISB support the emerging populate of “programming literate” professionals entering the workforce, especially for bottom-up community development of long tail applications. The unifying theory of the computing universe is software and services, and the ISB is the keystone of this new application model.

Resources

·         Biztalk Adapter http://msdn2.microsoft.com/EN-US/library/aa744368.aspx

·         Biztalk Labs http://labs.biztalk.net

·         Enterprise Application Integration (EAI) http://en.wikipedia.org/wiki/Enterprise_application_integration

·         Enterprise Service Bus http://en.wikipedia.org/wiki/Enterprise_service_bus

·         Mashup http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)

·         Model View Controller http://en.wikipedia.org/wiki/Model_view_controller

·         OASIS Web Services Reliable Messaging (WSRM) TC www.oasis-open.org/committees/wsrm/

·         SAP RFC http://en.wikipedia.org/wiki/ABAP

·         Straight Through Processing http://en.wikipedia.org/wiki/Straight_Through_Processing

·         Struts http://struts.apache.org/

·         Use Cases http://en.wikipedia.org/wiki/Use_cases

·         WS-Eventing http://www.w3.org/Submission/WS-Eventing/

·         WS-Security Security Token Service http://sts.labs.live.com/

·         Zorro’s ISB Blog http://zorroisb.spaces.live.com

About the Authors

Dr. Donald Ferguson is a Microsoft Technical Fellow in Platforms and Strategy in the Office of the CTO. Don focuses on both the evolutionary and revolutionary role of information technology in business. Prior to joining Microsoft, Don was an IBM Fellow and Chief Architect for IBM’s Software Group (SWG) and chaired the SWG Architecture Board, which focused on product integration, crossproduct initiatives and emerging technology, including Web services, patterns, Web 2.0 and business-driven development. Don’s primary hobby is Kenpo Karate. He earned his black belt in December 2005.

Dennis Pilarinos is a senior technical lead in the Connected Systems Division at Microsoft. You can learn more about his work from his blog at www.dennispi.com.

John Shewchuk drives the Technology Strategy team for Microsoft’s Connected Systems Division (CSD). In CSD, John has worked to develop Microsoft’s application platform, including work on application messaging technologies like the Windows Communication Foundation, Web services interoperability specifications such as WS-Security, and identity and access technologies such as InfoCard. John co-founded the Indigo team and has been a key driver in cross-industry interoperability. With others on the Indigo team, John led development of the Web services architecture and specifications and managed technical negotiations with a broad range of industry partners.

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal Web site.