Hizmet normalleştirme modeli - Service normalization pattern

Hizmet normalleştirme bir tasarım deseni, içinde uygulandı hizmet odaklılık tasarım paradigması, kimin uygulaması bu hizmetleri sağlar[1] aynı hizmet envanterinin parçası olan[2] herhangi bir yedekli işlevsellik içermez.[3] Bu tasarım deseni yaratmaya vurgu yapıyor normalleştirilmiş hizmetler, bir tablodaki tüm özniteliklerin yalnızca tablo tarafından tanımlanan varlıkla ilişkili olduğu ve varlıkla doğrudan ilişkili olmayan özniteliklerin ya yeni bir tabloya ya da mevcut bir tabloya konulduğu bir veritabanında normalleştirilmiş tablolar oluşturmaya çok benzer. bu özniteliğin bağlamına uyar.

Gerekçe

Farklı ekipler, çeşitli iş süreçlerini otomatikleştirmenin bir parçası olarak birden çok hizmet sunduğunda, bu hizmetlerden bazılarının yinelenen işlevselliğe sahip olma olasılığı vardır. Örneğin, aynı eski sistemle mesaj alışverişi yapması gereken iki farklı iş sürecinin iki farklı ekip tarafından otomasyonu, hizmetlerle mesaj alışverişini sağlamak için oluşturulan bir sarmalayıcı hizmetinin iki farklı sürümüyle sonuçlanabilir. İşlevsellikteki bu örtüşme, kolayca hizadan çıkabildikleri için, belirli bir işlevselliğin sağlanması için resmi hizmet olarak hangi hizmetin ilan edileceği ve fazlalık hizmetlerin bakımı gibi başka sorunlara yol açabilir.

Aynı hizmet envanterinin bir parçası olarak herhangi bir yinelenen işlevsellik içermeyen hizmetler sunmak için, her hizmetin işlevsel sınırının, başka herhangi bir hizmetle çelişmemesi için dikkatlice oluşturulması gerekir. Hizmet Normalleştirme[4] tasarım modeli, herhangi bir işlevsel yineleme olmadan aerodinamik hizmetler içeren hizmet envanterleri oluşturmak için yönergeler sağlar.[5] Normalleştirilmiş hizmetler yaratarak, hizmetin amacı da potansiyel tüketiciler için daha net hale gelir.[6]

Kullanım

Diyagram A
Diyagram A
Bir hizmet envanteri planının yokluğunda, İş Süreci 2'nin otomasyonu, İş Süreci 1'i otomatikleştirirken daha önce oluşturulan kırmızı hizmetle işlevselliğinin çoğunu paylaşan kırmızı hizmetin yaratılmasıyla sonuçlandı.
Diyagram B
Diyagram B
Bir hizmet envanteri taslağının oluşturulması, iki kırmızı hizmetin tek bir kırmızı hizmette birleşmesi ile sonuçlanır ve kırmızı hizmet bağlamına girmeyen herhangi bir işlev, yeni turuncu hizmete eklenir.

Bu tasarım modelinin uygulanması, tüm hizmetlerin işlevsel bağlamları hakkında bilgi gerektirir, çünkü ancak o zaman hizmetlerin herhangi bir örtüşen işlevsellik içermediği garanti edilebilir. Bu, hizmet modelleri, yani herhangi bir gerçek hizmet sözleşmesi içermeyen, ancak sağlayabilecekleri işlevsellik türü hakkında yüksek düzeyde ayrıntılara sahip hizmetler oluşturarak elde edilir. Hizmet modelleri oluşturmak için aşağıdaki faaliyetlerin gerçekleştirilmesi gerekir:

  1. İş sürecini, belirli bir hizmet envanterinin sınırlarına düşen ayrı adımlara ayırın.
  2. Her adımı bir hizmetin ayrı bir işlevine atayın
  3. Yukarıdaki işlevselliğin başka bir hizmet tarafından zaten sağlanmadığından emin olun.
  4. Bir hizmet, yeni gerekli işlevselliğin bir parçasını sağlasa bile, tamamen yeni bir hizmet oluşturmak yerine, eklenen işlevselliğin işlevsel bağlamı mevcut hizmetin işlevsel bağlamıyla eşleştiği sürece yeni işlevin mevcut hizmete eklenmesi gerekir.

Hizmet envanterinin sınırları içinde kalan her iş sürecine aynı sürecin uygulanması gerekir.

Hizmet normalleştirme tasarım modelinin esaslarını takip ederek, hizmet envanterindeki toplam hizmet sayısı da azalacaktır. Bunun nedeni, gereksiz hizmetlerin geliştirilmesinin engellenmesidir, bu da Yönetim hizmet envanterinin ek yükü. Bu tasarım modelinin uygulanması, ayrıca mantık merkezileştirme ve hizmet yeniden düzenleme tasarım desenleri. Bunun nedeni, hizmetlerin herhangi bir fazlalık işlevsellik içermemesi ve bu nedenle, belirli bir iş süreciyle ilgili olmayan mantığı tek bir hizmette tutmanın ve herhangi bir bağımlılığı bozmadan bir hizmeti geliştirmenin kolay olmasıdır.

Düşünceler

Bu tasarım modelinin uygulanması, yukarıdan aşağıya hizmet sunumunun izlenmesini gerektirir[7] herhangi bir gerçek hizmet sunulmadan önce önemli ölçüde önceden analiz gerektiren süreç. Bu, hem açısından ekstra kaynak gerektirir. adam-saat hem de zaman. Bu durum, ortada buluşmanın benimsenmesiyle çözülebilir[8] Tam bir hizmet envanteri oluşturmayı beklemeden yeterli hizmetler modellendikten sonra hizmet sunum sürecinin başlayabileceği hizmet sunum süreci[9] taslak.

Giderek daha fazla iş süreci otomatikleştirildikçe, mevcut normalleştirilmiş hizmetlerin sürekli bir yönetişimi gereklidir. Bunun nedeni, yeni iş süreçlerinin otomasyonunun mevcut normalleştirilmiş hizmetlere işlevsellik eklenmesiyle sonuçlanabilmesidir ve bu hizmetlerin normalleştirilmiş kalmasını sağlamak için geri kalan hizmetlerin analiz edilmesi gerekir.

Referanslar

  1. ^ Hizmetler
  2. ^ hizmet envanteri
  3. ^ Kanu Tripathi.WS-AtomicTransaction Olmadan Hizmet İşlemi Yönetimi [Çevrimiçi]. Erişim tarihi: 25 Nisan 2010.
  4. ^ Thomas Erl, Herbjörn Wilhelmsen.Hizmet Normalleştirme tasarım modeli [İnternet üzerinden]. Erişim tarihi: 6 Nisan 2010.
  5. ^ Thomas Erl.SOA Tasarım Modeline Giriş [İnternet üzerinden]. Erişim tarihi: 6 Nisan 2010.
  6. ^ Yefim V. Natis, Massimo Pezzini.On İki Yaygın SOA Hatası ve Bunlardan Nasıl Kaçınılır [Çevrimiçi]. Erişim tarihi: 25 Nisan 2010.
  7. ^ Yukarıdan aşağıya hizmet sunum süreci Arşivlendi 9 Mayıs 2010 Wayback Makinesi
  8. ^ ortada buluşma hizmeti sunumu
  9. ^ Hizmet Envanteri

daha fazla okuma

  • Erl ve diğerleri, (2009).SOA Tasarım Modelleri. Prentice Hall. ISBN  0-13-613516-1
  • Mauro. et al. Servis Odaklı Cihaz Entegrasyonu - SOA Tasarım Modellerinin Bir Analizi. [Çevrimiçi], s. 1–10, 2010 43rd Hawaii Uluslararası Sistem Bilimleri Konferansı, 2010. Erişim tarihi: 4 Nisan 2010.
  • Matthew Dailey.Yazılım Mimarisi Tasarım Hizmeti Odaklı Mimariler (Bölüm II) [Çevrimiçi]. Erişim tarihi: 22 Nisan 2010.

Dış bağlantılar