by Atanu Banerjee
Summary: The 2007 Microsoft Office system provides a set of servers, clients, and tools to make it easier for enterprises and software vendors to build and deploy composite applications in the enterprise. These solutions, called Office Business Applications (OBAs), are quick to build and deploy; empower end users through extensive personalization capabilities; are easy to change when business needs require; and are built using familiar Microsoft Office tools and applications. This paper shows how to architect composite applications, and how the 2007 Microsoft Office system provides a good platform—familiar to end users—for building such applications.
What Are Composite Applications?
The 2007 Microsoft Office System as a Platform for Building Composite Applications
How Office Business Applications Are Composite Applications
Building an Office Business Application
Building Departmental SharePoint Sites to Host Local Documents and Processes
About the Author
Globalization, specialization, and outsourcing require people to work in more collaborative ways than before. This trend requires a matching change in the tools that information workers use to gain insight, collaborate, make decisions, and take action. Today, most business applications are effective at automating transactions, but do not enable rich collaboration across functional boundaries. This usually leads information workers to use personal productivity tools to perform the complex interactions required to conduct business. However, this in turn leads to a loss in productivity, as users are forced to cross from one set of tools to another, often manually moving the data through means such as cut-and-paste. These gaps between different business applications and productivity tools need to be bridged for information workers in a way that is seamless, synchronized, and secure.
There really has not yet been an effective way to enable composition of business applications in a way that is contextual, collaborative, easy to use, role-based, and configurable to pull in other platform technologies that are needed for building these kinds of composite applications. Ease of use is important, as the platform, tools, and architecture for composition should not introduce unreasonable technical complexity that requires radical retraining of people.
A composite application is a collection of software assets that have been assembled to provide a business capability. These assets are artifacts that can be deployed independently, enable composition, and leverage specific platform capabilities.
In the past, an enterprise's software assets usually consisted of independent business applications that were monolithic and poorly integrated with each other. However, to get the business benefits of composition, an enterprise must treat its software assets in a more granular manner, and different tiers of architecture will require such varying assets as presentation, application, and data assets. For example, a Web service might be an application asset, an online analytical processing (OLAP) cube might be a data asset, and a particular data-entry screen might be a presentation asset.
An inventory of software assets by itself does not enable composite applications. This requires a platform with capabilities for composition—that is, a platform that provides the ability to deploy assets both separately and in combination with each other. In other words, these assets must be components, and the platform must provide containers (Figure 1).
Figure 1. High-level representation of a composite application
Containers provided by the platform need to be of different types, which map to the different tiers in the architecture. Enterprise architectures are usually decomposed into three tiers: presentation, application (or business logic), and data. So the platform needs to provide containers for these. However, the three-tier architecture assumes structured business processes and data, where all requirements are made known during the process of designing and building the system. By their very nature, composite applications presume that composition of solutions can occur after assets have been built and deployed—and so need to explicitly account for people-to-people interactions among information workers that are essential to complete any business process. Usually these interactions are not captured by structured processes or traditional business applications; therefore, it is critical to add a fourth tier—the productivity tier—to account for these human interactions. This is shown in Figure 2.
Figure 2. The four tiers of a composite application
Traditional discussions about the architecture of business applications tend to focus on the application tier as being the connection between people and data. Typically, however, the application tier contains structured business logic, and this holds for discussions about Service-Oriented Architectures (SOAs), Enterprise Service Buses (ESBs), Service Component Architectures (SCAs), and most other architectural perspectives in the industry today, including first-generation discussions about composite applications. However, building a composite application requires the architect not only to consider the productivity tier a critical element of the stack, but also to recognize that it contains the most business value.
To expand on the comparison between composite applications and SOA: Both of them target flexibility and modularization. However, SOA provides flexibility at just one tier: the structured business logic in the middle tier. Composite applications target flexibility at all four tiers. That said, a composite application is a great way to extract information from an SOA, and having line-of-business (LOB) applications exposed as services makes it easier to build support for cross-functional processes into a composite application.
Therefore, to design a composite application, a solutions architect must:
After deployment, users will have the opportunity to personalize both assets and connections, and the composition stack should enable this through loose coupling and extensibility mechanisms.
The 2007 Microsoft Office system is such a platform for building composite applications—which are called Office Business Applications (OBAs).
Figure 3. Capabilities provided by the 2007 Microsoft Office system
Let us now look at each of the tiers in Figure 2, and examine the types of containers and component types that the platform provides.
Table 1. High-level 2007 Microsoft Office system capabilities
|Web Site and Security Framework||A common framework for creating different kinds of sites such as team collaboration sites, intranet portals, Internet Web sites.|
|Open XML File Formats||This enables rich server-side processing of documents. With prior versions of Microsoft Office, parsing the document (for example, a spreadsheet), using the document object model required an in-memory, running instance of the application used to create the document (for example, Excel).|
|Extensible UI||Server-side portal that can be personalized by users, from building blocks that can be extended by solutions providers. Client applications that can be extended with Visual Studio Tools for Office.|
|Business Data Catalog||A metadata repository to define business entities stored in back-end data stores, to model relationships between entities, and to define actions permissible on entities.|
|Enterprise Search||To extract data from various enterprise sources through searching.|
|Workflow||Integrated with Workflow Foundation to host workflows that represent people-to-people interactions and that link UI elements.|
|Enterprise Content Management||Manage diverse content, with one topology for Web, document, and records management. Support for document life-cycle management.|
|Business Intelligence||Server-based Excel spreadsheets, plus BI components (dashboards, reports, Web Parts) built into the portal and connected to SQL Server Analysis Services.|
|Communication and Collaboration||Support for unified communications integrated into the platform.|
The first type of container in the presentation tier is the Microsoft Office client application (Excel, Word, InfoPath). These applications are customizable containers that can now more easily extract information and functionality from LOB applications through custom task panes, custom ribbons, and actions that present users with data and actions in the context of their current activity. The component type that can be hosted within these containers is the Open XML document. This is the new XML representation for Microsoft Office documents—which enables rich server-side processing of information stored within. This is shown in Figure 4.
Figure 4. Office client applications are customizable containers for Open XML content.
The second type of container is a Web portal, as enabled by Windows SharePoint Services (WSS), and Microsoft Office SharePoint Server (MOSS). WSS v3.0 provides the following hierarchy of containers, as shown in Figure 5:
Figure 5. Containers provided by Windows SharePoint Services (Click on the picture for a larger image)
While WSS provides support for building collections of sites for team collaboration, MOSS enables portal functionality on top of WSS, with additional capabilities. For example, MOSS comes with capabilities for enhanced searching, connectivity to business data stores, and Business Intelligence. However, a MOSS portal is a WSS site collection, and so is a hierarchy of WSS sites. MOSS also comes with a Web Part gallery that contains a rich set of Web Parts out-of-the-box, for example to extract Microsoft Office Excel spreadsheets and charts. Solution providers can also provide their own custom Web Parts for application-specific or domain-specific functionality—which can then be uploaded into WSS. Information workers can personalize pages by adding Web Parts from the gallery, removing Web Parts from a page, or rearranging the layout.
The 2007 Microsoft Office system provides a number of different ways to share information and collaborate on using it. For example, server-side storage provides containers for in-process documents, and other kinds of heterogeneous content with version-control. This allows for collaboration in unexpected or unplanned situations. It is hard to capture all the complex people interactions in a business process management (BPM) system, as work usually never happens as planned. In traditional three-tier architectures, there is little support for this beyond storage of in-transit documents on personal hard drives or e-mail servers, and it can sometimes be hard to decide which document is the correct version. However, the 2007 Microsoft Office system can set up versioned document libraries to store documents at the intermediate stages of a business process, which improves manageability, and also improves the likelihood of graceful recovery from unplanned events. WSS provides the following types of storage:
Figure 6. SharePoint Workflow Architecture (Click on the picture for a larger image)
Information workers can add document libraries themselves and specify particular document templates to be used by all documents in those libraries. For example, a business analyst might use the InfoPath WYSIWYG design tool to create a form, and then use that form as a template to create a forms library. Whenever users create a new document within that library, this template will be used to create an empty form. The 2007 Microsoft Office system also has built-in, server-side support for Windows Workflow Foundation (WF). The WF run-time engine is hosted within MOSS and acts a container for business logic that can be attached to work items and documents in the form of workflows. These workflows may be associated with lists, document libraries, or with particular content types. They are started and completed by user actions, and are managed using WSS task lists. For example, workflow activities create and update task items as required, and users can track workflow progress through history tables. 2007 Microsoft Office client applications are also workflow aware. They can be used for workflow initiation, configuration, completion, and also ad-hoc customization (forwarding/delegation).
Workflows can be associated with lists, document libraries, or particular content types. These associations to WF templates are tracked in a farm-wide workflow association table. WF templates are defined by XML metadata and can include both workflow assemblies and forms. For example, when users create a document library, they can choose to associate that library with a particular workflow and specify the conditions under which the workflow gets triggered (for example, a document in a given library might have been modified or created). This workflow could support a particular business process or support document life-cycle management.
Integration of the 2007 Microsoft Office system with WF provides a variety of benefits (Figure 7). Simple business processes can be automated in a way that is seamlessly integrated into the SharePoint UI. Users are empowered through self-service capabilities, such as support for a broad range of user-controlled document routing and tracking scenarios, in a way that reduces the involvement of IT staff in putting together simple applications. WF also provides vertical solutions providers with an extensibility point to deploy their own business rules and logic into the containers provided by the 2007 Microsoft Office system.
Figure 7. Workflow hosting with WSS (Click on the picture for a larger image)
Finally, the productivity tier must also provide a lightweight way to create and publish information and reports. This is supported by the 2007 Microsoft Office system, which integrates into SQL Server Reporting Services and provides the following components:
A dashboard might be provided to users as a reporting template built around a specific business function, such as sales, marketing, or inventory management.
Typically, structured business logic lives within the application tier. This might be an LOB application such as an Enterprise Resource Planning (ERP) system, or an orchestration across multiple systems such as a BPM system. The application tier will typically include both transactional systems and decision-support systems. There are multiple ways for OBAs to enable composition in the application tier, as well as to consume composite services exposed by other platform technologies (Microsoft and non-Microsoft).
The first level of composition in the application tier is through packaged activity libraries created using Workflow Foundation, and deployed into the 2007 Microsoft Office system. Previously, we discussed how workflows can be attached to lists, document libraries, and particular content types. Figure 7 shows how the WF run-time provides a container for application-specific activities that are packaged and deployed as activity libraries, and on top of which workflows are assembled.
The second level of composition in the application tier provided by the 2007 Microsoft Office system is through Excel Services. This is a server-side Excel calculation engine that is built into SharePoint Server. It provides browser access to live, interactive spreadsheets that are deployed on the server, and also Web service access to server-side Office Excel calculations. With Excel Services, existing Excel power users can now provide server-side application logic in a way that is familiar to them. This means that MOSS is now a container for application logic, as shown in Figure 8.
Figure 8. Excel Services in the 2007 Microsoft Office system
A third way for OBAs to enable composition in the application tier is to consume composite services exposed by other platform technologies. The 2007 Microsoft Office system can be plugged seamlessly into a services-oriented architecture. If the enterprise has a services backbone already under development, these interfaces can be consumed from the 2007 Microsoft Office system. This can be done in a couple of ways. The first is by invoking Web service interfaces in activities that have been built into workflows deployed into the productivity tier. The second is through the Business Data Catalog (BDC), which is described in the next section.
The 2007 Microsoft Office system also comes with a Business Data Catalog (BDC) that runs within the server as a shared service. It can read data from multiple types of data sources—databases, analysis services cubes, and Web services—and then display this data in the portal through SharePoint tables and lists. This acts as a metadata repository for descriptions of business-data entities and their attributes, and for mapping these entities back to data stores within the enterprise, as shown in Figure 9.
Figure 9. Business Data Catalog (BDC)
While the BDC cannot be used to create an entity that maps across multiple data stores, it is possible to define relationships that link entities—such as parent-child relationships. So, the BDC can be used to create lightweight linkages between data entities across the enterprise—almost like an enterprise thesaurus. BDC-defined entities can then be plugged back into the 2007 Microsoft Office system, for example in SharePoint lists. This allows users to compose pages with linkages to back-end data and to traverse data tables by following relationships between entities.
Although the BDC enables data composition, it provides read-only access to data. However, users can use the BDC to model actions that can be taken on a data entity, where an action is defined by a name, a URL, and a set of attributes from the entity definition to be passed back to this URL. This can then be used from within a dropdown menu on a SharePoint list. The URL can correspond either to a Web service or to a server-side document such as an InfoPath form, with code-behind to pre-populate the form from the context that gets passed in from the BDC. Information workers can then use the portal to create lightweight applications in SharePoint with tables and lists that extract BDC data and actions.
Figure 10 shows how some of the capabilities of the 2007 Microsoft Office system map to the tiers in Figure 2. Table 2 provides a list of asset types that are candidates for composition.
Figure 10. Capabilities of the 2007 Microsoft Office system application platform, mapped to tiers (Click on the picture for a larger image)
Table 2. List of application assets for composition
There are two steps to building a standard business process as an OBA.
One way to deploy an OBA in the enterprise might be as follows:
SharePoint sites must be set up at the departmental level to enable team collaboration, as shown in Figure 11. These sites will have document libraries to store in-process documents. Information workers on the team will have their own personalized pages, customized from the templates available on the team site.
Figure 11. Provision OBAs in departmental sites for team collaboration, coordinate activities with business-process models, and connect to LOB systems through a services backbone.
Note that Figure 11 is a logical view of the architecture, as all these departmental sites would not typically be running on separate servers. Instead, multiple sites could be running on a single server in line with Figure 5, and the physical architecture (that is, the deployment landscape for SharePoint servers) would be chosen based on other factors like load, availability, and geographic dispersion of teams.
In-process documents are stored in document libraries and are associated with workflows that get invoked whenever a document is created or edited. Such a workflow might run validation rules on documents; apply approval policies and actions to the data; cleanse, validate, or filter the data contained within; or update back-end systems.
In addition to business process workflows, in-process documents undergo a life cycle of their own, from authoring and collaboration through management and publication, to archiving or destruction. Whenever a document reaches one of these stages, the appropriate workflow can be set to be triggered, such as for managing the archival process.
As shown in Figure 11, business-process models coordinate activities both within a team and across departments. Within a department, business processes can be modeled using WF activities that are deployed into the SharePoint server that is supporting that department. Coordination of activities across departments can be accomplished using collaboration processes that manage the life cycle of individual business entities (orders), and also the life cycle of business processes (procure-to-pay).
The interdepartmental business processes could either be located centrally in IT data centers, or closer to the information workers within the departmental servers. For example, long-running workflows running centrally might be running on Microsoft BizTalk Server, whereas departmental processes would be running in WF workflows within the SharePoint server.
Service orientation is one of the ways to expose current business applications into an OBA.
In that sense, SOA promotes modularization which is a basic requirement for composition, and SOA are complementary solutions. new cross-functional business applications boundaries of current applications.
SOA is not the only way to connect LOBs to OBAs. A services backbone can also be exposed using other integration technologies, such as custom adapters.
The BDC (Figure 9) can be used to connect back-end data stores to the 2007 Microsoft Office system by displaying data in SharePoint lists and Web Parts. This makes it possible to build composite applications for cross-functional processes into the SharePoint portal, using a combination of BDC, SharePoint lists, and Workflow. For example, the BDC can be used to define entities that have a parent-child relationship (such as order header and order details), and SharePoint lists could display them. It would be possible to drill down from the list displaying header information, to the corresponding details information, by following the parent-child relationships. Furthermore, actions can be modeled in BDC metadata, which means that these are displayed as menu items on the SharePoint list and selecting a dropdown from this menu will mean that context from the currently selected row will be passed into the URL defined for the action.
Often the scope of an OBA is not contained within an organization. For example, an OBA might support a business process that needs to consume a service that is offered by a hosting provider (Software as a Service—SaaS—scenario). Alternatively, the OBA might need to support a business process that offers a service to another organization. This is especially common in supply chain management scenarios, where trading partners are involved. Here, there needs to be a way to transfer documents from one information worker to a counterpart in the trading-partner organization. This needs to be secure, reliable, asynchronous, and transparent.
One way of putting together an end-to-end architecture for this is shown in Figure 12. Message brokers have been set up at the edge of the organization to send and receive messages and documents from trading partners. Messages from different trading partners can potentially be received in multiple message formats and delivered over multiple channels, such as Web services, EDI, e-mail, RosettaNet, and so on. Furthermore, messages can be exchanged in a variety of different patterns: one-way, asynchronous two-way, or synchronous two-way messaging. These message brokers must handle each combination of these message interchange patterns and message formats.
Figure 12. Connecting the OBA to systems at "the edge"
After the message is received by the message broker, it is processed into the single canonical format that is required for downstream services, and the transformed message is persisted to a message queue to decouple public processes from private ones. Next, the message is retrieved from the queue by a routing service that examines the message and routes it to the intended recipient. But before the document reaches its intended recipient, it might have to be preprocessed by enterprise application services such as LOB applications, or BPM orchestrations. Business rules might be applied to messages, to ensure validity and to enforce corporate policies. The result of all this processing is a document that can be processed by a human with enough information to make a quick decision. For example, a purchase-order request from a customer might be fed into an order-promising service, and the response from this service might be used to generate an XML document that corresponds to an InfoPath form with a candidate PO Confirmation. Next, this generated form might be placed into a SharePoint forms library for an information worker in the sales department to approve.
After the information worker has reviewed the proposed confirmation and made changes if necessary, the worker submits the form. This kicks off the workflow for the return trip, which updates LOB systems and then posts the information from the form as an XML document into a queue for outbound messages as a response to the original request. The message broker then converts back into the format used by the trading partner.
There are multiple ways to implement the message brokers at the edge, such as BizTalk Server. This would provide a scalable and manageable solution that would also come with standards-based accelerators and adapters, such as the RosettaNet accelerator for trading partner collaboration. The queues that decouple internal and external processes could be implemented using Microsoft SQL Service Broker 2005.
To provide technical resources and guidance on building OBAs with meaningful business value, a reference implementation for an OBA is available online here. This reference application pack for supply-chain management covers scenarios for collaboration between the different levels of a multi-tier supply chain.
The 2007 Microsoft Office system provides a powerful set of capabilities to build composite applications, which are called Office Business Applications (OBAs). This enables cross-functional solutions offering a composite user interface that exposes business functions and capabilities across a heterogeneous set of back-end IT assets. These solutions also provide collaborative business capabilities that span the gap between traditional business applications and personal productivity tools.
Atanu Banerjee is an architect on the Architecture Strategy Team at Microsoft. He has 10 years' experience in the software industry, having worked earlier on solutions for supply chain management and advanced process control. He joined Microsoft from i2 Technologies, where he served as chief architect for its supply and demand management product line. Before that, he worked at Aspen Technologies' advanced control systems group. He received a Ph.D. from Georgia Tech in 1996, and holds a bachelor's degree from IIT Delhi, India.
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 website.