定義視覺

Mary Kirtland
Microsoft Corporation

2001 年 1 月 10 日

在 上周的資料行中，我引進了 Web 服務指引小組和我們的任務：建置、部署和操作範例 Web 服務，以說明您在執行相同動作時需要考慮的問題類型。 我也引進了我們的第一個範例專案我的最愛服務。

感謝您的留言和意見反應。 我們正在追蹤您提出的問題，因此請保留 'em coming！

有人詢問為何需要三個月的時間才能發行範例，以及我們為何在宣佈想法之前尚未開始。 事實上，我們已在過去兩個月內處理我的最愛幾乎完全。 許多功能都是正常 運作... 但在一切封裝好且整齊的範例之前，仍有一些工作要做，您可以安裝在自己的機器上，或透過網際網路試用。 撰寫、技術檢閱、編輯及處理我們想要隨附範例來源的所有文章，也需要一些時間。 因此，這就是為什麼我們要以三個月專案週期為目標。 我們將手指保持交叉，讓我們能夠在 2 月取得第一個我的最愛版本。 (撰寫此作業時，小組會進行排程練習，以取得較佳的發行日期估計。)

有些批註也假設我們使用.NET Framework來開發此範例。 這不一定是這種情況。 我們將使用我們認為最適合工作的任何技術。 而且最好不一定表示技術上更上層、更容易使用，或新聞中大部分。 無論我們選擇什麼，我們都會告訴您原因，我們會告訴您當我們嘗試使用它時所執行的問題。

本周，我們將開始查看小組在建置我的最愛服務時遇到的問題。 有許多待辦專案，但我們會從頭開始：找出專案的目標和目標。

開始使用

在 Microsoft 解決方案架構 程式模型中，任何專案中的第一個階段是 構想階段。 在構想階段，專案小組和客戶會建立專案目標和條件約束的高階檢視。 此階段的主要交付專案是視覺檔，其中包含商務問題的分析、產品目標的描述、解決方案概念的大綱、產品的設定檔、設計目標，以及專案範圍的定義。 構想階段會在 視覺/範圍核准的 里程碑中產生。

我們的小組從不尋常的起點開始：我們知道我們想要撰寫 Web 服務，但我們沒有任何特定的問題網域，也沒有使用現有的應用程式。 因此，我們需要做的第一件事是提出合理的實際商務案例，以合理方式建置可調整、可靠等等。Web 服務。

我們一開始會鎖定會議室中的一群人，並腦力激蕩潛在的企業或產業、服務和技術問題，以取得指引。 在過程中，我們會產生一些您可能想要建置 Web 服務的原因：

• 您是使用者或其他企業想要使用的時間敏感性或參數化資料來源。 如果資料不常變更，而且用戶端幾乎一律想要所有資料，您也可能只會在網站上張貼 XML 檔。 但是，如果用戶端想要對您的資料執行查詢，則 Web 服務會相當合理。 如果您想要將資料推送至用戶端，訂用帳戶和通知作業也是潛在的 Web 服務。
• 您可以實作其他企業無法或不想自行實作的演算法。 在此情況下，每個演算法都是潛在的 Web 服務：用戶端傳入資料，您會以答案回應。
• 您可以匯總數個其他服務，以提供較高層級的服務。 在此情況下，用戶端會使用您的服務，因為它會提供所需的資訊組合，並儲存它們結合現有服務本身的工作。
• 您想要整合企業流程與合作夥伴。 跨企業界限的商務程式每個步驟都是潛在的 Web 服務或 Web 服務作業。
• 您有異質和/或地理位置分散的企業架構，其中使用私人網路或緊密結合的應用程式整合通訊協定並不實用。 您想要整合之每個應用程式的 API 是潛在的 Web 服務。
• 您可以為其他 Web 應用程式和 Web 服務開發人員提供基礎結構服務 (「管管」) ，例如身分識別服務或計費服務。 您可以公開 API 作為 Web 服務，而不是為每個用戶端平臺建置自訂 API 程式庫。

當然，基於上述任何原因，您也必須考慮您的服務是否有足夠的潛在客戶端數目，以證明實作和操作的成本。

我們也快速瞭解建置範例服務以教育一般開發人員物件時，還有一些其他考慮。 首先，商務案例不應該需要對特定產業有廣泛的知識。 其次，我們希望您可以在自己的電腦上安裝和執行範例。 第三，許多有趣的案例都需要一或多個資料存放區或摘要。 傳送範例原始程式碼時有許多問題，示範如何存取我們不擁有的資料來源。 而且我們沒有 任何 資料來源...至少不要說我們要放棄樣本。

這讓我們離開線上銀行、控制家庭數位視訊錄製器、檢查正式發行前小眾測試版狀態或每日 Comics 伺服器等案例， 我們開始思考 MSDN 可以提供 (實際服務的 Web 服務類型，而不是範例) 。 人們真正喜歡的一個概念是追蹤他們想要再次尋找的 MSDN 文章，不論他們用來存取 MSDN 的電腦為何。 這可讓我們瞭解伺服器端我的最愛。

Vision， Rev 1

一旦我們大致瞭解我們想要建置的服務，我們就會建置其周圍的商務案例：

• 我們正在尋找擴充用戶端基底的方法，以用於 Web 開發實務，並產生一般的營收資料流程。 我們相信我們可以藉由提供網站想要使用的高品質 Web 服務來達成這兩個目標。 由於 Web 服務是新的概念，因此我們覺得潛在客戶必須確信他們可以在我們的服務上參與其業務。 因此，我們需要一個可：
  • 為潛在客戶的網站提供明顯的價值。
  • 不提供任務關鍵性服務。
  • 顯示開發和作業實務的品質。
  • 可以以合理的成本實作和部署給我們。

以下是我們對於專案願景的第一個剪下：

• The server-side Favorites Service will enable Web surfers to store their favorite links in a safe, secure, central location, so their favorites are accessible anywhere, any time. We will offer the service free of charge to all users; however because we want to protect each user's privacy, users will need to be authenticated to access their favorites. By using the service through a client Web site, users agree that we may use their favorite lists after all personally identifying information is stripped from the data. 在此專案的第二階段中，我們會將其他服務授權給網站。 例如：
  • 要為其網站建立書簽之頁面的統計資料。
  • 根據所有使用者最愛的親和性分析，建議的連結。

從技術觀點來看，此案例看起來會解決我們從客戶聽到的許多問題。 商務邏輯看起來並不容易實作，或太難以向讀者解釋。 但是，一旦寫下視覺聲明供每個人查看，一些大紅色旗標就會啟動：

• 我們需要全域使用者識別配置，這是一個通用配置，足以讓網站能夠將使用者識別碼傳遞至我們的服務。
• 當要求來自網站而不是直接從使用者時，我們會如何驗證使用者？ 聽起來就像我們需要委派，或者我們需要信任網站，才能在使用者實際使用其網站時代表使用者提出要求。
• 是否允許任何網站擷取從另一個網站新增的使用者最愛？ 如果是，我們想要讓任何網站使用我們的服務，還是應該限制對授權網站的存取？ 讓任何網站都能存取 [我的最愛] 服務中儲存的任何和所有資料，而不需要使用者任何輸入，就好像是龐大的隱私權問題。
• 同樣地，如果我們的 Web 服務提供更新方法來維護使用者最愛的資訊，該怎麼辦。 是否允許一個網站修改從另一個網站新增的使用者我的最愛？
• 如果使用者發現我們正在對從多個網站收集的資料進行親和性分析之類的動作，使用者是否不會發出訊息？ 他們甚至會如何知道這些網站正在使用我們的服務？ 我們需要執行類似動作，要求終端使用者向我們的服務註冊，並在任何網站存取其資料之前設定其隱私權喜好設定？ 使用者如何知道要向我們註冊？

或許有一些額外的研究順序。

Vision， Rev 2

檢閱有關使用者隱私權的所有專案之後，我花了數小時的時間，與 Microsoft 的公司隱私權群組成員討論我們的服務可能啟用的案例，以及隱私權影響。 我在備忘稿頁面之後進行頁面，但仍有一些開放式問題。 但是，一個網站可以從隱私權觀點存取或修改從另一個網站新增的資料，聽起來很不小心。 這不表示不應該允許他們，只是很難撰寫精確但可瞭解的隱私權原則來涵蓋這些案例，而使用者可能不熟悉案例。

我們也對驗證問題進行一些初步研究。 目前，在中間有應用程式時，全域識別和驗證使用者的方式實際上並不好。 當使用者透過瀏覽器與網站互動時，Microsoft Passport 可正常運作。 但網站沒有安全的方式，無法將使用者的認證傳遞至另一個網站。 Passport 的單一登入功能為何，當使用者移至另一個已啟用 Passport 的網站時，不需要重新輸入其使用者名稱和密碼？ 這使用用戶端重新導向。 我們的 Web 服務永遠不會直接與使用者的機器交談。

根據此初步研究，我們決定分階段實作我的最愛。 這可讓我們有更多時間來找出隱私權影響，而且在去年的 PDC 中提及數次的身分識別 Web 服務，在我們需要全域身分識別配置時可以使用。

我們的修訂願景看起來像這樣：

• 我們將在 CY2001 期間實作及部署 Favorites Web Service，讓使用者能夠將網站中選取的頁面加入書簽，以供稍後存取。 這些我的最愛將由我的最愛服務儲存，因此可從使用者正在使用的任何電腦或裝置存取它們。
• 我的最愛服務將用來向潛在客戶公告，因此必須是高可用性、可調整且安全的服務，以展示公司對品質和個人隱私權的承諾。

清除者可能會認為這太長，無法成為視覺聲明。 不過，重要事項是每個人都瞭解它，不論您想要呼叫它。

我們已定義如下的階段：

• 在階段第一階段中，我們將實作並部署我的最愛 Web 服務，此服務可授權給網站開發人員，以在幕後使用來管理客戶我的最愛。 (實際上，每個授權者都有使用者 favorites.) 的私人資料存放區，我們也提供範例，示範如何將我的最愛服務整合到網站中。 服務與範例將于 2001 年 3 月 1 日提供授權。 我們的目標是在 2001 年 3 月 1 日將服務授權給每個月大約 10，000 名新使用者五到 10 個網站。 (我們認為這是可管理成長率，因為我們目前的員工.)
• 在階段 2 中，我們將實作 Internet Explorer 和 Netscape Navigator 的瀏覽器延伸模組，讓使用者能夠安全地管理其對任何網站的我的最愛，就像今天管理用戶端我的最愛一樣。 我們也會實作及部署網站使用者可用來管理其我的最愛、閱讀我們的隱私權聲明、設定使用者設定檔選項，以瞭解其個人資訊的使用方式，以及下載瀏覽器延伸模組。 瀏覽器延伸模組和網站將于 2001 年 5 月 1 日傳遞。 我們的目標是每月達到 1，000 個新的使用者。
• 在階段三中，我們將擴充 [我的最愛 Web 服務]，讓使用者能夠透過瀏覽器增益集或我的最愛網站直接 (看到他們儲存的兩個我的最愛，) ，以及透過 [我的最愛服務] 授權儲存的我的最愛。 授權者可以選擇顯示特殊標誌，讓使用者知道正在使用諮詢我的最愛服務 (，因此這些我的最愛也可透過瀏覽器增益集或我的最愛網站存取) 。 授權者也可以在幕後繼續使用我的最愛服務，在此情況下，透過瀏覽器增益集或我的最愛網站儲存的我的最愛將無法透過瀏覽器增益集或我的最愛網站取得。 第三階段將于 2001 年 6 月 1 日提供。
  階段三提供未來 Web 服務的基礎。 例如，如果使用者流覽網頁，網站可能會顯示其他使用者喜歡該頁面的網頁清單。 網站會從 Web 服務擷取頁面清單。 我們尚未決定是否要實作這種類型的分析服務。

備妥之後，我們就可以充分利用其餘的視覺檔。

下一個步驟是定義一些使用者設定檔。 當您定義 Web 服務專案願景時，請務必仔細思考所有使用者。 我們在構想階段識別的使用者類別如下：

• 使用者— 任何使用網頁瀏覽器流覽網站的任何人。
• 授權者 -- 任何使用我的最愛服務的網站。
• 授權開發人員— 開發人員建置授權者的網站。
• 授權操作員- 授權者的網站操作員。
• 操作員-負責操作我的最愛服務的人員。

您可以在 [我的最愛] 視覺檔中閱讀此資料行隨附的完整使用者設定檔。 結果我們錯過了幾個類別：授權的經理和經理。 當我們開始思考報告需求時，這些已裁剪。 我們也應該將測試人員分割成個別的類別。 此清單應該為大部分的 Web 服務專案提供良好的起點。

我們也花一些時間思考商務目標和設計目標。 其中一個主要問題是：為何要建置 Web 服務？ 您是否嘗試獲利？ 嘗試簡化商務程式嗎？ 或者，還有其他專案嗎？ 無論您決定什麼，都可能會對您的需求造成影響。 例如，我的最愛服務的主要目標是：

• 展示我們對品質產品的承諾。
• 避免因為不可靠的服務、安全性問題或個人隱私權問題而造成不正確的按下。

此目標群組合在我們的服務上新增了大量的需求，特別是在授權領域，以及 (延展性、可用性等功能需求。) 。 但獲利是這個專案的完整非目標。 如果是目標，我們的許多授權需求會以一些不同方式推出。

從設計觀點來看，您應該考慮使用者隱私權、安全性和其他非功能性需求的整體原理。 您也應該考慮世界各地的用戶端是否會使用您的 Web 服務，以及這表示全球化和當地語系化的意思。 例如，我們的幾個設計目標如下：

• 提供全球解決方案。 服務及所有支援的應用程式都必須全球化。
• 提供可靠、安全的服務。 服務必須具有高可用性、不得遺失資料，而且只能允許授權的使用者存取。

您可以在我的最愛視覺檔中找到其餘業務目標和設計目標。

結論

如果專案小組和客戶已同意整體目標、目標和範圍，則當您使用專案小組完成專案時，一定會比較容易瞭解。 即使您認為只是將 Web 服務前端新增至現有的網站，也值得花一些時間來撰寫視覺檔。 為何要新增前端？ 您預期會使用哪一個？ 您的作業人員未預期將額外負載放在您的網站上有多少額外負載？

撰寫我的最愛視覺檔是一個寶貴的練習。 如果沒有，我們至少會錯過最後在功能規格中最後的一半需求。例如，在遊戲稍後之前，我們可能不會辨識隱私權和安全性問題。 視覺檔也會為我們執行其他動作。 它提供我們評估功能要求和優先順序需求的標準。 本檔會提醒我們未來階段要執行的動作，我們可以在範例設計中考慮該作業，因此我們不需要完全重寫未來的工作。

下周，我們將更詳細地查看這裡所述的隱私權問題。 我會讓您知道我從公司隱私權群組學到的內容、討論我們延遲的困難問題，以及討論在階段一中的隱私權問題，以及這些問題對設計與實作有何影響。

接著，看到您！

Mary Kirtland 是 MSDN Web 服務指引小組的架構師，她負責撰寫程式碼、測試或作業，包括嘗試讓規格保持最新狀態、記下小組在 MSDN 文章中學到的所有內容、在評論期間詢問令人疑慮的問題，以及訂購午餐。