Servis Tabanlı Ürün Mimarisi Tasarım Sorunları – Product Service System Design Problems

Yazılım mimarisinde zorlandığımız konulardan biri aynı sistem üzerinde somut ürünleri ve hizmet bazlı ürünleri bir arada satmak istediğimizde ortak bir yazılım mimarisi oturtabilmekti. Bu zorluk hem veritabanı hem de sınıf yapıları için geçerli bir durum.

Neden?
Bugünkü dünyada ürünlerle sağlanan hizmetler giderek daha çok yer tutmaktadır. Eskiden araba satışı yapıldıktan sonra üreticinin müşteriyle ilişkisi kesilirken, bugün gelinen noktada üreticilerin bir bölümü araçları kiralama modeliyle müşterilerine sunmaktadırlar. Yani müşteri arabayı değil, belirli sürelerle araç kullanma hizmetini almaktadır [2]. Bu durumda eskiden üretim tarafında kullanılan BT sistemleri yeni ihtiyaçlar için yetersiz hale gelmiştir.

serviceproductsubs-01

Ürünlere İlişkin Hizmetlerin Sınıflandırılması [3]

Zorluklar

Somutlaştırma,
Somut ürünlerde ürün stok kodunun yanında, ürün tanımı (ad, üretici kodu, vb.) gibi bilgiler kullanılırıken, servis bazlı ürünlerde servisin başlangıç, bitiş süresi, tanımı ve opsiyonel bazı diğer seçenekler söz konusu. Somut ürün satışından sonra buna ilişkin bakım, yenileme ve benzeri servis bazlı özelliklerin bilgilerinin tutulması ve bunlara ilişkin iş akışlarının tasarlanması gerekiyor. Servis üyelikleri (sesli ve görüntülü iletişim), sigorta, finans, eğitim, tatil ve yazılım gibi hizmet ağırlıklı ürünlerde ise satış sonrasında yerine getirilmesi gereken işlemler ağırlık kazanmaktadır.

Somut ve Servis Tabanlı Ürünlerin Karşılaştırması

serviceproductmapping-02

Servis ve Somut Ürün Karşılaştırması

Zorluklar

Hem ürün hem de servis bazlı sistemlerde değişiklik talepleri karşısında karşılaşılabilecek zorluklar,

  • Bağımlılık yönetimi: Bir değişikliğin sistemdeki diğer nesneler üzerindeki etkisi
  • Yeni değişiklik noktaları: Sisteme yeni değişiklik noktalarının eklenmesi.
  • Sistem tasarımın değiştirilmesi: Değişen ihtiyaçlar doğrultusunda tasarımın değişmesi. İçlerinde ne pahalı olan güncellemedir.

Çözüm Yöntemleri

  • Ayrık Sistemler: Somut ve servis bazlı ürünlerin ayrı sistemler sahip olması. Aradaki ilişkinin paylaşılan ürün tekil numaraları üzerinden sağlanması.
  • Karma Sistemler: Ayrım yapılmaksızın somut ürünleri ve hizmetleri tek bir sistemde barınması.
  • Tümleşik Sistemler: Somut ürünler ve bunlara ilişkin hizmetleri ayrık yapılarda olmasına karşın aralarında güçlü bağların olması.

Bağlantılar,

[1] http://www.servicedesignresearch.com
[2] Oksana Mont (2002). “Clarifying the Concept of Product-Service System”(PDF). Journal of Cleaner Production 10 (3): 237–245. doi:10.1016/S0959-6526(01)00039-7.
[3] Brezet, H. (2000). Product-Service Substitution: Examples and Cases from the Netherlands. In Mont, O. & Ryan, C. (Eds.), “Funktionsförsäljning” – productservice systems, AFR-report 299 (pp. 16-18). Stockholm: Swedish EPA.

Reklamlar

Bulut Bilişim – Cloud Computing

Son zamanların Buzz wordu “Cloud Computing” ya da Türkçesi “Bulut Bilişimdir”. İnternette ufak bir araştırma yaptığınızda herkesin bu kavramı kendine göre tanımladığını görebilirsiniz. Bu da ister istemez kafa karışıklığına yol açıyor. Bu yazıda farklı sağlayıcıların Bulut Bilişimden ne anladıklarını özetlemeye çalışacağım.

Genel Bulut Bilişim Stratejileri

Bulut Bilişim genel olarak bir yönelimler kümesini temsil eder. Kurum olarak siz kendi ihtiyaçlarınıza uygun yönelimi veya yönelimleri seçmeniz uygun olacaktır. Bu yönelimler dört farklı başlık altında gruplanabilir,

  • İş Fonksiyonu Seviyesi: Belirli iş fonksiyonlarının bulut’ta yer alan hazır kaynaklar üzerinden sağlanması olarak düşünülebilir. Şimdilik en az uygulaması olan gruptur.
  • Uygulama Seviyesi: Uygulamaların buluttan sunulması olarak tanımlanabilir. Software as a service (SAAS) olarak sunulan uygulamalar bu sınıfta yer almaktadır. Örnek uygulamalar arasında bulut üzerinden chatt, çağrı merkezi, eposta ve benzeri servislerin verilmesi gösterilebilir.
  • Platform Seviyesi: Bulut’ta alınabilecek hizmetlerin merkezi platformlar üzerinden sağlanmasıdır. Her bir sağlayıcı bu konuda kendi platformunu sunmaktadır. Kullanıcılar çeşitli ortamlarda geliştirdikleri uygulamaları bu platformlarda barındırabilmektedirler. Platform sağlayıcılar kullanılan CPU, network bant genişliği, Veritabanı büyüklüğü ve benzeri kriterlere göre periyodik ücretlendirmeler yapmaktadırlar.
  • Altyapı Seviyesi: Veri depolama, Sunucu barındırma ve benzeri altyapı servislerinin tamamen bulutta yer alan sistemler üzerinden sağlanmasıdır.

Bulut Bilişim Uygulamaları

Çeşitli kurumlar tarafından sunulan Bulut Bilişim hizmetleri aşağıdaki tabloda özetlenmiştir. Burada verilen örnekler fikir vermek açısından ele alınmıştır. Benzer hizmetleri veren kurum ve şirketlerin sayısı giderek artmaktadır.

Bulut Bilişim Uygulama Örnekleri
Seviye Şirket-Kurum Açıklama
Uygulama SalesForce İşletmeler için CRM uygulaması ve kapsamındaki Satış, Destek, Raporlama yazılımlarını sunmaktadır.http://www.salesforce.com
Uygulama Google Apps İşletmeler için Gmail, Google Takvim, Google Dokümanlar, Google Sites, Google Video ve benzeri uygulamaları kapsamaktadır.http://www.google.com/apps
Uygulama IBM – Lotus Live IBM yazılımların hizmet olarak sunulma iddiasını biraz daha öteye taşıyor. IBM kendisine ait Mail, Takvim, Doküman yönetimi, Proje yönetimi ve benzeri uygulamaları sunarken, bir yandan piyasada bulunan Open Source (Sugar CRM, vb.) ve ücretli yazılımları da müşterilerine sunuyor. Belirli servis paketlerini aylık ücretler karşılığında kullanabiliyorsunuz.http://www.lotuslive.com/en/
Platform Google – App Engine Java ve Python kullanarak geliştirdiğiniz uygulamaları, Google sunucularında çalıştırabilirsiniz. Java ve Pythona ilişkin SDKları Code Google altında yer alıyor.http://code.google.com/appengine/
Platform Amazon – AWS Amazon web servislerinde uygulamalarınızı Java, PHP, Python, Ruby ve .Net ortamlarından birinde geliştirebilirsiniz. Bunlara ilişkin SDK’lar ücretsiz olarak web sitesinden indirebilirsiniz.http://aws.amazon.com/
Platform Microsoft – Azure Windows Azure platformunda barındıracağınız uygulamaları C#, Java, Ruby, PHP ve benzeri araç ve dilleri kullanarak geliştirme yapabilirsiniz. Geliştirme ile ilgili SDKları sitesinden ücretsiz indirip kurabilirsiniz. Windows Azure uygulamalar, SQL Azure veritabanları için platform sağlıyor.http://www.microsoft.com/windowsazure/
Altyapı Amazon.com – EC2, S3 Amazon EC2 ortamından kendi sanal sunucularınızı oluşturup geliştirdiğiniz uygulamaları hızlı bir şekilde devreye alabilirsiniz. Amazon kullandığınız kaynakların raporlanması ve yönetimi için araçlar sunmaktadır. http://aws.amazon.com/ec2/Benzer şekilde depolama alanı olarak Amazon S3 (Simple Storage Service) hizmetlerini kullanabilirsiniz.http://aws.amazon.com/s3/
Altyapı Google Google yönetilebilir barındırma hizmetlerini sunmaktadır.
Altyapı Terramark Terramark yönetilebilir barındırma hizmetlerini sunmaktadır. Bunlardan VMware vCloud veri merkezi hizmetleri öne çıkmaktadır. http://www.terremark.com

Neden Bulut Bilişim?

Bulut Bilişim, bilişim dünyasında var ola gelen kuralları, oturmuş alışkanlıkları, satış stratejilerini temelden değiştirecek teknolojik trend olarak önümüze çıkıyor. Bu trend beraberinde hem fırsatları hem de tehditleri getirmektedir. Süreç karşımıza yeni oyuncuları getirecektir, eski oyuncuların ise buna göre esnediğini veya yön değiştirdiğini gözlemliyoruz. Bu trendi fırsat olarak görüp değerlendirenler daha büyük fayda sağlayabileceklerdir.

Arayüz ve İş Katmanı Tasarım Mimarileri – Software Design Patterns for User Interface and Businnes Logic

Yazılım tasarımında önemli kararlardan biri kullanıcı arayüzü ve iş katmanı arasında bilgi akışının düzenlenmesidir. Kullanılan ortamın windows veya web tabanlı olmasına bağlı olarak yapılacak tercihte farklılıklar olabilir. Kullanılan arayüz mimarileri OOP’in temel ilkelerinden olan kavramların ayrılığına (separation of concerns) dayanır. En çok bilinen arayüz – iş katmanı modelleri,

MVC (Model-View-Controller) mimarisi üç temel bileşenden oluşur; Model, Görünüm, Denetçi. MVC ilk defa 70li yılların sonunda Xerox bünyesinde uygulanmıştır.

mvc01

MVC Modeli

Model: uygulama alanına mahsus bileşenlerin tanımlandığı bunlara ilişkin durumları ve bilgileri saklayan yapılardır. Modelde bir değişiklik olduğunda buna ilişkin görsel (View) yapılar uyarılır.

View (Görünüm): modelde bulunan bilgilerin kullanıcıya anlaşılır bir şekilde sunulmasından sorumludur. Aynı zamanda kullanıcının girdiği verileri Denetçi (Controller) birimine iletir. Görünüm kısmı php şablonları, jsp, asp sayfalarından oluşabilir.

Controller (Denetçi): Denetçi bu üçlünün habercisini oluşturur. Görünüm ve model arasında veri akışını kontrol eder, görünümden girilen verileri modele yansıtır, modeldeki durumların ve bilgilerin görünümle ilgili bölümlerini günceller. Bazı durumlarda uygulama için Observer (gözlemci) deseni kullanılabilir.

MVC’nin temel özellikleri,

  • Model, Görünüm ve Denetçi’den bağımsızdır.
  • Model, Görünüm ve Denetçi’den bağımsız olarak oluşturulup, güncellenebilir.
  • Aynı Modele birden fazla Görünüm ve Denetçi çifti uygulanabilir. Aynı model hem web ara yüzünden hem de XML yapısından sunulabilir.

Model View Presenter (MVP) modeli MVC’nin daha gevşek bağlara sahip özel bir uygulaması olarak tasarlanmıştır.

 

mvp01-02

MVP Modeli

MVP’nin bileşenleri,

Model: Asıl verileri ve yapıları barındıran sınıflardır.

View (Görünüm): Modeldeki verilerin görüntülenmesini ve kullanıcı olaylarının sunucuya (presenter) iletilmesini sağlar.

Presenter (Sunucu): Sunucu model ve görünüm üzerinde etkilidir. Modeldeki verileri alır, bunları saklar ve görünüm için uygun formata dönüştürür.

Presentation Model (PM)

PM modeli 2004 yılında Martin Fowler tarafından önerilmiştir. MVP’ye benzer olarak görünümü, davranışı ve durumu birbirinden ayırmaktadır. Bu mimaride görünüm, sunum modeliyle (presentation model) sürekli olarak etkileşmekte ve gösterdiği bilgileri tazelemektedir. Kullanıcadan gelen giriş bilgileri bu sunum modelini güncellemekte ve saklanmaktadır, görünüm ise kendini sunum modelinden tazelemektedir.

MVVM (Model-View-ViewModel)

MVVM üç temel bileşenden oluşur; Model, View, ve ViewModel.

  • View doğrudan bir ViewModel’e bağlanır
  • ViewModel barındırdığı bilgileri View’a döndürür
  • ViewModeller genelde View’a karşılık gelen DataContext nesneleridir
  • ViewModel’de oluşan değişiklikler View’a hemen aktarılır
  • View’dan gelen kullanıcı girişleri ViewModel’de ilişkili bir komutu çalıştırır
  • ViewModel yapılan değişiklikleri Model’e yansıtır
  • Model ve View arasında doğrudan bir ilişki yoktur
  • MVVM mimarisinde ViewModel’e test yazmak oldukça kolaydır. Test sınıfları ViewModel için farklı bir View ifade eder.

mvvm01-03

 

MVVM Modeli

MVC’nin farklı uyarlamaları,

  • Model Delegate
  • Morphic Interface
  • Model Pipe View Controller
  • Four Layer Architecture

Konuyla ilgili başurabileceğiniz bağlantılar,

MSDN, WPF Apps With The Model-View-ViewModel Design Pattern
MVC or MVP Pattern – Whats the difference?
Model View Controller
Presentation Model
Code Project, Model View Controller, Model View Presenter, and Model View ViewModel Design Patterns

Servis Tabanlı Ürün Mimarisine Tasarım Önerisi – A Design Model for Service Based Systems

Önerilen mimaride iş geliştirme, pazarlama, v.b. departmanlar tarafından tasarlanan servislerin BT sistemlerinde nasıl uygulanabilir sorusuna yanıt aranmaktadır.

Mimaride yer alan temel birimler,

ServiceModel-01.png

Servis Modeli

Servis Paketi: hizmet satışlarında genellikle tek bir paketin içinde birden fazla servis tanımlanır. Müşteri tarafında ise bunlar tek bir paket altında sunulur. Konuyu anlatmak için İnternet’te yapılan alışverişler üzerinden bir benzetme kullanabilir. Bu alışverişlerde genellikle sepet mantığı kullanılır. Seçtiğiniz ürünleri sepete tek tek eklersiniz. Sonra da sepeti satın alırsınız. Servis paketi ise bunun tersyüz edilmiş halidir. Müşteri paketin tamamını alır. Sistemler arka planda paketi oluşturan servisleri oluşturur ve gerekli işlemleri başlatır. Her servis paketinde bir veya birden fazla servis bulunabilir.

Servis: Esas hizmete ilişkin Servisi Birimi, Kural Dizgisi, Veri Erişim Katmanı ve Uygulama Adaptörü gibi bileşenleri barındırır.

Servis Birimi: Hizmete ilişkin işleyişleri (iş mantığını) barındırır. Durum makineleri ve BPEL süreçleri servisleri uygulamak için kullanılabilir. Galatataş üyeliği sonrasında veri tabanına gerekli kayıtların açılması, müşteriye SMS atılması, iş ortaklarına mesaj geçilmesi, sözleşme belgelerinin hazırlanması bu servis birimlerinin içinde tanımlanabilir.

Kural Dizgisi: Hizmete ilişkin kuralların tanımları yer alır. Bunlar arasında çalışma zamanları, kontroller (Maça gelişlerde Galatataş üyeliğinin devam edip etmediğinin kontrolü), vb. yer alır.

Veri Erişim Katmanı: Veritabanlarını veya diğer XML servislerine erişimde kullanılır.

Uygulama Adaptörü: Diğer sistemlerdeki servislere tek bir arayüz üzerinden erişmeye imkan sağlar. Sistem üzerinden farklı operatörlede bulunan SMS servislerine tek bir arayüz üzerinden göndermek için kullanılabilir.

Mimaride önerilen peketlerin altında yer alabilecek uygulamalara ilişkin örnekler,

Servis Modeli Uygulamaları

ServiceModelExamples-02.png

Servis mimarisinde çeşitli birimlerde kullanılabilecek teknolojiler,

Servis Modeli Teknolojileri

ServiceModelTechnology-03.png

Servis Modelinin Kullanımı

Önerilen servis modeli teknoloji ve uygulamadan bağımsız olarak tasarlanmış ve geneli kapsaması düşünülmüştür. Benzer bir model uygulanmak istendiğinde kullanılan teknolojilere ve uygulamanın alanına bağlı olarak bazı kısıtlamalar oluşacaktır. Uygulama servis modeli buna göre şekillenecektir. Modeli gerçeklemede yazılım tasarımın temel ilkelerinden uzmanlık (expert), az bağımlılık (low coupling), iyi uyum (high cohesion), arabirim (indirection, adapter, facade) kullanılması durumunda daha sağlıklı yapılar elde edilecektir.