Windows Workflow Foundation – Yapı

Windows Workflow Foundation – Yapı

 

 

            Yukarıdaki şekil  WWF’nin yapısını açıklıyor . Burda en yukarıda Host Process olduğunu ve bunun diğer bütün öğeleri içinde barındırdığını da farketmiş olmalısınız .  Host Process’ten kasıt burda kendi uygulamamız ; bu bir Windows Forms ,ASP.NET veya en basitinden bir Console Uygulaması olabilir . WFF bir framework yapısında olduğu için içerisinde sadece tekrar kullanılabilir özellikte olan öğeler barındırır ve bu öğeler bizim implementasyonumuz olmadan birşey ifade edemez.

 

            WWF içerisinde  yer ala öğeleri açıklayacak olursak ;

 

Base Activity Library  and Framework : Aktivitelere ileride başka makalelerimde daha detaylı olarak değineceğim   ,ama Windows Forms veya ASP.NET ‘teki kontrollere benzer bir yapıda olduklarını şimdiden söyleyebilirim . Tasarladığımız workflow’larımız içerisinde yer alan aktiveteler bir bütün olarak ancak workflow oluşturabilir .  Net 3.0 yüklediğimiz zaman bize WWF dahilinde bir çok aktivite dahili olarak  bizim kullanımımıza hazır bir şekilde gelmekte . Toolbox’ımı açıp baktığımız vakit , IfElseAcitivty, WhileActivity gibi ismen bize hiç de yabancı olmayan bazı aktivitelere bile rastlamaktayız  . Diğer yandan workflowlarımız sadece aktivitelerden oluşuyor gibi gözükse de bunu destekleyen ve bir framework de arkada barındırmakta . Mesela PolicyActivity  arkasında bir rule engine çalıştırmaktadır .

 

Runtime Engine  : Workflow’ların tekrar kullanılabilir yapıda sınıflardır ve tek başlarına bir görev üstlenemezler . Host uygulamanın bir şekilde bu workflow’ları ayağa kaldırıyor olması gerekmekte . Ayrıca uygulama içerisinden de workflowlarımızı besliyor ve yönetebiliyor olmalıyız . Runtime Engine bu görevi gerçekleştiren birim olarak karşımıza çıkıyor .  Uygulama içerisinde workflow sınıfları ile asla direk olarak çalışmıyor ,runtime hangi workflow ile çalışmak istediğimi söyleyebiliyoruz sadece . Gerisini runtime bizim için halledecektir zaten . Tabiki burda servislerin rolünü de ihmal etmemek lazım .

 

Runtime Services : Runtime engine workflow’ları ayağa kaldırabilir ve yönetebilir ama workflow ile runtime arasındaki ilişkininin niteliklerini belirleyen yapı runtime services’dir. Engine ayrıca içerisinde bu service’leri barındırır . Worfklow’larımız ise runtime’la bu servislerin arayüzleri veya soyut sınıfları vasıtayla temasta  bulunur . Bu servisler mesela ne yapabilir . En basitinden bir örnek verecek olursak aynı sınıftan türüyen iki tane scheduler servisimiz vardır :

 

ManualWorkflowSchedulerService DefaultWorfklowSchedulerService

 

DefaultWorfklowSchedulerService zaten runtime’a adından da anlaşılabileceği gibi varsayılan olarak ekli gelir . Eğer ben bu servisi ManualWorkflowSchedulerService ile ezmezsem engine bana workflowlarımı asenkron olarak işletecektir . Diğer türlü senkron bir işletim olacaktı.

 

Workflow’ların aktivitelerin toplamından oluştuğundan bahsederek esasında aktivitelerin önemine de vurgu yapmış olduk . Base Activity Library ile bize gerçekten çok kullanışlı birçok aktivite gelsede bunların yetmediği yerler olacaktır veya en azından uygulamamızda bazı taskleri kolaylaştıracak spesifik aktivitelere ihtiyacımız olacaktır  . Bu durumlarda kendi aktivitelerimi workflow projelerinde oluşturabilir , hatta ve hatta bunları bir activity library içerisinde toparlayarak tekrar kullanabilir bir yapıya sokabiliriz (mesela mail gönderen bir aktivite her projede mutlaka gerekecektir ) .Custom Activity Library ise bunu ifade eder.

 

İlk bakışta  biraz karmaşık veya soyut gelen bu ifadeleri ileriki makalelerde koda girdiğimiz vakit çok daha iyi anlayacağınızı tahmin ediyorum . Gelecek makalelerde de buluşmak üzere hoşçakalın .

Döküman Arama

Başlık :

Kapat