turkiye.gov.tr

Başbakanlık, verilen e-devlet hizmetlerinin iyileştirilmesi, tek elden koordine edilip, kullanılan araç ve teknolojilerin daha verimli kullanılması ve hizmet kalitesinin arttırılması için bir kanun tasarısı hazırlamış ve bunu da kamuoyu görüşüne açmış. Detayları aşağıda bulabilirsiniz.

Hatırlarsanız bundan bir kaç yıl önce E-Devlet Kapısı projesi gündeme gelmiş, yapılan ihale sonucu Oytek grubu projeyi yönetmeye hak kazanmış, önce Türk Telekom’da olan proje sorumluluğu da sonradan Türksat’a devredilmişti. Bu proje kapsamında bugün de hizmette olan turkiye.gov.tr sitesi doğmuştu. Şimdilik devlet kurumlarıyla yeterli derecede entegre çalışmayan, daha çok kurum hizmetlerine giriş kapısı gibi duran bir girişimdi bu. Kişisel olarak da bilgisayarımdaki Safari tarayıcısı ile giremediğim nadir sitelerden biri oldu.

Bilgi toplumu olmak şüphesizki ülkenin medeniyet seviyesindeki artışla eşdeğer. Sağlıklı işleyen bir E-Devlet yapısıyla vatandaşların devletin hizmetlerini daha zahmetsizce ve mevzuat açıklıkları vs’ye daha az maruz kalarak kullanmaları mümkün olacak. Hizmetler kişilerden sistemlere taşınarak kaliteleri, kusursuzlukları artacak, tamamlanma süreleri büyük ölçüde azalacak. Yapılan işlerde kayıtsızlık problemleri de azalacak ve bunun sonucunda aslında demokratik hizmet dağılımının da gerçeklenmesi mümkün olacak. Kısacası sağlıklı bilgi toplumu çok alanda fayda sağlayacak.

Bu işte başarı sağlayabilmek ise uzun ve ağır bir çalışmayı gerektiriyor. Öncelikle mevcut hizmetlerin tam bir envanteri tüm ilişkili olduğu süreç, belge, kişi, kurum, mevzuat nesneleriyle beraber oluşturulmalı. Bunlar bir modele oturtularak bu modelde nerelerde iyileştirmeler sağlanabilir, nerelerde standartlaşmaya gidilebilir, nerelerde ortak teknolojiler kurulabilir analizi yapılmalı.

Teknik olarak bu model bir Servis Odaklı Mimari’nin üzerinde kurgulanmalı, gerekirse federe çalışan Kurumsal Servis Yolları [ESB] gündeme getirilmeli. Devlet kurumlarının bu mimariye dahil olacakları standartlaşmalara gidilmeli, gerekirse İngiltere’deki DISBOX [Department Integrated Service Box] benzeri senaryolar oluşturulmalı. Sağlıklı bir SOA’nın gerektirdiği tüm noktalar es geçilmeden bu mimariye katılmalı. Devlet gerekirse açık kaynağın da desteğini de alarak kendi servis çatısını yaratmalı, geliştirmeli.

Verilen hizmetlerin izlediği süreçler BPMN gibi standartlarla ifade edilmeli ve mümkün olduğu derecede süreç motorlarının üstünde çalıştırılmalı.

Bu arada sizler de tasarı ile ilgili görüşlerinizi Türk Bilişim Derneği’nin sitesinden aktarabilirsiniz.

Tasarıyla ilgili dokümanlara da aşağıdaki linklerden ulaşabilirsiniz:
http://www.basbakanlik.gov.tr/docs/e-devlet/taslak.doc
http://www.basbakanlik.gov.tr/docs/e-devlet/gerekce.doc

Related posts:

1. SOA Birlikte Çalışınca (Çalışabilince) Güzel
2. Makale: Süreç Yönetimi
3. SOA ve Türkiye

SOA açısından en önemli konulardan bir tanesi “birlikte çalışabilirlik”. Uygulamaların standartlar üzerinden, gevşek bağlarla birbirine kolayca entegre olabilmesinden bahsediyoruz. Fakat, maalesef, ya standartlar yeterince standart olamadığından ya da standartları gerçekleyen projelerin/araçların/ürünlerin farklılıklarından, herzaman beklendiği kadar kolay entegrasyonu gerçekleştiremiyoruz.

Benim sevimsiz tecrübem Axis ile implemente ettiğim web servisi sunucumun, gSoap ile implemente edilmiş istemciyle konuşamaması şeklinde oldu. Uzun süreli araştırmalar ve biraz da hile ile iki uygulamayı beraber işler hale getirebildik. Tabi ki içimize sinmeyen bir çözüm olmuştu yaptığımız.
(bkz: http://www.gridlab.org/WorkPackages/wp-5/guide/faults.html)

Peki yanlış olan neydi? Birimiz Türk diğerimiz Alman iken ve biz bile anlaşabiliyorken bu web servisleri neden beraber çalışamamıştı? gSoap‘un ürettiği web servisi tanımı (WSDL) yanlış mıydı? Yoksa hata Axis‘de miydi? Eğer nuSoap ya da XFire kullansaydık farklı problemlerle mi karşılacaktık?

Sonuçta iki projenin de “kendine göre” doğru implementasyonu gerçekleştirdiğini, ortaya çıkardıkları WSDL ve SOAP mesajlarının tamamen uygun XML şemalarını desteklediklerini, ama “şeklen” farklılıklar taşıdıklarını gördük. Namespace’lerin farklı algılanması ve işlenmesiydi bu farklılık. Sonuç ise gSoap’un hazırlayıp gönderdiği SOAP mesajının Axis’in kabul etmemesi olmuştu.

Bugünlerde kurumların kendi içlerindeki entegrasyon kadar aralarındaki entegrasyon da konuşulan konular arasında. Özellikle E-Devlet Kapısı çalışmalarıyla beraber bu tür entegrasyon, yalnızca kamu kuruluşları için değil, kamu kuruluşlarıyla bilgi paylaşan özel kurumlar için de ihtiyaç halini alıyor. Bu ihtiyacın literatürdeki adı İngiltere’de DIS BOX(Department Integrated Service Box) olarak konulmuş durumda. Kısaca kurumun sağladığı servisleri güvenli ve belirli sınırlar içinde sunabilmek (SLA), başka kurumların sağladığı servisleri de yine güvenli ve hızlı şekilde tüketebilmek için tasarlanmış yapılar bu DIS BOX’lar. Dayandıkları mimari de tabiki açık standartlar ve SOA.

Yukarıda anlatılanları birbirine bağlarsak kurumlar arası entegrasyonu bekleyen önemli sorunlardan bir tanesi “beraber çalışabilirlik/işlerlik”. Web servislerinin beraber işlerliği ile ilgili bir organizasyon da var üstelik. WS-I organizasyonu yaratılan web servislerinin gerçekten gevşek entegrasyonu sağlayabilmesi için sağlaması gereken standartları belirliyor. Bu standartları da güvenliği (WS-Security) ve güvenilirliği (WS-Reliability) işin içine sokan farklı profiller şeklinde ifade ediyor. Buna göre SOA’nızın içinde yer alan bir ürünün WS-I profillerini gerçekleyip gerçeklemediğini sorgulayıp, beraber işlerlik konusunda sıkıntı yaşama olasılığınızı görebiliyorsunuz.

WS-I SOA’ya uygun araçlar geliştiren kişiler/kurumlar için de test araçları ve örnek uygulamalar sunuyor.

Doğru SOA’yı gerçekleştirmek için atılacak adımlardan biri de beraber işlerliği sağlayabilmek. Çünkü, SOA birlikte çalışınca güzel.

Related posts:

1. E-Devlet ve Bilgi Toplumu
2. Güzel Zamanlama
3. SOA’nın Getirdikleri (Götürdükleri?)