Aracılığıyla paylaş

Vizyon Tanımlama

  • Makale

 

Mary Kirtland
Microsoft Corporation

10 Ocak 2001, Şubat

Geçen haftanın sütununda Web Hizmetleri Kılavuzu ekibini ve örnek Web Hizmetlerini oluşturma, dağıtma ve çalıştırma misyonumuzu, aynı işlemi yaparken dikkate almanız gereken sorun türlerini göstermek üzere sundum. Ayrıca ilk örnek projemiz olan Sık Kullanılanlar Hizmeti'ni de tanıttım.

Yorumlarınız ve geri bildirimleriniz için herkese teşekkürler. Ortaya çıkardığınız sorunları takip ediyoruz, o yüzden gelmeye devam edin!

Birisi örneği yayınlamanın neden üç ay süreceğini ve fikri duyurmadan önce neden bu örneği kullanmaya başlamadığımız soruldu. Aslında, son iki aydır Sık Kullanılanlar üzerinde neredeyse tam zamanlı çalışıyoruz. İşlevselliklerin çoğu, iyi, işlevseldir... ancak her şey güzel ve düzgün bir şekilde kendi makinelerinize yükleyebileceğiniz veya İnternet üzerinden deneyebileceğiniz bir örneğin içinde paketlenmiş olmadan önce yapmanız gereken biraz iş var. Ayrıca örnek kaynaklarımızla birlikte göndermek istediğimiz tüm makaleleri yazmak, teknik inceleme yapmak, düzenlemek ve işlemek biraz zaman alır. Bu nedenle üç aylık proje döngülerini hedefliyoruz. Şubat ayında Sık Kullanılanlar'ın ilk sürümünü çıkarabilmemiz için parmaklarımızı çapraz tutuyoruz. (Bunu yazarken ekip, yayın tarihiyle ilgili daha iyi bir tahmin elde etmek için bir zamanlama alıştırmasından geçiyor.)

Bazı açıklamalar, bu örneği geliştirmek için .NET Framework kullandığımızı da varsayar. Böyle bir durum söz konusu olmayabilir. İş için en uygun teknolojileri kullanacağız. Ve en iyisi her zaman teknik açıdan daha üstün, kullanımı kolay veya haberlerin çoğu anlamına gelmez. Ne seçerseniz seçin, nedenini size anlatacağız ve kullanmayı denediğimizde karşılaştığımız sorunları size anlatacağız.

Bu hafta, ekibimizin Sık Kullanılanlar Hizmeti'ni oluştururken karşılaştığı sorunları incelemeye başlayacağız. Oldukça fazla kapsam var, ancak başlangıçtan başlayacağız: projenin hedeflerini ve hedeflerini belirleme.

Başlarken

Microsoft Çözüm Çerçevesi işlem modelinde, herhangi bir projenin ilk aşaması, öngörülen aşamadır. Proje ekibi ve müşteriler, öngörülen aşama boyunca projenin hedeflerine ve kısıtlamalarına ilişkin üst düzey bir görünüm oluşturur. Bu aşamadan elde edilen birincil teslim edilebilir, iş sorununun analizini, ürüne yönelik hedeflerin açıklamasını, çözüm kavramının ana hattını, ürün kullanıcılarının profillerini, tasarım hedeflerini ve projenin kapsamının tanımını içeren bir vizyon belgesidir. Öngörülen aşama, vizyon/kapsam onaylı kilometre taşında doruğa çıkar.

Ekibimiz alışılmışın dışında bir başlangıç noktasından başladı: Web Hizmeti yazmak istediğimizi biliyorduk, ancak aklımızda belirli bir sorun etki alanı yoktu ve kullanmak zorunda olduğumuz mevcut uygulamalarımız da yoktu. Bu nedenle yapmamız gereken ilk şey ölçeklenebilir, güvenilir vb. bir şey oluşturmayı gerekçelendirebilecek makul derecede gerçekçi bir iş senaryosu bulmaktı. Web Hizmeti.

Bir odadaki bir grup kişiyi kilitleyerek ve rehberlik için iyi konular oluşturacak potansiyel işletmelere veya sektörlere, hizmetlere ve teknik sorunlara beyin fırtınası yaparak işe koyulduk. Bu arada, Web Hizmetleri oluşturmak istemeniz için bazı nedenler bulduk:

  • Son kullanıcıların veya diğer işletmelerin kullanmak istediği zamana duyarlı veya parametreli bir veri kaynağısınız. Veriler sık sık değişmiyorsa ve istemciler neredeyse her zaman tüm verileri istiyorsa, web sitenize bir XML belgesi göndermeniz daha iyi olabilir. Ancak istemciler verilerinize yönelik sorgular yürütmek isterse, Web Hizmeti çok mantıklıdır. İstemcilere veri göndermek istiyorsanız abonelik ve bildirim işlemleri de olası Web Hizmetleridir.
  • Diğer işletmelerin kendilerini uygulayamadıklarına veya uygulamak istemeyebilecekleri algoritmalar uygularsınız. Bu durumda, her algoritma olası bir Web Hizmetidir: İstemciler verileri geçirir, yanıtla yanıt verirsiniz.
  • Daha üst düzey bir hizmet sağlamak için diğer birkaç hizmeti toplarsınız. Bu durumda istemciler hizmetinizi kullanır çünkü istedikleri bilgilerin birleşimini sağlar ve mevcut hizmetleri birleştirme çalışmalarını kaydeder.
  • İş süreçlerinizi iş ortaklarıyla tümleştirmek istiyorsunuz. Kurumsal bir sınır boyunca uzanan iş sürecinin her adımı, olası bir Web Hizmeti veya Web Hizmeti işlemidir.
  • Heterojen ve/veya coğrafi olarak dağıtılmış bir kurumsal mimariniz vardır ve bu mimaride uygulama tümleştirmesi için özel ağlar veya sıkı bir şekilde bağlanmış protokoller kullanmak pratik değildir. Tümleştirmek istediğiniz her uygulamanın API'si olası bir Web Hizmetidir.
  • Diğer Web uygulaması ve Web Hizmeti geliştiricileri için kimlik hizmeti veya faturalama hizmeti gibi altyapı hizmetleri ("tesisat") sağlarsınız. Her istemci platformu için özel API kitaplıkları oluşturmak yerine API'nizi Web Hizmeti olarak kullanıma sunabilirsiniz.

Elbette, bu nedenlerden herhangi biri nedeniyle, hizmetinizi uygulama ve çalıştırma maliyetlerini gerekçelendirmek için hizmetiniz için yeterli sayıda potansiyel istemci olup olmadığını da düşünmeniz gerekir.

Ayrıca, genel bir geliştirici kitlesini eğitmek için örnek hizmetler oluştururken dikkat edilmesi gereken başka noktalar olduğunu da hızlıca fark ettik. İlk olarak, iş senaryoları belirli bir sektör hakkında kapsamlı bilgi gerektirmez. İkincisi, örnekleri kendi makinelerinize yükleyip çalıştırabilmenizi istiyoruz. Üçüncüsü, birçok ilginç senaryo için bir veya daha fazla veri deposu veya akış gerekir. Sahip olmadığımız veri kaynaklarına nasıl erişildiğini gösteren örnek kaynak kodu gönderme konusunda birçok sorun vardır. Ve hiçbir veri kaynağımız yok ... En azından bir örnekle verme özgürlüğümüz yok.

Bu da bizi çevrimiçi bankacılık, ev dijital video kaydedicisini kontrol etme, uçuş durumunu denetleme veya günlük çizgi roman sunucusu gibi senaryolardan bir altyapı hizmetinin hatlarında daha fazlasını yapmaya yönlendirdi. MSDN'nin sağlayabilecekleri Web Hizmeti türlerini (örnekler değil gerçek hizmetler) düşünmeye başladık. İnsanların gerçekten beğendiği bir fikir, MSDN'ye erişmek için kullandıkları makineden bağımsız olarak yeniden bulmak istedikleri MSDN makalelerini takip etmenin bir yoluydu. Bu da bizi sunucu tarafı sık kullanılanlar fikrine yönlendirdi.

Vizyon, Rev 1

Oluşturmak istediğimiz hizmet hakkında kabaca bir fikir edindikten sonra, bunun etrafında bir iş senaryosu oluşturmuştuk:

  • Web geliştirme uygulamamız için istemci tabanımızı genişletmenin ve düzenli bir gelir akışı oluşturmanın yollarını arıyoruz. Web sitelerinin kullanmak isteyeceği yüksek kaliteli Web Hizmetleri sağlayarak her iki hedefe de ulaşacağımıza inanıyoruz. Web Hizmetleri yeni bir kavram olduğundan, potansiyel müşterilerin hizmetlerimizin bir parçası olabileceklerine ikna olmaları gerektiğini hissediyoruz. Bu nedenle bir teaser Web Hizmeti gerekir:
    • Potansiyel müşterilerin Web sitelerine bariz bir değer sunar.
    • Görev açısından kritik bir hizmet sağlamaz.
    • Geliştirme ve operasyon uygulamalarımızın kalitesini gösterir.
    • Makul maliyetle uygulanabilir ve dağıtılabilir.

İşte proje vizyonumuzun ilk kesimi:

  • 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. Bu projenin ikinci aşamasında, Web sitelerine ek hizmetler lisanslayacağız. Örnek:
    • Sitelerinden hangi sayfaların yer işaretine yer işareti belirlendiğiyle ilgili istatistikler.
    • Tüm kullanıcı sık kullanılanlarının benzite analizini temel alan önerilen bağlantılar.

Teknik açıdan bakıldığında, bu senaryo müşterilerden aldığımız soruların çoğunu ele alacak gibi görünüyordu. İş mantığının uygulanması çok zor görünmüyordu veya okuyucularımıza açıklamak çok zor görünmüyordu. Ancak görüntü bildirimi herkesin baksın diye yazıldıktan sonra bazı büyük kırmızı bayraklar çıktı:

  • Web sitelerinin kullanıcı tanımlayıcısını hizmetimize iletebileceği kadar yaygın bir şema olan genel bir kullanıcı tanımlama şemasına ihtiyacımız olacaktır.
  • İstekler doğrudan son kullanıcı yerine bir Web sitesinden geldiğinde son kullanıcının kimliğini nasıl doğrularız? Temsilci seçmemiz gerekiyor gibi görünüyor veya Web sitelerine yalnızca son kullanıcı kendi sitesini gerçekten kullandığında kullanıcı adına istekte bulunmaları için güvenmemiz gerekir.
  • Herhangi bir Web sitesinin, başka bir Web sitesinden eklenen son kullanıcının sık kullanılanlarını almasına izin verilmeli mi? Bu durumda herhangi bir Web sitesinin hizmetimizi kullanmasına izin vermek mi, yoksa lisanslı sitelere erişimi kısıtlamak mı istiyoruz? Herhangi bir sitenin, son kullanıcıdan herhangi bir giriş yapmadan Sık Kullanılanlar Hizmeti'nde depolanan herhangi bir ve tüm verilere erişmesine izin vermek büyük bir gizlilik sorunu gibi görünüyor.
  • Benzer şekilde, Web Hizmetimiz kullanıcının sık kullanılan bilgilerini korumak için güncelleştirme yöntemleri sağladıysa ne olur? Bir Web sitesinin, başka bir Web sitesinden eklenen son kullanıcının sık kullanılanlarını değiştirmesine izin verilsin mi?
  • Birden çok Web sitesinden toplanan verilerinde benzim analizi gibi şeyler yaptığımızı öğrenen son kullanıcılar bağırıp çağırmaz mı? Bu sitelerin hizmetimizi kullandığını nereden bilecekler? Herhangi bir sitenin verilerine erişebilmesi için son kullanıcının hizmetimize kaydolmasını ve gizlilik tercihlerini ayarlamasını zorunlu kılabilir miyiz? Son kullanıcı bize kaydolmayı nasıl bilir?

Belki de bazı ek araştırmalar sıralandı.

Vizyon, Rev 2

Kullanıcı gizliliği hakkında bulabildiğim her şeyi gözden geçirdikten sonra, hizmetimizin etkinleştirebileceği senaryoları ve gizliliğin etkilerini tartışarak Microsoft'un Kurumsal Gizlilik Grubu'nun bir üyesiyle birkaç saat geçirdim. Not sayfasından sonra sayfa aldım ve hala birkaç açık sorun vardı. Ancak bir sitenin başka bir siteden eklenen verilere erişebildiği veya bunları değiştirebildiği senaryolar gizlilik açısından oldukça riskli geldi. Bu, izin verilmemesi gerektiğini değil, yalnızca bu senaryoları kapsayacak doğru ancak anlaşılır bir gizlilik ilkesi yazmanın daha zor olduğunu ve son kullanıcıların senaryolardan rahat olmayabileceğini söylemek değildir.

Kimlik doğrulama sorunuyla ilgili bazı ön araştırmalar da yaptık. Ortada bir uygulama olduğunda İnternet üzerinden kullanıcıları genel olarak tanımlamanın ve kimliklerini doğrulamanın gerçekten iyi bir yolu yoktur. Bir kullanıcı tarayıcı aracılığıyla bir Web sitesiyle etkileşime geçtiğinde Microsoft Passport harika çalışır. Ancak, Web sitesinin kullanıcının kimlik bilgilerini başka bir Web sitesine geçirmesinin güvenli bir yolu yoktur. Kullanıcıların başka bir Passport özellikli siteye geçtiklerinde kullanıcı adlarını ve parolalarını yeniden girmeleri gerekmeyen Passport'un tek oturum açma özelliğine ne olacak? Bu, istemci tarafı yeniden yönlendirmelerini kullanır. Ayrıca Web Hizmetimiz hiçbir zaman doğrudan son kullanıcının makinesiyle konuşmaz.

Bu ön araştırmaya dayanarak Sık Kullanılanlar'ı aşamalar halinde uygulamaya karar verdik. Bu, gizliliğin etkilerini sıralamak için bize daha fazla zaman verir ve belki de geçen yılın PDC'sinde birkaç kez bahsedilen Kimlik Web Hizmeti, genel kimlik şemasına ihtiyacımız olan zamana kadar kullanılabilir.

Gözden geçirilmiş vizyonumuz şöyle görünür:

  • CY2001 sırasında, son kullanıcıların daha sonra erişmek üzere seçili sayfalara Web sitelerinden yer işareti eklemesini sağlayacak bir Sık Kullanılanlar Web Hizmeti uygulayacak ve dağıtacağız. Bu sık kullanılanlar Sık Kullanılanlar Hizmeti tarafından depolanır, böylece son kullanıcının kullandığı herhangi bir makineden veya cihazdan erişilebilir.
  • Sık Kullanılanlar Hizmeti potansiyel müşterilere reklam vermek için kullanılacaktır ve bu nedenle firmanın kalite ve kişisel gizlilik taahhüdünü gösteren yüksek oranda kullanılabilir, ölçeklenebilir, güvenli bir hizmet olmalıdır.

Purists bunun bir vizyon deyimi olamayacak kadar uzun olduğunu iddia edebilir. Ancak önemli olan herkesin anlamasıdır.

Aşamaları şöyle tanımladık:

  • Birinci aşamada, müşterilerinin sık kullanılanlarını yönetmek için arka planda kullanmak üzere Web sitesi geliştiricilerine lisanslanabilen bir Sık Kullanılanlar Web Hizmeti uygulayacak ve dağıtacağız. (Her lisans sahibi, kullanıcı sık kullanılanlarından oluşan özel bir veri deposuna sahiptir.) Ayrıca Sık Kullanılanlar Hizmeti'nin bir Web sitesiyle nasıl tümleştirileceğini gösteren bir örnek de sağlayacağız. Hizmet ve örnek 1 Mart 2001'e kadar lisanslama için kullanıma sunulacaktır. Hedefimiz, hizmeti 1 Mart 2001'e kadar ayda yaklaşık 10.000 yeni son kullanıcıyı temsil eden beş ila 10 siteye lisans vermektir. (Mevcut personelimiz dikkate alındığında bunun yönetilebilir bir büyüme oranı olduğuna inanıyoruz.)
  • İkinci aşamada, Internet Explorer ve Netscape Navigator için tarayıcı uzantılarını uygulayacağız. Bu uzantılar, son kullanıcılara herhangi bir Web sitesinde sık kullanılanlarını yönetmek için güvenli ve güvenli bir yol sağlar. Ayrıca, son kullanıcıların sık kullanılanlarını yönetmek, gizlilik bildirimimizi okumak, kişisel bilgilerinin kullanımıyla ilgili kullanıcı profili seçeneklerini ayarlamak ve tarayıcı uzantılarını indirmek için kullanabileceği bir Web sitesi uygulayıp dağıtacağız. Tarayıcı uzantıları ve Web sitesi 1 Mayıs 2001'e kadar teslim edilecek. Hedefimiz ayda 1.000 yeni son kullanıcıya ulaşmaktır.
  • Üçüncü aşamada, son kullanıcıların doğrudan kaydettikleri sık kullanılanları (tarayıcı eklentisi veya Sık Kullanılanlar Web sitesi aracılığıyla) ve Sık Kullanılanlar Hizmeti lisansları aracılığıyla depolanan sık kullanılanları görebilmesi için Sık Kullanılanlar Web Hizmeti'ni genişleteceğiz. Lisans verenler, son kullanıcıların Danışmanlık Sık Kullanılanlar Hizmeti'nin kullanıldığını bilmesini sağlayan özel bir logo görüntüleme seçeneğine sahip olur (bu nedenle bu sık kullanılanlara tarayıcı eklentisi veya Sık Kullanılanlar Web sitesi üzerinden de erişilebilir). Lisans verenler arka planda Sık Kullanılanlar Hizmeti'ni kullanmaya devam edebilir. Bu durumda, bu site aracılığıyla depolanan sık kullanılanlar tarayıcı eklentisi veya Sık Kullanılanlar Web sitesi aracılığıyla kullanılamaz. Üçüncü aşama 1 Haziran 2001'e kadar teslim edilecek.
    Üçüncü aşama, gelecekteki Web Hizmetleri için bir temel sağlar. Örneğin, bir kullanıcı bir Web sayfasını ziyaret ederse, site, sayfayı beğenen diğer kişilerin de beğendiği Web sayfalarının listesini görüntüleyebilir. Web sitesi, bir Web Hizmetinden sayfa listesini alır. Bu tür profil oluşturma hizmetinin uygulanıp uygulanmayacağımıza henüz karar vermedik.

Bunu yaptığımızda, Görüntü İşleme belgesinin geri kalanının etini yerle bir edebiliriz.

Sonraki adım, bazı kullanıcı profillerini tanımlamaktı. Bir Web Hizmeti projesinin vizyonunu tanımlarken tüm kullanıcılarınızın kim olduğu hakkında dikkatli düşünmeniz önemlidir. Tasdik aşamasında belirlediğimiz kullanıcı kategorileri şunlardır:

  • Son Kullanıcılar: Web sitelerini ziyaret etmek için Web tarayıcısı kullanan herkes.
  • Lisans verenler— Sık Kullanılanlar Hizmeti'ni kullanan bir Web sitesine sahip tüm işletmeler.
  • Lisans Alan Geliştiriciler: Lisans alan bir kullanıcının Web sitesini oluşturan geliştiriciler.
  • Lisans Sahibi İşleçleri: Lisans alan bir kullanıcının Web sitesinin işleçleri.
  • İşleçler— Sık Kullanılanlar hizmetini çalıştırmakla sorumlu kişiler.

Bu sütuna eşlik eden Sık Kullanılanlar görüntü işleme belgesinde kullanıcı profillerinin tamamını okuyabilirsiniz. Birkaç kategoriyi kaçırdığımız ortaya çıktı: lisans sahiplerinin yöneticileri ve yöneticileri. Raporlama gereksinimlerini düşünmeye başladığımızda bunlar kırpılmış. Test edicileri de ayrı bir kategori olarak ayırmamız gerekir. Bu liste çoğu Web Hizmeti projesi için iyi bir başlangıç noktası sağlamalıdır.

Ayrıca iş hedefleri ve tasarım hedefleri hakkında düşünmek için biraz zaman harcadık. Başlıca sorulardan biri şudur: Web Hizmetini neden oluşturuyorsunuz? Para kazanmaya mı çalışıyorsun? İş süreçlerini kolaylaştırmaya mı çalışıyorsunuz? Ya da tamamen başka bir şey? Kararınız ne olursa olsun, gereksinimleriniz üzerinde büyük olasılıkla bir etkisi olacaktır. Örneğin, Sık Kullanılanlar Hizmeti'nin birincil hedefleri şunlardır:

  • Kaliteli ürünlere olan bağlılığımızı sergileyin.
  • Güvenilir olmayan hizmet, güvenlik sorunları veya kişisel gizlilik sorunları nedeniyle kötü baskılardan kaçının.

Bu hedeflerin birleşimi, özellikle lisanslama ve yetenek gereksinimleri (ölçeklenebilirlik, kullanılabilirlik vb.) alanlarında hizmetimize önemli sayıda gereksinim ekledi. Ancak para kazanmak, bu proje için tam bir hedef değildir. Bu bir hedef olsaydı, lisanslama gereksinimlerimizin çoğu biraz farklı bir şekilde ortaya çıkar.

Tasarım açısından bakıldığında, kullanıcı gizliliği, güvenlik ve diğer işlevsel olmayan gereksinimler hakkındaki genel felsefenizi düşünmeniz gerekir. Ayrıca, dünyanın her yanındaki istemcilerin Web Hizmetinizi kullanıp kullanmayacağını ve bunun genelleştirme ve yerelleştirme hakkında ne anlama gelir olduğunu da göz önünde bulundurmalısınız. Örneğin, tasarım hedeflerimizden birkaçı şunlardır:

  • Dünya çapında bir çözüm sunun. Hizmet ve tüm destekleyici uygulamalar genelleştirilmelidir.
  • Güvenilir ve güvenli bir hizmet sunun. Hizmetin yüksek oranda kullanılabilir olması, verileri kaybetmemesi ve yalnızca yetkili kullanıcıların erişimine izin vermesi gerekir.

İş hedeflerimizin ve tasarım hedeflerimizin geri kalanını Sık Kullanılanlar Görüntü İşleme belgesinde bulabilirsiniz.

Sonuç

Proje ekibi ve müşterileriniz genel hedefleri, hedefleri ve kapsamı önceden kabul ettiyse, bir projeyle işiniz bittiğinde bunu bilmek her zaman daha kolaydır. Var olan bir Web sitesine yalnızca bir Web Hizmeti ön ucu eklediğinizi düşünseniz bile, bir görüntü işleme belgesi yazmak için zaman ayırmaya değer. Neden ön ucu ekliysiniz? Bunu kimin kullanmasını bekliyorsunuz? Bu, sitenize operasyon çalışanlarınızın beklemedikleri ne kadar ek yük koyacak?

Sık Kullanılanlar için vizyon belgesini yazmak bizim için değerli bir alıştırmaydı. Bu olmasaydı, işlevsel özelliklerimizde sona eren gereksinimlerin en az yarısını kaçıracaktık. Örneğin, oyunun çok daha ilerisine kadar gizlilik ve güvenlik sorunlarını muhtemelen fark etmezdik. Görüntü İşleme belgesi bizim için başka şeyler de yapar. Özellik isteklerini değerlendirmek ve gereksinimleri önceliklendirmek için bize bir yardstick sağlar. Belge, gelecek aşamalarda ne yapmak istediğimizi anımsatır; bunu örnek tasarımda hesaba ekleyebiliriz, böylece işleri tamamen yeniden yazmamız gerekmez.

Gelecek hafta burada bahsedilen gizlilik sorunlarına daha ayrıntılı bir şekilde göz atacağız. Kurumsal Gizlilik Grubumuzdan öğrendiklerimizi size bildiririm, ertelediğimiz zor sorunlar hakkında konuşur, birinci aşamada kalan gizlilik sorunlarını ve bunların tasarımımız ve uygulamamız üzerinde nasıl bir etkisi olduğunu tartışırım.

Görüşürüz o zaman!

Mary Kirtland , MSDN Web Hizmetleri Rehberliği ekibinin mimarıdır ve teknik özellikleri güncel tutmaya çalışmak, ekibin MSDN makalelerinde öğrendiği her şeyi yazmak, incelemeler sırasında rahatsız edici sorular sormak ve öğle yemeği sipariş etmek de dahil olmak üzere kodlama, test veya operasyonlar dışında her şeyi yapar.