Giriş
İki defa Parser (Ayrıştırıcı) işi ile uğraşmam gerekti. Her ikisinde de farklı yöntemler kullandım. Parser denilince akla sadece bir stream'den veriyi okuyup mesaj haline getiren şey geliyor.
İşin bir de mesaj oluşturup gönderme ve hatta mesajları belli kurallara göre gönderme tarafı da olabiliyor. Bu konuyu Parser ile karıştırmayıp Transmission Queue veya Message Crafting başlığı ile ayrı olarak ele almakta fayda var.
1. Gömülü Proje Parser
Bu projede mesajlar A zarfı içindeki B zarfı içindeki C mesajları şeklindeydi. Uygulama sadece C mesajları ile ilgileniyordu. Parser Java'daki Stax Parser gibi çalışacak şekilde tasarlandı. Yani C mesajlarını okudukça uygulamaya bir çeşit event(olay) gönderiyordu. Bu Parser push modda çalışıyor diye düşünülebilir. Uygulama A ve B zarfları ile ilgilenmediği için görece olarak gerçekleştirmesi kolay.
Tek sıkıntı mesajların zor ve açmalı kapamalı yapıya sahip olması ve gömülü ortamın getirdiği bellek kısıtlarıydı
2. Java Parser
Bu projedeki mesajlar sınırsız bir derinlikte ve zarf tipinde olabiliyordu. A zarfının içine B,C,D gibi herhangi bir zarf ve alt zarfların içine de yine belirsiz tipte mesajlar gelebiliyordu. Bu projedeki parser pull modda çalışıyordu. Yani parse() merodu sonucunda bir çeşit Composite dönüyordu.
Composite yapısını tasarlaması zordu. Ayrıca Parser içinden diğer parser'ları çağırmak ta gerektiği için her parser'a bir Context nesnesi geçmek gerekiyor. Context içinde Composite nesnesi, parser işleminin sonucu, Parser'ın çalışma modu gibi gerekli parametreler bulunuyordu.
Mesajlar için ayrı ayrı modüller/kütüphaneler tasarlanmıştı. Böylece mesajların tekrar kullanılabilir olması hedeflenmişti. Yani ben elle mesajı oluşturup gönderebiliyordum.
2.1 Genel Sıkıntılar - Bozuk Veri
Parser'ın hatalı gelen mesajları bir şekilde anlayıp bir şey yapması gerekiyor. Verinin nereden bozulduğunu anlaması kolay değil. Yapılabilecek bazı şeyler şöyle.
- Örneğin eski veri atılıp yeni bir başlangıç yapmak.
- Hatalı olan kısma kadar olan veriyi düzgünce işleyip geri kalanını "Bozuk Veri" olarak göstermek.
- Bence en güzel yöntem Parser'ın okuduğı kanalı kapatıp gerekiyorsa tekrar açmak
2.2 Genel Sıkıntılar - Parser'ın Çıktısını İşleyen Kod
Parser'ımız Composite döndüğü için bu kanalı dinleyen kod parçasına herşey geliyor. Yani Wireshark'tan Ethernet + IP + TCP + Data almak gibi. Ancak kod parçamız sadece Data ile ilgileniyor. Dolayısıyla kodumuzun Composite içinde yürüyerek işlemek istediği düğümü bulması gerekiyor.
2.3 Parser'ın Okuduğu Kanal İle Kod Parçasına Kadar Olan Tasarım
2.3.1. Event Driven Processor
Bu seçenek şöyle
Poller -> Stream Buffer (Kanal)-> Parser -> Processor (Kod Parçası)
Burada karşımıza yine iki seçenek çıkıyor. Poller'a ayrı ayrı kanallar takmak veya tek bir kanal takıp kanalın ucunda Parser'lara göre ayrıştırmak.
Aralarında çok fark yok. Tek dikkat edilmesi gereken köprüyü yani kanalı kapatırken önce Poller ucunu daha sonra Processor ucunu kapatmak. Ya da tam tersi yeterki tutarlı olsun :)
2.3.1. Pulling Processor
Bu seçenek şöyle
İki defa Parser (Ayrıştırıcı) işi ile uğraşmam gerekti. Her ikisinde de farklı yöntemler kullandım. Parser denilince akla sadece bir stream'den veriyi okuyup mesaj haline getiren şey geliyor.
İşin bir de mesaj oluşturup gönderme ve hatta mesajları belli kurallara göre gönderme tarafı da olabiliyor. Bu konuyu Parser ile karıştırmayıp Transmission Queue veya Message Crafting başlığı ile ayrı olarak ele almakta fayda var.
1. Gömülü Proje Parser
Bu projede mesajlar A zarfı içindeki B zarfı içindeki C mesajları şeklindeydi. Uygulama sadece C mesajları ile ilgileniyordu. Parser Java'daki Stax Parser gibi çalışacak şekilde tasarlandı. Yani C mesajlarını okudukça uygulamaya bir çeşit event(olay) gönderiyordu. Bu Parser push modda çalışıyor diye düşünülebilir. Uygulama A ve B zarfları ile ilgilenmediği için görece olarak gerçekleştirmesi kolay.
Tek sıkıntı mesajların zor ve açmalı kapamalı yapıya sahip olması ve gömülü ortamın getirdiği bellek kısıtlarıydı
2. Java Parser
Bu projedeki mesajlar sınırsız bir derinlikte ve zarf tipinde olabiliyordu. A zarfının içine B,C,D gibi herhangi bir zarf ve alt zarfların içine de yine belirsiz tipte mesajlar gelebiliyordu. Bu projedeki parser pull modda çalışıyordu. Yani parse() merodu sonucunda bir çeşit Composite dönüyordu.
Composite yapısını tasarlaması zordu. Ayrıca Parser içinden diğer parser'ları çağırmak ta gerektiği için her parser'a bir Context nesnesi geçmek gerekiyor. Context içinde Composite nesnesi, parser işleminin sonucu, Parser'ın çalışma modu gibi gerekli parametreler bulunuyordu.
Mesajlar için ayrı ayrı modüller/kütüphaneler tasarlanmıştı. Böylece mesajların tekrar kullanılabilir olması hedeflenmişti. Yani ben elle mesajı oluşturup gönderebiliyordum.
2.1 Genel Sıkıntılar - Bozuk Veri
Parser'ın hatalı gelen mesajları bir şekilde anlayıp bir şey yapması gerekiyor. Verinin nereden bozulduğunu anlaması kolay değil. Yapılabilecek bazı şeyler şöyle.
- Örneğin eski veri atılıp yeni bir başlangıç yapmak.
- Hatalı olan kısma kadar olan veriyi düzgünce işleyip geri kalanını "Bozuk Veri" olarak göstermek.
- Bence en güzel yöntem Parser'ın okuduğı kanalı kapatıp gerekiyorsa tekrar açmak
2.2 Genel Sıkıntılar - Parser'ın Çıktısını İşleyen Kod
Parser'ımız Composite döndüğü için bu kanalı dinleyen kod parçasına herşey geliyor. Yani Wireshark'tan Ethernet + IP + TCP + Data almak gibi. Ancak kod parçamız sadece Data ile ilgileniyor. Dolayısıyla kodumuzun Composite içinde yürüyerek işlemek istediği düğümü bulması gerekiyor.
2.3 Parser'ın Okuduğu Kanal İle Kod Parçasına Kadar Olan Tasarım
2.3.1. Event Driven Processor
Bu seçenek şöyle
Poller -> Stream Buffer (Kanal)-> Parser -> Processor (Kod Parçası)
Burada karşımıza yine iki seçenek çıkıyor. Poller'a ayrı ayrı kanallar takmak veya tek bir kanal takıp kanalın ucunda Parser'lara göre ayrıştırmak.
Aralarında çok fark yok. Tek dikkat edilmesi gereken köprüyü yani kanalı kapatırken önce Poller ucunu daha sonra Processor ucunu kapatmak. Ya da tam tersi yeterki tutarlı olsun :)
2.3.1. Pulling Processor
Bu seçenek şöyle
Processor -> Channel'dan okur -> Parser'a verir ve çıktıyı işler.
Bu seçenek Processor sayısı fazla ile çok thread'e sebep olduğu için tercih edilmiyor.
Hiç yorum yok:
Yorum Gönder