Giải pháp Sharepoint

Nghiên cứu sâu hơn về Windows SharePoint Services 3.0 (WSS 3.0)

WSS 3.0 là một thành phần bổ sung miễn phí của Windows Server 2003, là một công cụ tạo site linh hoạt giúp giải quyết vấn đề tạo lập và quản lý hàng nghìn trang web với hàng chục ngàn người truy cập. Nhờ sự linh hoạt của mình, WSS 3.0 có thể được hiểu như một môi trường sản sinh ra các trang web chạy trên một web server và có sự tham gia của MS SQL server với vai trò lưu trữ dữ liệu.

Cũng như các phiên bản trước, WSS hỗ trợ các tính năng cộng tác ngoài giúp người dùng dễ dàng thiết kế các website, ví dụ như Shared Carlendars, Contact Lists hay Document Libraries. Tuy nhiên ở khía cạnh lập trình viên, WSS 3.0 là một nền tảng phát triển được trang bị đầy đủ, bổ sung những sức mạnh đáng nể trên nền ASP.net.

WSS đơn giản hóa việc tạo và lưu trữ trang, các danh dách và thư viện tài liệu, cho thấy rõ ở đâu và làm thế nào để lưu trữ các trang, hơn nữa lại có thể thay đổi những sản phẩm tạo sẵn nhờ thao tác của người dùng hay chỉnh sửa mã nguồn thông qua giao diện chạy trên trình duyệt. Nó còn lược bỏ nhiều thao tác buồn tẻ bắt buộc phải có trong lập trình ASP thông thường nhờ bổ sung các thành phần giao diện giúp người dùng thêm, xem và sửa nội dung.

ASP.NET 2.0 giới thiệu một kiểu thành phần plugin gọi là công cụ cung cấp đường dẫn ảo. Một lập trình viên có thể viết các thành phần tùy biến để nhận trang .aspx từ bất kỳ đường dẫn nào bao gồm cả trong dữ liệu SQL server. Khi bộ cung cấp đường dẫn ảo nhận được một trang .aspx, nó có thể để yên cho ASP.NET hướng dẫn việc phân tích hay biên dịch cần thiết. ASP.NET còn mang đến cho bộ cung cấp đường dẫn ảo một sự thỏa thuận điều khiển tốt về cách thức phân tích trang .aspx và quyết định chúng có thể được biên dịch và chạy trong một môi trường không biên dịch được hay không.

Đội phát triển WSS 3.0 đã viết riêng một bộ cung cấp đường dẫn ảo mang tên SPVirtualPathProvider. SPVirtalPathProvider (SPVPP) có thể lấy các trang .aspx từ SQL server và sau đó để cho bộ phân tích trang .aspx xử lý. Điều này có nghĩa đội phát triển WSS đã không bị đòi hỏi phải cải tiến bộ phân tích trang .aspx, cũng có nghĩa WSS 3.0 không phải nhức đầu về chuyện giảm bớt tập hợp tính năng phân tích trang và cứ thế làm như với WSS 2.0.

Tích hợp với ASP.net 2.0

WSS 3.0 được khởi động bằng website chạy trên IIS- trong tài liệu này một website như vậy được gọi là một ứng dụng web.

WSS 2.0 được tích hợp với IIS 6.0 và ASP.NET 1.1 thông qua một ISAPI filter DLL. Sự tích hợp này dẫn đến việc định hướng của IIS (IIS routing) yêu cầu WSS trước ASP.NET. Điều này cho thấy một số điểm chưa rõ ràng trong những tình huống cụ thể vì WSS giành điều khiển của một HTTP request trước khi nó có cơ hội được khởi tạo đầy đủ trong ngữ cảnh của ASP.net.

Cách thức WSS tích hợp với ASP.net đã được thiết kế lại hoàn toàn. Đầu tiên WSS được xây dựng trên ASP.net 2.0 (mạnh hơn đáng kể so với ASP.net 1.1).  Hơn nữa, sự tích hợp được thay đổi thành việc định hướng các request qua ASP.NET runtime trước khi đến WSS. Đội phát triển WSS đã thực hiện điều này bằng cách loại bỏ ISAPI filter và bổ sung HttpModule cùng với HttpHandler đã đăng ký trước với ASP.net nhờ sử dụng những mục Web.config chuẩn. Điều này có nghĩa các HTTP request đến luôn luôn truy cập vào ASP.net runtime environment và được khởi tạo đầy đủ trong ngữ cảnh của ASP.net trước khi được forward đến mã nguồn viết bởi WSS để thực hiện một xử lý đặc thù của WSS.

Cũng cần phải lưu ý rằng khi mở rộng một trang web trên IIS thành một ứng dụng web của WSS, WSS 3.0 bổ sung một sơ đồ ứng dụng thay thế vào IIS metabase. Sơ đồ ứng dụng thay thế này phục vụ cho việc định hướng các HTTP request đến ASP.net Runtime tùy vào phần mở rộng, nó cần thiết cho việc forward một request đến kiểu file bất kỳ (PDF, DOC, DOCX) đến ASP.net, cuối cùng là forward đến WSS để xử lý.

Một phần quan trọng khác của kiến trúc mới là phải làm việc với cách thức phân tích và biên dịch một trang .aspx. Bộ phân tích cú pháp của trang .aspx trong ASP.net 1.1 chỉ làm việc với những trang .aspx nằm ở hệ thống file cục bộ. Tuy nhiên, kiến trúc WSS dựa trên lưu trữ các trang .aspx trong cơ sở dữ liệu SQL server. Vì WSS 2.0 dựa trên ASP.net 1.1 nên đội phát triển WSS phải tạo riêng một bộ phân tích trang .aspx riêng. Thật không hay là bộ phân tích .aspx trong WSS 2.0 không hỗ trợ nhiều tính năng như bộ phân tích .aspx của ASP.NET.

ASP.NET 2.0 giới thiệu một kiểu thành phần plugin gọi là công cụ cung cấp đường dẫn ảo. Một lập trình viên có thể viết các thành phần tùy biến để nhận trang .aspx từ bất kỳ đường dẫn nào bao gồm cả trong dữ liệu SQL server. Khi bộ cung cấp đường dẫn ảo nhận được một trang .aspx, nó có thể để yên cho ASP.NET hướng dẫn việc phân tích hay biên dịch cần thiết. ASP.NET còn mang đến cho bộ cung cấp đường dẫn ảo một sự thỏa thuận điều khiển tốt về cách thức phân tích trang .aspx và quyết định chúng có thể được biên dịch và chạy trong một môi trường không biên dịch được hay không.

Đội phát triển WSS 3.0 đã viết riêng một bộ cung cấp đường dẫn ảo mang tên SPVirtualPathProvider. SPVirtalPathProvider (SPVPP) có thể lấy các trang .aspx từ SQL server và sau đó để cho bộ phân tích trang .aspx xử lý. Điều này có nghĩa đội phát triển WSS đã không bị đòi hỏi phải cải tiến bộ phân tích trang .aspx, cũng có nghĩa WSS 3.0 không phải nhức đầu về chuyện giảm bớt tập hợp tính năng phân tích trang và cứ thế làm như với WSS 2.0.

Trong kiến trúc của WSS 2.0 có 2 khái niệm “ghosting” và “unghosting”. Page Ghosting là một chức năng cho phép web server lưu trữ một mẫu trang .aspx trên hệ thống tệp cục bộ của nó và chia sẻ mẫu này qua nhiều site. Page Ghosting mang lại lợi ích về hiệu năng vì WSS có thể tạo hàng ngàn trang sử dụng chung một template trên hệ thống tệp cục bộ và được nạp vào bộ nhớ chỉ một lần.

WSS 2.0 giúp việc tùy biến của người dùng trở nên thuận tiện nhờ các công cụ như Front Page 2003.  Khi người dùng thay đổi một mẫu trang và ghi lại những thay đổi đó, thì một phiên bản mới của trang sẽ được lưu trong SQL Server. Trong WSS 2, việc này được xem như là “page unghosting” .

WSS 3.0 vẫn hỗ trợ các mẫu trang nằm trên web server cũng như các phiên bản đã tùy biến của chúng được lưu trữ trong SQL Server. Tuy nhiên đội dự án WSS 3.0 không còn dùng khái niệm ghosting và unghosting nữa vì chúng khó dịch sang khác ngôn ngữ khác, thay vào đó là các khái niệm “uncustomized page”  (mẫu trang được sử dụng trực tiếp trên hệ thống file cục bộ của webserver) và “customized page” (phiên bản đã chỉnh sửa của mẫu trang đã được ghi vào cơ sở dữ liệu cho một trang riêng biệt).

Một sự thay đổi khác là phiên bản mới của FrontPage 2003 được xuất hiện dưới cái tên mới: Microsoft Office SharePoint Designer 2007 (MOSD). MOSD cũng hướng người dùng hơn là lập trình viên. Nhưng dù sao thì đối với mỗi lập trình viên, có nó vẫn hơn không!!!

MOSD cung cấp hệ soạn thảo và bộ thiết kế WYSIWYG để tùy biến các trang .aspx trong các site WSS 3.0. Ta còn có thể tạo ra các trang mới trong một site WSS 3.0 mà không có một mẫu tương ứng nào trên Web server. MOSD 2007 hỗ trợ tạo list và document library, thậm chí cung cấp một giao diện mới giúp tạo ra các workflow mong muốn trong site WSS 3.0.

  •  Làm việc với Master Page

Một trong những nét buồn tẻ nhất trong WSS 2.0 là tạo ra một dạng cảm quan (look and feel) nhất quán giữa các trang. Nguyên nhân là do ASP.net 1.1 không cung cấp bất kỳ công nghệ dựng mẫu trang nào có thể sử dụng trên nhiều trang trong WSS 2.0 site. Vì thế mà các lập trình viên và người thiết kế đã sắp xếp lại để cắt/dán các mẫu trình bày HTML từ trang này sang trang khác, rất khó để tùy biến và bảo trì một site có những yêu cầu trình bày khác so với những gì sẵn có bằng WSS 2.0 site chuẩn.

ASP.NET 2.0 mang đến một tính năng tạo mẫu trang rất mạnh gọi là master page. Nó chính là một mẫu cho phép định nghĩa một định dạng trình bày trang cho cả site có những thành phần như banner, các điều khiển trình duyệt (navigation control) và menu. Các trang link đến master page gọi là content page.

Điểm chính yếu là mỗi content page liên kết đến master page để thu được layout chia sẻ, rồi mở rộng master page bằng cách bổ sung các nội dung tùy biến vào các điểm giữ chỗ đã đặt tên có thể thay thế được (replaceable named placeholder).

WSS 3.0 được thiết kế từ dưới lên để bao trùm cấu trúc master page của ASP.NET 2.0. Mỗi site WSS 3.0 được tạo ra từ một danh mục đặc biệt gọi là Master Page Gallery chứa đựng một master page với tên gọi default.master. Master page này định nghĩa một cách trình bày chung cho mọi trang chủ của site (default.aspx) cũng như mọi trang chuẩn của WSS 3.0 liên kết với các list và document library (ví dụ: allItem.aspx, newItem.aspx). Dạng trình bày của master page chứa đựng các menu và điều khiển trình duyệt chuẩn của WSS.

Sự định nghĩa về default.master bao hàm một vài điểm giữ chỗ đã được đặt tên như PlaceHolderPageTitle, PlaceHolderMain và PlaceHolderLeftNavigation. Điều này giúp tạo các content page thuộc site (có cùng định dạng trình bày) trở nên tương đối đơn giản. Đoạn mã dưới đây chỉ rõ việc tạo một content site là dễ dàng đến thế nào:

<%@ Page language=”C#” MasterPageFile=”~masterurl/default.master” %>

     

Welcome to customization with WSS V3

      Trang được tạo ra quá đơn giản, hơn nhiều so với WSS 2!!

Việc định nghĩa content page thể hiện trong code không thể nào đơn giản hơn.  Nó chỉ làm một việc đơn giản là thêm một đoạn HTML cực ngắn trong PlaceHolderMain, nhưng đủ để tạo một dạng trình bày trang WSS chuẩn với biểu tượng, menu và các thanh navigation. Khi biết cách sử dụng tập các placeHolder được định nghĩa trong default.master, ta có thể dễ dàng đổi chỗ các thành phần chuẩn của WSS như menu và navigation bar hay thay thế chúng bằng những ASP.NET control hay Webpart của riêng mình. Điều này là thực hiện được ở phạm vi một site, một site collection hay lớn hơn thế.

Master page và content page được lưu trữ và nạp lên cùng dựa trên những nguyên lý của mẫu trang và tùy biến trang (đã thảo luận). Có các mẫu trang cho master page và content page nằm trong hệ thống file cục bộ của webserver. Mỗi site ban đầu sử dụng phiên bản chưa tùy biến của mẫu master page và content page. Tuy nhiên, khi người sử dụng tùy biến và lưu trữ lại sự thay đổi nhờ MOSD 2007, thì phiên bản đã chỉnh sửa được lưu lại trong cơ sở dữ liệu của SQL server.

Ta có thể tùy chọn chỉ mình master page mà không quan tâm đến các content page hoặc ngược lại, thậm chí thay đổi cả hai, nhưng rồi cuối cùng muốn hủy bỏ mọi sự thay đổi, thì cả giao diện trên Browser của WSS 3.0 lẫn MOSD 2007 đều hõ trợ các menu đơn giản để xóa bỏ dấu vết trên cơ sở dữ liệu của SQL server và khôi phục lại mẫu trang ban đầu.

Lưu ý rằng mỗi site có Master Page Gallery chứa default.master và thuộc tính Master-Url của riêng nó, nên không phải các site trong site collection đều tự động sử dụng cùng một master page. Tuy nhiên, khá đơn giản để viết một vài mã lệnh có sử dụng đệ quy ngược với mô hình đối tượng của WSS 3.0 để đồng bộ hóa một site ngoài cùng (top-level) và các site con trong một site collection để sử dụng chung một master page.

  • Các Web Part trong WSS 3.0

Một trong những cách làm phổ biến nhất của các lập trình viên khi mở rộng các site của WSS 2.0 là tao ra những web part mong muốn. Ưu điểm của Web part là có thể bổ sung được nhiều tùy chọn cá nhân của người dùng.

Vì tính phổ dụng của Web part trong WSS 2.0, Microsoft đã quyết định hỗ trợ thêm cho khả năng phát triển các Web part mong muốn vào ASP.NET 2.0. Chiến lược hướng tới một lực lượng đông đảo người sử dụng là lập trình viên đã hoàn tất bằng việc tạo ra một cấu trúc bên trong mới mẻ của Web part cho ASP.NET 2.0, cái chưa từng có ở WSS 2.0.

Do đó hiện nay có hai kiểu Web part khác nhau:

  • Kiểu cũ (kiểu WSS) phụ thuộc vào Microsoft.SharePoint.dll và phải kế thừa từ lớp cơ sở WebPart định nghĩa bởi đội dự án WSS 2.0 trong namespace Microsoft.SharePoint.WebPartPages.
  • Kiểu mới (kiểu ASP) phụ thuộc vào System.Web.dll và phải kế thừa từ một lớp cơ sở khác cũng mang tên WebPart định nghĩa bởi đội dự án ASP.NET 2.0 trong namespace System.Web.UI.WebControls.WebParts.

WSS 3.0 cần phải được thiết kế với mục tiêu chạy được cả Web part kiểu cũ và Web part kiểu mới. Điều này đã thực hiện được với việc xây dựng các hỗ trợ của WSS 3.0 cho Web part bên trên hạ tầng Web part của ASP.NET, sau đó tạo ra các thay đổi cho Microsoft.SharePoint.dll sao cho các Web part kiểu WSS (viết cho WSS 2.0) có thể được tương thích với WSS 3.0 runtime environment.

Để lý giải làm thế nào Web part được nạp và chạy trong WSS 3.0, đầu tiên ta thảo luận về việc làm thế nào kiến trúc WSS 3.0 được thiết kế thành lớp trên cùng của hạ tầng Web part của ASP.NET 2.0. Đầu tiên, cần xem xét cách mà các trang Web part được trình bày trong WSS 3.0, sau đó ta sẽ đi vào chi tiết cách thức phát triển các Web part cho môi trường WSS 3.0.

Để chạy các Web part trong ứng dụng ASP.NET 2.0, ta phải tạo một trang .aspx chứa đúng một thể hiện của control WebPartManager và một hay nhiều control WebPartZone. Control WebPartManager chịu trách nhiệm xuất bản các dữ liệu liên quan đến Web part cũng như lưu trữ và truy xuất nó từ các bảng trong cơ sở dữ liệu của các ASP.NET service.

Trang .aspx tương tự như một trang Web part cũng có thể chứa các Editor Part cho phép người dùng tùy biến và cá nhân hoá các thuộc tính Web part. Các trang Web part cũng có thể chứa các Catalog Part, cho phép người dùng bổ sung Web part mới vào các zone khác nhau.

Hạ tầng Web part của WSS 3.0 được xây dựng trên một control mang tên SPWebPartManager nhận được từ control WebPartManager của ASP.NET 2.0. Control SPWebPartManager nạp chồng (override) các hành vi chuẩn của control WebPartManager để giữ nguyên dữ liệu Web part bên trong cơ sở dữ liệu nội dung của WSS thay cho cơ sở dữ liệu của ASP.NET services. Ta không cần phải lo lắng về chuyện làm việc trực tiếp với control SPWebpartManager vì thể hiện duy nhất của nó đã được định nghĩa trong trang default.master. Khi tạo ra một content page kế thừa từ default.master,  control SPWebPartManager đã có sẵn ở đó.

Các điều khiển khác xuất hiện trên một trang WSS 3.0 Web part thông thường chứa đựng các Web Part zone, Editor Part và Catalog Part. Chú ý rằng các Web part zone cho một trang Web part trong WSS 3.0 nên được tạo ra bằng control WebPartZone định nghĩa trong namespace Microsoft.SharePoint.WebPartPages mà không phải control WebPartZone của ASP.Net 2.0

 

Một trang Web part trong WSS 3.0 đòi hỏi có control SPWebPartManager và một hoặc nhiều control WebPartZone. Nếu ta tạo ra một content page kế thừa từ lớp WebPartPage, ta có thể nhận được những tiện ích của WSS 3.0 như Editor Part và Catalog Part cung cấp sẵn. Các thể hiện của control WebPartZone thường được định nghĩa trong content page. (đoạn code không gõ vào…)

Khi tạo ra một trang Web part cho một ứng dụng ASP.NET 2.0 chuẩn, ta cần phải thêm các logic tương tác với control WebPartManager để quản lý chế độ hiển thị của Web part. Bình thường ta cũng cần phải bổ sung Editor Part và Catalog Part một cách rõ ràng vào trang dùng định dạng trình bày HTML để bố trí chúng. Rất may là ta không cần phải làm những việc ấy khi tạo ra các trang cho một site WSS 3.0, thay vào đó ta kế thừa từ lớp WebPartPage đã định nghĩa sẵn trong namespace Microsoft.SharePoint.WebPartPages và để nó làm toàn bộ mọi thứ.

(*)Phát triển một Web part tùy chọn: Sẽ nghiên cứu sau ở giai đoạn code

  • Điểm nổi bật trong lưu trữ nội dung

WSS 2.0 bị phê phán rằng một số tính năng giá trị hỗ trợ cho document library lại không mở rộng cho list. Ví dụ document library hỗ trợ đánh số phiên bản (versioning) và các sự kiện, nhưng list thì không. Trong WSS 3.0, list đã hỗ trợ nhiều tính năng giống như document library bao gồm versioning, events và folders. Ngoài ra còn có một vài tính năng mới hỗ trợ cho cả list và library trong WSS 3.0 như trình bày dữ liệu đến từ các RSS feed tự động.

WSS 2.0 còn bị phàn nàn về hiệu năng khi làm việc trên list và document library lớn. Ví dụ list thường bắt đầu cho thấy hiệu năng yếu kém khi số lượng phần tử vượt quá 2000. Document library cũng tương tự như vậy. Vì thế việc đi đến một sự phối hợp để phân chia các document ra nhiều thư mục trong cùng một document library đã trở thành cách tiếp cận phổ biến trong  WSS 2.0 để giải quyết vấn đề số lượng document lớn.

WSS 3.0 giới thiệu tính năng đánh chỉ mục cột (column indexing) mới để giảm nhẹ vấn đề về hiệu năng nói trên. Từ một trang thiết lập list hay document library, ta có thể thêm một chỉ mục vào một cột bất kỳ. Việc làm này không thật sự tạo ra một chỉ mục trong SQL Server, mà nó tạo ra một bảng với ID là số nguyên của phần tử thuộc list hay document và giá trị của cột đã được đánh chỉ mục. WSS sau đó sử dụng bảng này để tăng hiệu năng xử lý dữ liệu trả về từ các view, đặc biệt là một view xây dựng nhờ bộ lọc trên các cột đã đánh chỉ mục.

Nhiều lập trình viên mong muốn làm việc với các field của WSS 3.0 ở một cấp độ thấp hơn để có thể thu được nhiều control thông qua việc xác nhận và diễn tả nó. Đội dự án WSS đáp lại mong muốn đó bằng cách bổ sung các kiểu field có thể mở rộng trong WSS 3.0. Ta có thể tạo ra một kiểu field mở rộng được bằng cách viết một lớp trong C# hay VB.NET có kế thừa từ các kiểu field dựng sẵn trong WSS như SPFieldText, SPFieldNumber hay SPFieldUser. Một kiểu field mở rộng được cũng có thể tận dụng control User của ASP.NET chứa đựng các Web control ưa thích của ta. Điều này cho phép ta sử dụng cùng một kỹ thuật để khởi tạo và xác nhận control mà ta đã sử dụng trong các ứng dụng ASP.NET.

Một cải tiến hấp dẫn nữa trong WSS 3.0 là các custom site column. Một site colum là một định nghĩa có thể tái sử dụng, có thể được sử dụng trong nhiều list. Một site column định nghĩa tên của một column, kiểu field cơ sở của nó và các đặc điểm khác như giá trị mặc định, định dạng và chuẩn hóa của nó. Khi đã định nghĩa một site column, ta có thể sử dụng nó giống như ta định nghĩa cấu trúc của một list tự tạo. Lợi ích hiển nhiên là ta có thể cập nhật site column ở chỉ một nơi và thu được kết quả update trong cả danh sách nơi mà site colum đã được sử dụng.

Một site column được định nghĩa trong phạm vi của một site đơn, nó chưa hiển thị ở tất cả các site con bên dưới trang mà ở đó nó được định nghĩa. Do đó ta có thể tạo ra một site column có thể tái sử dụng trong toàn bộ site collection bằng cách định nghĩa nó ở trang trên nhất.

Một kỹ thuật thuật tiện được giới thiệu cùng với site colum là khả năng thực hiện tìm kiếm field qua các site. Ví dụ ta có thể tạo ra một site colum ở trang ngoài cùng có nhiệm vụ thực hiện việc tìm kiếm trên một list trong cùng site. Sau đó ta có thể tạo ra các list khác trong site con sử dụng site …

  • Xử lý sự kiện

Bộ xử lý sự kiện trong WSS 2.0 có hỗ trợ xử lý sự kiện, song sự hỗ trợ này là rất nhỏ và nhận được nhiều lời phàn nàn từ phía cộng đồng các lập trình viên. Các sự kiện trong WSS 2.0 được hỗ trợ cho document library nhưng không cho list. Hơn nữa WSS 2.0 chỉ hỗ trợ các sự kiện không đồng bộ diễn ra sau khi hành động của người dùng đã được chuyển đến cơ sở dữ liệu SQL server, nghĩa là không có cách nào để hủy bỏ một hành động của người dùng trong bộ xử lý sự kiện.

Hỗ trợ xử lý sự kiện trong WSS 3.0 đã được nâng cấp đáng kể. Ngoài hỗ trợ những sự kiện không đồng bộ như WSS 2.0 đã làm được, nó còn hỗ trợ cho những sự kiện đồng bộ, cho phép lập trình viên hủy bỏ thao tác người dùng. Ví dụ ta có thể cấm người dùng xóa một văn bản một khi nó đã được duyệt hoặc sắp được tạo ra ở một thời điểm định trước trong tương lai. Hơn thế nữa, các sự kiện giờ đây đã được bổ sung cho list, giống như cho document library.

Ngoài việc hỗ trợ các sự kiện trên list và document, WSS 3.0 hỗ trợ nhiều kiểu sự kiện mới khác nhau mà chưa từng có trong WSS 2.0. Có các sự kiện trên list xảy ra khi một ai đó thay đổi định nghĩa list. Ví dụ ta có thể hủy hành động của một người nếu anh ta cố gắng loại bỏ hay đổi tên một cột trong danh sách tùy chọn của ta. Bên cạnh đó còn có các sự kiện xảy ra bất kỳ khi nào có người xóa hay di chuyển một site hay toàn bộ một site collection.

  •  Workflow trong WSS 3.0

Thành phần WinFX run-time được ra mắt vào cuối năm 2006 với cái tên Windows Workflow Foundation (WinWF) đã bổ sung một hạ tầng đầy đủ cho việc xây dựng các ứng dụng kiểu workflow. Hạ tầng WinWF chứa một công cụ workflow, các thành phần linh hoạt (pluggable) để làm liên tục trạng thái workflow, và một bộ thiết kế Visual Studio giúp dễ dàng tạo các workflow bằng cách kéo các thành phần (được biết đến như là các hoạt động) vào không gian thiết kế workflow.

WSS 3.0 xây dựng trên WinWF để cung cấp một cơ sở để đính các logic nghiệp vụ vào các phần từ của danh sách hay các document. WSS 3.0 mở rộng mô hình workflow của WinFX bằng cách liên kết một danh sách tác vụ và danh sách history với mỗi workflow. Phần mở rộng của WSS 3.0 dành cho WinFX nâng cao trách nhiệm của workflow, yếu tố có “tính người”  trong tự nhiên, ví dụ như một workflow dành cho kiểm duyệt và rà soát một văn bản.

Cả WSS 3.0 lẫn MOSS 2007 ra mắt với các workflow đã cài đặt sẵn và sẵn sàng cho việc  sử dụng trong thực tế. WSS 3.0 chứa đựng một vài workflow định hướng đơn giản cho những việc như kiểm soát hay xét duyệt văn bản. MOSS 2007 cung cấp các workflow phức tạp hơn và được sử dụng để hỗ trợ các tính năng như tiến trình phê chuẩn nội dung web.

Các workflow tùy biến diễn tả rõ ràng một khả năng mở rộng cho các lập trình viên tạo giải pháp nghiệp vụ với WSS 3.0 và MOSS 2007. Bên cạnh những hỗ trợ chuẩn của Vistual Studio Extension cho WinFX, đội dự án Office còn có kế hoạch cho ra mắt một workflow SDK chuyên biệt của WSS và một bộ công cụ khởi đầu workflow bao gồm cả các mẫu project cho Visual Studio nhằm tạo ra các workflow mong muốn trên các site WSS 3.0.

MOSS 2007 còn hỗ trợ tạo các workflow tùy chọn trong các site WSS 3.0. Hỗ trợ này được thiết kế dành cho người dùng cao cấp hơn là các lập trình viên vì có cung cấp giao diện để đính kèm các logic nghiệp vụ phức tạp vào các phần tử của list và document trong quá trình tạo dựng một site WSS 3.0.

  • Các định nghĩa site (site definition), các tính năng và giải pháp

Các lập trình viên từng sử dụng WSS 2.0 như một platform để xây dựng các giải pháp nghiệp vụ nhận thấy rằng làm việc với định nghĩa site cấp thấp mang lại số lượng control lớn nhất và khả năng tái sử dụng cao. Một định nghĩa site là một thư mục trên Web server ngoài chứa các file XML mẫu trang .aspx có chức năng định nghĩa thiết kế của một site, bao gồm cả lược đồ list và trình bày trang. Ngôn ngữ dựa trên XML sử dụng trong nhiều tệp định nghĩa site được gọi là Collaborative Application Markup Language (CAML).

WSS 2.0 có một số điểm bị các lập trình viên chê trách:

  • Các tệp XML trong định nghĩa site của WSS 2.0 là khá nghèo nàn và khó điều khiển.
  • Microsoft không hỗ trợ cải tiến một định nghĩa site một khi nó đã được sử dụng để tạo ra các site. Có nghĩa không có hỗ trợ kỹ thuật nào cho các định nghĩa trang để có thể sử dụng vào mục đích bổ sung các tính năng vào một site WSS 2.0 đang tồn tại.
  • Định nghĩa site và các tùy chọn tập hợp phụ thuộc vào những công cụ tạo lập được cung cấp, bởi lẽ các tệp cần phải được đẩy ra mỗi Web server mà không có một hỗ trợ nào từ hạ tầng WSS.
  • WSS 2.0 không cung cấp phương tiện để khoanh vùng một định nghĩa size. Điều này làm ảnh hưởng đến các doanh nghiệp muốn quốc tế hóa các giải pháp nghiệp vụ đã xây dựng trên WSS 2.0.

Với WSS 3.0, định nghĩa site là một thư mục chứa các file XML xây dựng bởi CAML và các mẫu trang. Tuy nhiên, các tính năng này đưa ra một cách tiếp cận rời rạc hơn bởi vì không cần phải định nghĩa thiết kế cho toàn bộ site, thay vào đó một tính năng đơn giản có thể định nghĩa một thành tố site như định nghĩa list tùy biến hoặc một menu lệnh tùy biến hiển thị ở một trong những menu chuẩn của WSS.

Một khía cạnh khá thú vị ở các tính năng này là chúng có thể được kích hoạt trên một site đang tồn tại. Ví dụ: ta có thể tạo ra một tính năng giúp định nghĩa kiểu list mong muốn, một thể hiện của kiểu list đó, và kiểm soát sự kiện hoặc workflow trên thể hiện list đó. Một khi các tính năng đã được cài đặt, từ dòng lệnh hoặc.

  • Bảo mật kiểu Internet (Internet-style security)

Việc phân quyền trong WSS 2.0 dựa trên các toài khoản Windows và các Security ID liên quan. Điều này có nghĩa WSS 2.0 gắn bó chặt chẽ với Active Directory trong mọi hành động trong khi chỉ sử dụng một phần tối thiểu. Sự phụ thuộc này không đáng kể cho những công ty đã triển khai Active Directory khi bắt đầu sử dụng WSS 2.0 và Windows SharePoint Portal Server 2003 để xây dựng các giải pháp nội bộ. Tuy nhiên sẽ có nhiều khó khăn hơn với những công ty xây dựng các giải pháp liên quan đến bên ngoài. Sự đóng cặp chặt chẽ của WSS 2.0 và Active Directory tạo ra ấn tượng xấu rằng WSS 2.0 là một ứng dụng không phù hợp cho các site đưa lên internet vì phần lớn công ty không tạo ra các tài khoản Active Directorry cho những người dùng lạ ghé thăm website ở lần đầu tiên qua internet.

Tất cả những điều này đã thay đổi trong WSS 3.0 vì việc phân quyền đã được thiết kế lại bên trên cấu trúc hỗ trợ phân quyền mới của ASP.Net 2.0 (authentication provider infrastrcture). Nếu không muốn bảo trì các tài khoản người dùng cho WSS 3.0 và các site MOSS 2007 bên trong Active Directory, ta có thể xây dựng hoặc yêu cầu một công cụ phân quyền ASP.NET (authentication provider) được thiết kế để lưu trữ và quản lý tài khoản người dùng trong một kho chứa định danh khác.

Ví dụ, ASP.Net 2.0 ra mắt với các form phân quyền cho phép ta bảo trì các tài khoản người dùng trong cơ sở dữ liệu SQL Server. Bộ cung cấp phân quyền này có thể được thiết lập cho việc sử dụng trong các site WSS 3.0. Với một chút công sức ta có thể đặt một site WSS 3.0 lên internet, cho phép những người dùng lạ có thể đăng ký thành viên. ASP.NET 2.0 mang đến cho ta sự tiện lợi trong việc thay đổi và tái lập mật khẩu của họ.