SharePoint is the name Microsoft has given to its collaboration platform. The name actually refers to a number of applications, though today most people use it to refer to the two prominent server applications: SharePoint Foundation 2010 and SharePoint Server 2010. But you'll also find it used for desktop applications such as SharePoint Designer and SharePoint Workspace (formerly Groove).
It is SharePoint Foundation that serves as the base for the platform, and it is actually a component of the Windows Server operating system. SharePoint Foundation provides core functionality, such as the ability to quickly provision collaboration sites, and a sophisticated document repository featuring collaboration necessities such as versioning, checkin/checkout, and a metadata system.
Whereas SharePoint Foundation provides collaborative sites to facilitate teams of users, SharePoint Server supplies more features to the enterprise. With SharePoint Server, the focus is on distributing information, social networking, application integration, search, business intelligence, and managing an enterprise's content. Enterprises get a platform designed for their intranet, extranet, and Internet environments.
In this chapter, we take a moment to reflect on SharePoint's history and then give you an overview of the new features. The idea is to get you up to speed on the new areas and terminology, not to replace the thorough introduction you can get from other resources. We'll focus on the big changes in the products' functionality and refer you to solutions later in the book that leverage them, along with lots of links for you to do more reading on your own. We'll exclude the Visual Studio 2010 Tools for SharePoint from this chapter as they are so pivotal in many of the solutions in this book that we gave them their own chapter (Chapter 3).
To understand the products as they exist today, it is important to review their history. Each product has a different heritage and only recently have the products been so seamlessly aligned and integrated. Before the term portal grew in popularity, developers sought to use Microsoft Outlook as a foundation to provide access to different systems and data, and most of the attention was focused on creating views that aggregated information from different applications into a single display. These views were made up of page components, and were organized much like the Outlook Today view. Microsoft provided SDK material and soon developers were building components to be loaded into the Outlook interface—a technique known as building digital dashboards. This allowed developers to build reusable components that could be arranged on the dashboard to provide a view of data across the enterprise. These components were the beginning of the web parts we know today. Developers used them to query databases and to display charts, data, and other key information.
Early in the Web era, Microsoft released a FrontPage server application that ran on top of Internet Information Services (IIS) and relied on the FrontPage HTML-design tool for administration and customization. One of the compelling features of FrontPage server was that it shipped with web site templates. Thus an organization could quickly create new sites that automatically had some application functionality, such as calendaring and task lists. These web sites would be ready for use after simply running a wizard. This eliminated the labor-intensive processes of web designers and application developers, dramatically decreasing the time it took to deploy a web site. The result was especially powerful for a straightforward web site that was going to be used by a small number of users for a short period of time.
For many organizations, such a site is not worth the effort and cost of a full-blown web-development endeavor. These FrontPage sites eventually evolved into a product named SharePoint Team Services, or STS, which was still based on Active Server Page (ASP) technology. With the .NET evolution, Windows SharePoint Services (WSS) arrived, and the version 2 features were released as a component of the server operating system. This led to a proliferation of organizations using this application's ability to create collaboration sites based on templates for teams of users. Windows SharePoint Services (version 3) was released as part of the 2007 wave of Office products and was built on top of ASP.NET 2.0. Though it still provided the foundation layer for the SharePoint stack, this release gave developers increased capabilities for customizing the solution so it could match a particular customer business process. Developers gained access to master pages, web parts, authentication providers, list and library event handlers, custom workflows using Windows Workflow Foundation, and much more.
Microsoft SharePoint Portal Server (SPS) 2001 was the first release of enterprise collaboration services that were to complement the agile team sites. This portal product was also based on ASP technology and focused on creating workspaces. With a workspace, the product provided a document repository as well as a web site where an organization could set up a site structure or taxonomy for organizing its information. The focus here was that documents should be categorized and that users would browse the category terms to locate their documents of interest. This category-based interface was a popular one for Web-based search engines at the time, such as Yahoo!. Included in this release was a search service as well as a Web-based component platform supporting web parts. A major difference between this version and the ones that would follow is that SharePoint 2001 did not rely on SQL Server for storage. Instead the repository was more like Exchange 2000 and was called the Web Storage System.
Like Windows SharePoint Services, SharePoint Portal Server received a major facelift with the move to the .NET platform. Microsoft SharePoint Portal Server 2003 gave organizations the ability to create enterprise portals. These portal sites relied on the WSS foundation for their document-repository needs and added new features for the enterprise, including a search that could index not only content stored within its repositories but also other content stores, such as file shares, web sites, and Microsoft Exchange public folders. SharePoint 2003 folded the workers of the system into the content mix as well. The services of My Sites and user profiles allowed the system to capture information about an organization's users and provided an application that let users view each other's profiles from within the system, access documents they shared, and locate users by attributes such as proficiency in a particular language. In fact, a user could be returned as a search result item along with documents and sites. SharePoint Portal Server 2003 also extended the web-part interface provided by WSS by incorporating a personalization service that allowed for a page to hide or show specific web parts to specific audiences of users. SharePoint's single-sign-on service provided an application-development framework for translating security contexts between the logged-in user and that user's credentials to an external application whose data was used by a web part. Ultimately, SharePoint Portal Server 2003 completed the touch points a user would have with his organization's information. Whereas WSS answered the needs for teams of users, SPS provided the services to meet the needs of the overall organization, divisions, and even the individual.
Microsoft Office SharePoint Server 2007 (MOSS) extended the capabilities of SPS 2003 by adding enterprise features to the platform. Built on the success of the 2003 release, this product expanded into new areas. The definition of content management was expanded to include web content and records management. In fact, the addition of web content management meant that MOSS swallowed whole the product capability of Microsoft Content Management Server. This was a benefit to customers in that there was no longer a need to support two separate products and platforms for content management. It also eliminated the need to glue the two products together for a complete offering. Moreover, MOSS 2007 integrated electronic forms into its definition of content, solving a key problem for InfoPath in the process. InfoPath, introduced in Office 2003, was a great product for quickly building forms without code but was limited in that the user filling out the form also had to have the InfoPath client application. MOSS solved this problem by automatically generating a web-based equivalent of the form using its InfoPath Forms Services feature.
MOSS 2007 also expanded to play a pivotal role in business intelligence by allowing users to visualize their data in dashboards. A major part of this functionality was Excel Services which, much like Forms Services, allowed users to publish their spreadsheets to the server. Once the spreadsheets were published, the rich charting and visualization capability of Excel could be utilized through web-based web parts that could still maintain their connection to data sources. Furthermore, MOSS 2007 became an integration platform with the inclusion of the Business Data Catalog (BDC). This feature enabled the surfacing of line-of-business data from external systems, such as Oracle databases, SAP, or other applications, into a SharePoint environment with the developer only having to describe the external system through XML. The surfaced data could find its way into dashboards via web parts, search, and even metadata columns—all without the developer having to write a line of code. For more information on SharePoint's history, read the reflections of Microsoft Corporate Vice President for SharePoint Server, Jeff Teper's blog post: http://blogs.msdn.com/sharepoint/archive/2009/10/05/sharepoint-history.aspx.
Microsoft's tag line for the SharePoint 2010 release is "The Business Collaboration Platform for the Enterprise and the Web." The key word for us is Platform. Think of all of the other words that could have been chosen: application, product, server, suite, and so forth. However, none of these other terms adequately describes what enterprises are doing with the software or Microsoft's vision regarding the direction of the product. The software has evolved beyond a set of out-of-the-box capabilities to a set of application-level services that enterprises and their developers mold into business solutions. SharePoint is no longer about just setting up an intranet and publishing documents. The 2010 release of these technologies is about providing a rich set of capabilities that can be combined and extended to make a business more effective. Figure 2-1 is Microsoft's depiction of the SharePoint 2010 feature areas. We will spend some time in each, providing an overview and discussing some of the extension points for developers.
In SharePoint, the "site" provides a context for the users interacting with the information within it. This context could be a particular team, department, event, or an instance of a business process. The site provides a wrapper that relates all of the content (lists, document libraries, and web parts) to a specific purpose. The ability to provision these sites quickly has always been one of the strengths of the platform. These sites can be self-provisioned with no need for developers to hold many months of requirements-gathering sessions before building a custom solution. In fact, this is the focus of Chapter 11, which not only looks at site templating but also examines how to inject workflow into the site provisioning process so you can have self-service along with process and auditing.
In the 2010 release, SharePoint sites provide the user with an enhanced web experience. The most obvious improvement is the ribbon interface, which first made its appearance in the Office client applications in Office 2007. The ribbon makes the organization of commands uniform between the web and desktop interfaces, a great help to users. Of course, as developers, you've been able to extend the ribbon in the desktop applications (described in more detail in Chapter 4), and that extension point will continue in with the SharePoint web experience. Figure 2-2 shows the SharePoint ribbon extension you will build in Chapter 3. The same technique will also be used in the solution you'll build in Chapter 6.
Another significant improvement in the 2010 release is the AJAX behavior of the pages. AJAX stands for asynchronous JavaScript and XML. For end users, this means the web interface behaves more like a traditional Windows Forms application that updates only appropriate controls. Not only is the out-of-the-box experience enhanced, your customizations can leverage it as well. Chapter 9 shows you how to build an AJAX-style web part, and Chapter 13 layers data over a web-based Visio document using the new JavaScript-based SharePoint API. There are also new dialog and notification techniques that reduce page refreshes. These are used in Chapter 5.
With each release of SharePoint, the Office client applications become more integrated into the sites its files participate in. The new backstage interface that appears when users click the File menu eases adoption by removing some of the mystery of how to get a document into SharePoint. As shown in Figure 2-3, from this interface a user can easily perform actions such as saving the file to a SharePoint site, setting metadata, starting a workflow, and more. We will even extend this interface in Chapter 7.
In addition to streamlining the interaction between the server and desktop applications, SharePoint 2010 also enables scenarios that were problematic in the past. Users with low-bandwidth connections often found it difficult to interact with their SharePoint sites. Now in the 2010 release, these sites can make it to the desktop much more efficiently than before. For example, the user can start with the web-based versions of Word, Excel, PowerPoint, or OneNote installed in the SharePoint environment to preview a file before deciding to download it. As the remote user browses the SharePoint sites, a combination of Windows 7 and Windows Server 2008 R2 together provide a branch cache solution that accelerates the experience. The acceleration is due to the remote user's ability to potentially retrieve the HTML, JavaScript, images, and other files from a peer instead of across the wide area network. If the user changes a downloaded file and saves it back to the server, the save is actually asynchronous to a local cache where a delta is created and sent to the server. The Office clients are even more capable of taking content offline. Microsoft Outlook and SharePoint Workspace (formerly Microsoft Groove) play a large part in offline scenarios. In Chapter 10 you will see how SharePoint 2010 enables a user to take line-of-business data offline. Use the following links for more details on these improvements:
Introduction to the Office 2010 Backstage View for Developers
http://msdn.microsoft.com/en-us/library/ee691833(office.14).aspxSharePoint 2010 Sites (Video on New Features)
http://sharepoint2010.microsoft.com/product/capabilities/sites/pages/top-features.aspxWindows Server 2008 R2 and BranchCache
http://www.microsoft.com/windowsserver2008/en/us/branch-cache.aspxSee What's New in Microsoft SharePoint Workspace 2010
http://www.microsoft.com/video/en/us/details/755f7866-f95c-4d8a-a904-d80154413444
Ever since SharePoint Portal Server 2003 included the "my site" functionality, the SharePoint platform has been more than just a web-based file share. The product focuses on engaging people, and this continues with My Sites, which are still a feature of SharePoint Server 2010. The user profile store still exists, and surfaces itself as a sort of electronic business card, and there is still a personal dashboard where users can organize web parts for quick access to information they check regularly. The main difference in the 2010 release is how My Site becomes the center hub for a user to get updates on activities and events within their enterprise, along with the increased number of ways users can participate socially. There are now many different ways users can contribute, participate, and share beyond the documents themselves. For example, users can tag any piece of content, whether list item, document, or even the web page. These tags become social since a user is able to see what colleagues are tagging as a roll-up on their My Site. Users can also rate content and share bookmarks. My Sites now even have a note board, which Facebook users will relate to writing on someone's wall. Of course, there are also enhanced blogs and wikis. In fact, every page in a SharePoint 2010 site has a wiki-like editing experience. And the new team blog enables multiple people to publish blog posts. The bottom line is that social networking tools have definitely become popular in the public domain, and SharePoint 2010 brings these features to the enterprise. They are all ways to get your users involved, integrated, and participating in the environment. User tags, ratings, and profile data also becomes a wealth of information you can leverage in your own solutions. In Chapter 13, we integrate user profile data into a Visio diagram. And in Chapter 7, we integrate a people search into a task pane of Microsoft Word. Use the following link for a video on SharePoint 2010 Communities features http://sharepoint2010.microsoft.com/product/capabilities/communities/pages/top-features.aspx.
In SharePoint 2010, the content repository gets too many enhancements to list. Nevertheless, we will touch on some of the really big items you will surely want to be aware of when reading through the solutions in this book. The most important improvement is one you might rarely actually see—scale. SharePoint 2010's content repositories have been tested well beyond the limits that were practical in the previous release. Almost everyone working with SharePoint 2007 was aware of the recommended threshold of 2,000 items in a list or folder of a document library. This was not a hard ceiling, but if a solution pushed much past this limit, the user experience would begin to degrade. It seems difficult to imagine returning more than 2,000 items in a single view of a page, but we have seen lots of customers try. Such an operation can be a problem for a farm because it can be very taxing on the SQL Server and SharePoint web front end to generate this view of data for just one user. So taxing, in fact, that other users of the environment may suffer long page loads or dropped requests even with trivial actions. In SharePoint 2010, it is possible to have lists where the number of items is measured in millions. This scale is achieved by first realizing that users won't browse through millions of items like they browse a file system. Retrieving items from a large list will be done by specifying filters against metadata properties (another improvement described a bit later). Of course, it's still possible for a user to specify a filter that returns more items than you want to allocate resources for, but in SharePoint 2010, there is a farm configuration setting where you can specify the desired threshold limit. This will vary in different environments based on the hardware and server configuration, but it gives the administrators confidence that SharePoint will defend itself from queries that could drag down performance. If a query exceeds the threshold, the user will be informed and asked to indicate additional filters to the query to bring it under the limit.
Another major change in the 2010 release is that metadata is everywhere—and we're not talking about just simple columns of data on a file. In SharePoint 2010, you can create hierarchical enterprise metadata term stores for use in your enterprise. In addition to this top-down approach, SharePoint also provides a bottom-up solution where users can submit their own terms through tagging, creating a folksonomy of metadata. This metadata can also be used for navigation instead of the typical folder navigation approach. Figure 2-4 shows the administrative interface for the term store management tool.
In previous versions of SharePoint, metadata and other many other features were focused on a particular item. You could set metadata for an item, send an item through a workflow, version an item, and so on. But customers often asked how to operate on a set of items as a single unit. SharePoint 2010 answers this question with the new feature called document sets. A document set can be treated as a single item, with its contained files taking on some of the behavior of the set. You can cascade metadata across the items in a set, have the set go through a workflow, or version the entire set. Of course, not every item in the set has to be the same type. Figure 2-5 shows you the welcome page of a document set which contains several different types of files.
Other improvements in the content repository include additional support for digital asset management and enhanced records management. For records management, the enhancements give you additional routing capability. You can also choose to manage the records separately or manage retention in-place where the content was created. Also, there is a new server-side Word Automation Service that allows you to do conversions of Microsoft Word documents in ways similar to the options in Word's save-as dialog. This enables you to automate, say, converting files to PDF, XPS, or older versions of Microsoft Word. We will kick off this service from code as part of the solution in Chapter 7.
The workflow story with SharePoint 2010 is also more complete. In previous versions, there was a distinction between enterprise class workflows and ad-hoc, one-off solutions. Enterprise workflows that were going to be used in different lists, sites, or site collections had to be created using Visual Studio. However, a savvy end user could use SharePoint Designer to create a workflow for a specific list. What was missing, and what SharePoint 2010 provides, is the ability to promote the end-user workflow to an enterprise one. In fact, you can start with a Visio diagram, prototype the solution using SharePoint Designer, and then import that into Visual Studio for final development. Figure 2-6 shows a workflow at the beginning of this process in Visio. These techniques are used in the solution in Chapter 11.
Use the following link for a video about SharePoint 2010 Content features http://sharepoint2010.microsoft.com/product/capabilities/content/pages/top-features.aspx.
Ever since the SPS 2001 release, SharePoint has included Microsoft's enterprise search solution, which is not concerned only about searching content within SharePoint's databases, but also provides a single interface to search across an enterprise's content repositories. This means that file shares, web sites, and even data that is normally locked into line-of-business applications are all capable of being indexed and surfaced through a SharePoint interface. With the 2010 release, SharePoint's search interface becomes much more interactive. Users can narrow a search result through refiners, see related queries, and perform more advanced searches including by using wildcard support. Users can also subscribe to a search result as an RSS feed, ask to be alerted through e-mail or text message if new items for the search are found, or bookmark it to rerun the search later. The SharePoint search engine is also more broadly accessible in that searches can be performed from the browser, smartphone device, or from a desktop running Windows 7. One of our favorite new search features is in people search where you can phonetically spell a user's name. No more hunting through the Global Address Book looking for the right spelling of Shawn. We will leverage the search functionality in Chapter 7. Use the following link for a video about the SharePoint 2010 Search features: http://sharepoint2010.microsoft.com/product/capabilities/search/pages/top-features.aspx.
The Insights portion of the wheel in Figure 2-1 refers to the functionality in SharePoint 2010 that helps users make decisions based on data visualizations. This includes features like Excel Services, Performance Point Services, Visio Services, and PowerPivot. Excel Services was introduced in MOSS 2007 and its focus was to enable users who leverage Excel to build visualizations of their data to share through a SharePoint page. In this scenario, a spreadsheet is connected to a data source and the user builds the visualization and then publishes it to the SharePoint server. Once it's on the server, SharePoint enables users to view and interact with elements of the spreadsheet without ever downloading the file in Excel. The interface is a thin client that uses DHTML, JavaScript, and images. There are lots of potential advantages to sharing the visualization in this manner. First, the server can continue to connect to the original data source, updating the visualization so the user sees the most recent result. If the spreadsheet were just e-mailed around, this would not be possible unless all users had access and connectivity to the data source. By publishing to the SharePoint server, you can also hide elements of the spreadsheet that you don't want to share, such as sheets of background data, and you can prevent access to formulas. Chapter 5 focuses on spreadsheets and Excel Services. All of the Excel Services functions continue in SharePoint 2010 and, in addition, you can access the spreadsheet in Excel Services through a REST API. REST stands for Representational State Transfer and means that Excel Services can render elements of the spreadsheet simply with a URL request. So, for example, the following URL would retrieve a chart from an Excel Services spreadsheet named CRMSales.xlsx http://intranet/sites/crm/_vti_bin/ExcelRest.aspx/Shared%20Documents/CRMSales.xlsx/model/charts('Chart%203'). The result is a PNG image that can be used in other applications. This technique is shown in Figure 2-7 and is used in Chapter 10 to pull in a visualization of orders information into Outlook.
In addition to Excel Services, SharePoint 2010 includes Performance Point Services and support for SQL Server PowerPivot for SharePoint. Performance Point Services is a significantly enhanced version of the dashboarding capability that in the 2007 wave was offered as a separate product—Microsoft Performance Point. Performance Point Services includes a dashboard designer that allows you to build SharePoint pages containing many data visualizations with actions specifying what should change as the user interacts with the page. For example, using the dashboard designer, you could have a page with a scorecard that, when the user clicks a particular key performance indicator, causes other report web parts to load on the page that would display details specific to that metric. Figure 2-8 shows an example Performance Point Services dashboard.
SQL Server PowerPivot for Excel and SharePoint is actually a new solution for enabling users to analyze large datasets without having to build an OLAP cube. This offering brings an in-memory analysis engine that can be used by the Excel client or a SharePoint 2010 server should the spreadsheet be published there.
Another new data visualization technology in SharePoint 2010 is Visio Services. Much like Excel Services, this new feature enables you to connect a data source to a Visio document and then publish it to the server. Data sources could include SQL Server, Excel spreadsheets, and even SharePoint lists. Once on the server, the diagram is available through the browser, and you can add conditions to alter the appearance of the diagram based on the data. Figure 2-9 shows a floor-plan visualization you will build in Chapter 13. Notice how the conference room C-101 is available and that the printers are showing icons and overlays from other data sources.
Use the following link for a video on more about the SharePoint 2010 Insights features: http://sharepoint2010.microsoft.com/product/capabilities/insights/pages/top-features.aspx.
The Composites portion of the wheel refers to the functionality in SharePoint 2010 that helps organizations bring together traditionally siloed applications into a seamless experience. This includes features like Business Connectivity Services, InfoPath Form Services, Access Services, and SharePoint Designer. Business Connectivity Services (BCS) in SharePoint 2010 represents the evolution of the Business Data Catalog (BDC) functionality that first appeared in MOSS 2007. The original BDC became the developers' best friend as it removed the need to reinvent the wheel over and over again to do the common tasks of integrating external data into the SharePoint environment. Instead of writing code, a developer could describe these external applications (whether database or web-services-based) with an XML file, including methods for how to retrieve the item, how to search for an item, and details on the makeup or attributes of the item. With the description, the BDC could make this data available to MOSS 2007 search, automatically provide web parts to view the external data on SharePoint pages, and use the data as metadata properties on SharePoint items. In SharePoint 2010, the BDC becomes the BCS and increases the scope of the application integration. While the BDC brought the data into SharePoint as read-only, BCS supports writing changes back to the original application. In fact, the Office 2010 desktop applications also play a part in BCS functionality. For example, the external content can be taken offline in Outlook or SharePoint Workspaces. We use this technique as part of the solution in Chapter 10. Microsoft Word can also use BCS data inline in documents. This technique is described in the solution in Chapter 6. Figure 2-10 shows a Customers table from a SQL Server surfaced in SharePoint as an external list using the Business Connectivity Services functionality.
In addition to the enhanced functionality of BCS to bring in external data, the tooling also improves. In the previous versions, developers would either create the application definition XML file either manually or with a non-integrated tool. Now in the 2010 toolset, registering applications into BCS is integrated into SharePoint Designer and Visual Studio 2010. The experience in SharePoint Designer is easy and wizard-driven, but is limited to connecting to applications via SQL Server, web services, or a specific .NET class. As long as you stay within those boundaries, you can get your external application into SharePoint 2010 without writing a line of code, as you'll see in Chapter 10. If you need to connect to other types of applications, Visual Studio allows you to write some code for the integration and then still leverage the BCS infrastructure. In the 2010 release, SharePoint Designer takes on a larger role and often serves as a no-code method to rapidly bring applications together in your SharePoint environment.
Another composites feature is the improved InfoPath Forms Services. This feature also debuted in MOSS 2007. InfoPath had existed in Office 2003 only as a desktop application and was the centerpiece in Microsoft's electronic forms strategy. The appeal of InfoPath was that it could be used by non-developers and developers alike. A business savvy user could open up InfoPath, use its designer to lay out the form, and distribute the form to users who would use InfoPath to complete it. Developers could use the tool to connect to the web services of their applications. Once InfoPath inspected the description of the web service, it could automatically create a form. In either case, when users completed forms, InfoPath generated XML files containing their data that could easily be posted to other data sources or applications. The major problem, however, was that the InfoPath client was required both to design the form and to fill it out. This limited the tool to being used only within enterprises since you couldn't count on an external user having InfoPath. MOSS 2007's Form Services solved the problem by automatically creating a web-based equivalent of the form, including persisting any code a developer may have written. In SharePoint 2010, InfoPath Forms Services expands beyond traditional electronic forms. You can now use this service and InfoPath to design alternative forms for list items (view, edit, new). So instead of having to write custom web parts in Visual Studio in front of list items, developers can control the layout of the form, add advanced validation, incorporate other external data all through by using InfoPath to design the list item's form user interface. By the way, this form also goes with the list into SharePoint Workspace so the same user interface appears in the offline tool as the web interface. There is also an InfoPath form web part that is useful for composite applications. InfoPath Form Services is used as part of the solution in Chapters 5 and 11.
SharePoint 2010 also includes a feature called Access Services. Microsoft Access has long been a development tool with a lower bar of entry than Visual Studio or SQL Server. We can't tell you how often we've seen customers whose department-level Access database grew into a mission-critical application. Access is often used when a business user has a compelling need and requires a solution faster than an enterprise's developers can deliver. These types of applications often make a business more agile. The problem is that IT shops often clamp down on such activity because of how many times they have had to support these applications as they grow beyond the original intent. In SharePoint 2010, Access Services is the answer that promotes an Access application into a web-based, SharePoint-based solution. Not only do the tables and data find their way into SharePoint lists, but even the Access forms get converted into SharePoint pages. This can increase the reach of the solution and provide IT with a path to reduce governance risks. Access Services is the focus of Chapter 12. Figure 2-11 shows the creation of a web-based database in Access that could be published to SharePoint.
SharePoint 2010's out-of-the-box support for Silverlight makes it easier for developers to build interactive experiences that bring together data from multiple sources. In Chapter 5, we will use Silverlight to provide an interactive, graphical experience for the user to navigate the charts contained in Excel spreadsheets of a document library. As shown in Figure 2-12, the solution in Chapter 14 brings together several data feeds into a single mashup on top of Bing Maps.
Use the following link for a video about the SharePoint 2010 Composites features http://sharepoint2010.microsoft.com/product/capabilities/composites/pages/top-features.aspx.
This by no means is a complete guide to SharePoint 2010. If you are new to the SharePoint world, we highly recommend spending some time with some overview books or the materials on http://sharepoint.microsoft.com. When we introduced this chapter, we called out the importance of SharePoint 2010 as a platform, and the solutions presented in this book take this to heart. We don't simply stick to out-of-the-box functionality, but show how the features of SharePoint and Office along with the .NET framework enable developers to build effective solutions for information workers. In the next chapter, we dive deeper and take a closer look at the SharePoint development support in Visual Studio 2010.