Web Servislerine Dayalı Tıbbi Cihaz Tak ve Çalıştır Mimarisi Konsepti
ÖZET
Tıbbi cihazların birlikte çalışabilirliği hala bir sorun. Standartlar yalnızca HL7 ve DICOM gibi belirli alanlarda mevcuttur veya semantik düzeyde alan bilgisi modeli hariç ISO / IEEE 11073 gibi yaygın olarak kabul edilmemiştir. Semantik altındaki birlikte çalışabilirliği kapsayan bir yaklaşım önerilmektedir. Tıbbi cihaz uygulama alanı dışında yaygın olarak kabul gören web servislerine dayanmaktadır. Özellikle, mimarlık yaklaşmakta olan İnternet Hizmetleri R aporu (DPWS) üzerine kurulmuştur. Hizmet keşfi, yüzey açıklaması, olay bildirimi ve güvenlik için mevcut Web hizmetleri spesifikasyonlarının bir toplamıdır. Kaynak kısıtlı cihazlar için tasarlanmıştır ve bu nedenle medikal tak ve çalıştır cihazı içib uygun gibi görünmektedir.
GİRİŞ
Birlikte çalışabilirlik, “iki veya daha fazla sistem veya bileşenin bilgi alışverişinde bulunma ve değiştirilen bilgiyi kullanma kabiliyeti” olarak tanımlanmaktadır [6]. Lesh ve ark.na [8] göre, birlikte çalışabilirlik sürekliliği, fiziksel birlikte çalışabilirliğin en karmaşık son noktasından, veri ile birlikte çalışabilirliğin en karmaşıklığına kadar uzanmaktadır. Veri ile birlikte çalışabilme yeteneğini sağlamak için sadece bir hata olmadan bilgi alışverişi yapma yeteneği değil, bilgilerin algoritmada kullanılması için doğru yorumlanması gerekir. Tıbbi cihazların birlikte çalışabilirliği, veri odaklı klinik karar destek algoritmaları veya tıbbi cihaz güvenlik kilitleri ile geliştirilmiş hasta güvenliği arasında daha az geliştirme zamanı aralığındadır. MD PnP Birlikte Çalışabilirlik programı [10] veya IHE PCD [7] gibi birçok girişim de bu soruna hitap etmektedir.
ISO / IEEE 11073, birlikte çalışabilirlik sorununu ele alan olgun bir standarttır. Özellikle sağlanan etki alanı bilgi modeli sıklıkla kullanılmakta ve tıbbi cihazların semantik düzeyde veri alış verişinde bulunmalarını sağlamaktadır. Alt katmanlar karmaşıktır ve EtherNet veya TCP / IP gibi güncel teknolojileri desteklemez.
MediCAN, McKneely ve ark. Tarafından önerilen bir çözümdür. [9] ve UDP / TCP’nin yanı sıra CAN-Bus üzerine kurulu tescilli protokollere dayanan tıbbi cihazları arayüz için satıcının bağımsız bir ağ mimarisi olarak tanımlanmaktadır. Cihazlar arasında doğrudan bir iletişim yoktur ve kapalı tıbbi cihaz ağı için bir proxy sunucusu tarafından kontrol edilir.
Bir başka yaklaşım, özel amaçlı CANopen cihaz profilleri kullanarak OEM bileşenlerinden inşa edilmiş görüntüleme sistemleri bileşenleri arasında birlikte çalışabilirlik sağlamaktır. Akut bakım sistemlerine yönelik bir CANopen tabanlı uygulama profili de bulunmaktadır [25].
Hizmet odaklı Mimarlık
Hizmet odaklı mimariler (SOA) fikri iş ortamından gelmektedir. Orada bilgisayar sistemlerinin çalışması ve bakımı karmaşıktır ve bu nedenle çok masraflıdır. İş süreçleri her değiştiğinde, yeni bilgisayar sistemlerinin mevcut altyapıya entegre edilmesi gerekir. Çoğu zaman, bu yeni bilgisayar sistemleri yeni arayüzlere sahiptir ve eski sistemler ile entegrasyon sorunludur.
Şekil 1: SOA’da tüm hizmetler ortak bir mesajlaşma omurgası üzerinden birbirleriyle iletişim kurar. Bu soyut omurgayı gerçekleştirmek somut SOA’nın uygulanmasına bağlı. Örneğin bir ağ veya merkezi bir iletişim sunucusu olabilir.
Şekil 2: Hizmet odaklı bir mimaride birbiri ile olan etkileşimdeki üç önemli rol
Bir SOA, “servis” olarak adlandırılan, tüm sistemler için yeni ve standartlaştırılmış bir arayüz teknolojisi getirerek bu sorunu çözer. Tüm hizmetler artık Şekil 1’e göre ortak bir mesajlaşma omurgasında servis arayüzü ile iletişim halindedir.
Bir SOA, belirli bir teknolojiyi dikte etmez, sadece böyle bir mimari oluşturmak için bir kavramdır. Şekil 2, üç temel rolle bu kavramı göstermektedir: servis sağlayıcı, servis kayıt defteri ve servis tüketici. Bir servis sağlayıcı, servis tanımını bir servis kayıt defterine yayınlar. Ardından, bir hizmet tüketici kayıt defterinde ilgili bir hizmeti bulabilir. Daha sonra, hizmet tüketici, söz konusu hizmeti kullanmak için hizmet sağlayıcısına bağlanır.
Web hizmetleri, İnternet teknolojileri ile bir SOA’nın gerçekleştirilmesidir [15]. Web servislerinin diğer SOA çözümlerinden farklı olarak faydası, bilinen teknolojileri kullanması ve bir satıcı kilitlenmesinden kaçınılmasıdır.
Web servislerinin oluşturulduğu temel ve yaygın kabul gören standartlar SOAP [23] ve Web Servis Tanımlama Dili (WSDL) [22] ‘dir. SOAP, XML tabanlı ileti aktarım biçimi iken, WSDL rol modelindeki hizmet açıklamasını kapsar. Birlikte WSDL ve SOAP, hizmet sağlayıcının ve hizmet talep eden kişinin rollerini kapsar.
Kayıt defteri rolü bu iki standart tarafından kapsanmamaktadır, ancak Evrensel Tanımlama Bulma ve Bütünleştirme (UDDI) [14] tarafından böyle bir kayıt için bir arabirim belirtilmektedir. Bununla birlikte, standart WSDL ve SOAP olarak o kadar yaygın kabul görmemektedir. Bunun nedeni, bir global hizmet kaydı oluşturmak için UDDI’nın arkasında yatan ana fikrin başarısız olması gerçeğidir.
İlk Mimari Kavramları
Alman Federal Eğitim ve Araştırma Bakanlığı tarafından finanse edilen FUSION projesinde geliştirilen mimari, bir SOA gerçekleştirmek için Web servisleri üzerine kurulmuştur. İki yaklaşım ele alınmıştır: tam merkezileştirilmiş ve daha merkezi olmayan bir yaklaşım. İkincisi, tek bir başarısızlık sorununu ve performans sorunları nedeniyle üstesinden gelmek için.
Merkezi yaklaşım, senkron ve asenkron mesajların güvenilir taşınması ve izlenebilirliği için ortak bir veri merkezli ara katman yapısı sağlamak için bir kurumsal servis veri yolu (ESB) kullanmaktadır [19]. Dağıtılan yaklaşım merkezi bir yapıya değil, Web hizmet alanındaki standartlara daha fazla bağımlıdır. Hizmet araştırmaları UDDI sunucusu tarafından gerçekleştirilir. Bir sağlayıcıya ait web hizmetleri, doğrudan bir tüketici tarafından, ESB aracılığıyla talep / yanıt gönderilmeden çağrılır. Ayrıca, olaylar WS-Eventing belirtimi kullanılarak nakledilir: noktadan noktaya veya bir etkinlik komisyoncusu aracılığıyla. Çoğu durumda, olay güvenlik açısından kritikse ve merkezileştirilmiş bir etkinlik brokerı yoluyla gönderilemiyorsa, noktadan noktaya olay bildirimi kullanılacaktır. Bu yaklaşım, temel hizmet bileşenlerinden birinin çökmesine rağmen, daha esnek olmayı, daha az yapılandırmayı ve – cihazlar arasındaki iletişimin en önemlisi – bozulmamasını sağlar. Anlamsal etkileşim açısından, her iki yaklaşım da hemodinamik ve solunum verileri için ISO / IEEE 11073 alan bilgisi modeli ve ADT verileri için HL7 temelli bir XML sözlüğü kullanmaktadır.
Her iki çözümde de problem, merkezi yapıların kullanılması ve dolayısıyla tek bir hata noktasının yanı sıra ölçeklenebilirlik sorunlarının ortaya çıkmasıdır. Dahası, medikal cihazların yapılandırılması için bazı ekipm ortadan kaldırılmalı ve bu sayede tak ve çalıştır hissi ortaya çıkmamaktadır.
Bu nedenle, yerel olarak merkezi olmayan ve yalnızca alt ağ sınırları üzerinden iletişim gerekiyorsa, merkezi bileşenlere ihtiyaç duyan mevcut Web hizmeti standartlarına dayanan bir mimari sunulmuştur. Bu kavram aşağıdaki bölümde açıklanmaktadır.
ÖNERİLEN ARAŞTIRMA
Tıbbi cihaz bağlantısının mimari önerisi, keşif, arayüz açıklaması, mesajlaşma, olay yayılımı ve güvenli bilgi aktarımı için hizmetleri tanımlayan yakında çıkacak olan Web Hizmetleri Cihazları Kıyaslaması (DPWS) standardını [11] kullanmaktadır. Araya getirilebilirliğin anlamsal yanını tanımlamak önerilen mimarinin kapsamı dışındadır. Bu, HL7 veya ISO / IEEE 11073 gibi olgun standartların veri modelleri kullanılarak ele alınabilir.
Haziran 2009’da bir OASIS standardı haline gelen DPWS, kaynak kısıtlamalı cihazlar için az sayıda Web hizmetleri spesifikasyon setidir. Web hizmetlerinin keşfedilmesini ve tanımlanmasını ve olay yayılımı olasılığını içerir. DPWS’nin kökleri, modern ağ yazıcılarında veya görüntü tarayıcılarında tak ve çalıştır kullanılmasına izin verilen tüketici elektroniği alanındadır. Özetlemek gerekirse, DPWS, USB’nin seri bağlı aygıtlar için yaptığı gibi, tüketici elektroniği için Ethernet için aynı kullanımı kolaylaştırır. Gelecekte yazıcı entegrasyonu için Microsoft tarafından ileriye götürülür ve sonuç olarak Microsoft Windows Vista, Windows Server 2008 ve Windows Embedded CE 6.0 R2’nin yerleşik bir DPWS yığını (WSDAPI) vardır.
Önerilen mimarinin hizmetleri aşağıda ayrıntılı olarak ele alınmaktadır.
Dinamik keşif
Web Hizmetleri Dinamik Bulma (WS-Discovery) [13] bir hizmet yerelleştirme protokolüdür ve DPWS standardizasyon süreci kapsamında standartlaştırılacaktır. Varsayılan olarak, herhangi bir yapılandırma olmaksızın geçici modda çalışır. Bu nedenle, aynı alt ağ içindeki tüm hizmetlere erişmek için önceden tanımlanmış bir çok noktaya yayın grubu kullanır. Multicast, temel alınan ağın veriyi abone olunan tüm düğümlere dağıtan bir iletim modudur. Bulma işlevselliği, SoHo (Küçük Ev Sineması) aygıtlarında veya ev ağlarında müzik ve video dağıtımı yapan medya merkezi sistemlerindeki muhtemel bilinen keşif prosedürüne benzer. Yönetilen modda, keşif işlemi, tüm bilgileri önbelleğe alan keşfedilen proxy olarak adlandırılan merkezi bir bileşen kullanır. Bu proxy ile keşif işlemi, çok noktaya yayın kullanımının geçici modun aksine minimuma indirgendiği için, daha büyük sayıda uç noktaya ölçeklenir.
Geçici modun merkezi olmayan yapısı, tıbbi aygıtların uygulama alanı için geçerlidir, çünkü tek bir hata noktasından kaçınılmaktadır. Halihazırda etkileşimli aygıtların dışındaki ağ hataları durumunda sağlam bir keşif sistemine sahip olmak önemlidir. Bir ameliyathanedeki tıbbi cihazlar, örneğin, odalarının dışında şebeke arızaları olması durumunda iyi çalışmalıdır. Bu senaryo, keşif için tek bir merkezi kayıt defteri yasaklamaktadır.
WS-Discovery’de hizmet sağlayıcılar ağa katıldıklarında kendilerini duyurarlar. Aynı tüketicinin periyodik olarak aynı hizmette yoklamasına gerek bırakmaz. Bu özellikle, mevcut servis listelerini otomatik olarak güncellemek veya şebekede yeni bir servisin görünmesi durumunda doğrudan yanıt vermek mümkündür.
Şekil 3’te iki keşif prosedürü gösterilmektedir. Birincisi, servis sağlayıcı başlatılırken sol taraftaki servis tüketici zaten çalışıyor. Hizmet tüketici, o hizmet sağlayıcının merhaba duyurusunu alır ve dolayısıyla, yeni hizmetleri periyodik olarak aramak zorunda kalmadan doğrudan etkileşimi başlatabilir. Sağdaki servis tüketici ile birlikte ikinci keşif dizisinde servis sağlayıcı tüketiciden önce başladı. Böylece, tüketici merhaba duyurusunu cevaplamadı ve o hizmeti aramak zorunda kaldı.
WS-Discovery, tek bir alt ağ içinde kullanılmak üzere tasarlanmıştır. Çok noktaya yayın duyuruları ve arama istekleri çok iyi ölçeklendirilmemiştir, çünkü tüm mesajlar ağdaki tüm WS Bulma düğümlerine gönderilmelidir. Ayrıca bu belirtim, kullanımı tek bir alt ağla sınırlar. Dolayısıyla, bu spesifikasyon, işletme veya hastane ağlarında kullanım için pratik görünmemektedir. Böyle büyük ağlarda, hizmetleri keşfetmek için merkezileştirilmiş bir bileşene sahip olmak çok daha elverişlidir.
Bir yandan merkezi olmayan çok noktaya yayın keşfinin güvenilirliği, diğer yandan kurumsal çapta bir keşif gereklidir. Bu çatışmayı çözmek için bir yaklaşım, her iki türevin birbiriyle kombinasyon halinde kullanılmasıdır. Yönetilen mod için WS-Discovery, keşif proxy’si olarak adlandırılır. Başlangıçta, mevcut tüm bilgileri yerel hizmet sağlayıcılardan önbelleklemek ve aynı alt ağdaki hizmet tüketicilerinden gelen arama isteklerine yanıt vermek için kullanılır. Alt ağlarda çok noktaya yayın trafiğini azaltmak için bu bulma proxy’sini kullanmak yerine, mevcut alt ağın dışında – hastane genelindeki hizmetleri aramak için merkezi bir bileşen olarak kullanılabilir. Bir UDDI sunucusu yerine bir WS-Discoveryproxy sunucusu kullanmanın faydası, keşif işleminin mimari için daha tutarlı olmasıdır.
Önerilen uygulanabilir 2 katmanlı bulma mimarisi [17] Şekil 4’te gösterilmiştir. WS-Discovery uyumlu, bir alt ağda bulunan merkezi olmayan çok noktaya yayın keşfi, ağ hatalarına karşı mümkün olduğunca sağlamdır. Servis sağlayıcı ve tüketici arasındaki bir ağ bağlantısı bulunması yeterlidir. Pratik olarak bu, hiçbir sınırlama değildir, çünkü iki hizmet daha fazla iletişim kuramaz. Tüm ağdaki hizmetleri keşfetmek için merkezileştirilmiş bir vekil proxy sorgulamak gerekir.
Merkezi keşif proxy’sine ulaşmak için farklı yaklaşımlar mümkündür. [17] ‘de, keşif proxy sunucusunun IP adresini servis tüketicilerine aktarmak için DHCP protokolü kullanılır. DHCP sunucu tarafında satıcıya özgü veriler ekleme imkânı sağlar. Daha sonra DHCP istemcileri bu verileri isteyebilir. Başka bir yaklaşım [16], ana ad sistemini kullanmaktır. Burada, istemci sunucuları, keşif proxy’sinin IP adresini sorgular. DNS tabanlı özüm platformu bağımsız olarak uygulamak daha kolay bir avantaja sahiptir ve tüm alt ağ sınırlı DHCP sunucuları yerine sadece bir ad sunucusunda yapılandırılmalıdır.
Etkinliğe Dayalı Mimari Kavramları
Web hizmetleri, bir istemcinin Web servis sağlayıcısından bir hizmet istediği ve yanıt aldığı tipik istek-yanıt senaryoları ile başladı. Bunun tipik bir örneği, bir müşteri için bir uçuş ve otel rezervasyonu yapılması gereken seyahat acentelerindeki davaları kullanmaktır. Bu senaryoda olaylar göz ardı edilir.
Tıbbi uygulama alanında çok sayıda iletişim olaya dahildir. Örneğin, alarmlar gönderildi ve gerçek zamanlı veriler iletilir. Bunun anlamı, cihaz kontrolü için tipik talep-yanıt modeline ek olarak, yayın-abone olmak için desteklenmesi gerektiği anlamına gelir.
IP tabanlı ağlarda genel olarak yayınlama aboneliği için iki farklı çözüm bulunur. İlki her abone için ayrı bir noktadan noktaya bağlantı kullanır; Ikinci çözüm UDP çoklu yayın kullanarak alttaki ağın işlevselliğini kullanır.
N abone için n noktadan noktaya bağlantılar içeren ilk çözüm için farklı şirketler tarafından itilen farklı web hizmetleri spesifikasyonları mevcuttur:WS-Eventing (Microsoft) [1], WS-Bildirimi (IBM) [5] ve WS-Olaylar (HP) [2]. Mart 2006’da, mevcut spesifikasyonları uyumlu hale getirmek için ortak bir bildiri yayınladılar [3]. Olay yayılımı için WS-Eventing üzerine kurulan ve gelecekte belirtilmesi gereken WSEventNotification olarak adlandırılan yeni bir tanımlama ile sonuçlanır. WS-Eventing’i kullanmak için en iyi uygulamalar gibi görünüyor. DPWS standardında da referans olarak görülüyor. WS-Eventing’de olay kaynağı, abonelik yönetimini ve başka bir Web hizmetine olayların dağıtımını devredebilir. Bu, olay kaynağının listeyi tüm aboneliklerle birlikte ele alamadığı veya kullanmaması gereken senaryolar için pratiktir.
Şekil 3: İki keşif prosedürü için WS-Discovery sekans diyagramı: Sol taraftaki tüketici duyuruları beklerken sağdaki servis tüketici hizmetleri arar.
Şekil 4: İki farklı keşif katmanı: Aynı ağda hizmetler merkezi olmayan olarak bulunabilirken, ağın tamamında alt ağ sınırlarını aşmak için merkezi bir düzen gereklidir.
İkinci çözüm, alttaki ağın çok noktaya yayın işlevselliğine dayanır. Bu durumda, mesajlar UDP çoklu yayın yoluyla gönderilir; bu, yayıncıdan çok noktaya yayın adresine yalnızca bir mesaj iletmesine neden olur. Alıcılara dağıtım, ağ yönlendiricileri tarafından yönetilir. Çok noktaya yayın, gruptan bu tür dağıtım senaryoları için tasarlanmıştır, bu nedenle noktadan noktaya iletimden daha iyi derecelendirilmiştir. Web servislerinde çok noktaya yayınlı mesajlaşma uygulamak için gerekli şart, SOAP-over-UDP [12] olup DPWS’nin OASIS standardizasyon sürecinde de bulunmaktadır.
Güvenlik
Hassas veri ve kontrol komutları için bilgi güvenliği önemlidir. Tıbbi cihaz bağlantısı veri bütünlüğü bağlamında, gizlilik, uygunluk ve reddedilme riski yönetimi açısından ilginçtir.
Veri bütünlüğü, verilerin geçerliliğine işaret eder. Bütünlük kasten veya yanlışlıkla zarar görebilir. Uygunluk, verilere yalnızca erişime yetkili olanlara erişilebileceği anlamına gelir. Kullanılabilirlik, amacına hizmet etmek için gereken tüm bilgileri içeren bir sistemi ifade eder. Tıbbi cihazların birlikte çalışabilirliği bağlamında, doğru bir şekilde çalışan bir iletişim kanalına sahip olmak önemlidir. Bir itirazdaki bir tarafın gönderdiği bir mesajı reddetmesini sağlamak için reddedilme gereklidir. Bu kontrol komutları için ilginç olabilir.
Bilgi güvenliği ulaştırma katmanı üzerinden veya mesaj seviyesinde başarılabilir. Aktarım katmanı güvenliği için uçtan uca iletişim için güvenli bir kanal kurulur. Bu güvenli kanal, her iki uç nokta başında birbirini yetkilendirdiği sürece veri bütünlüğü ve doğruluğunu sağlar. HTTPS, SSL’ninardıllığı olan TLS (Aktarım Katmanı Güvenliği) protokolünü kullanan bir aktarım katmanı güvenliği örneğidir (SecureSocketLayer) [4].
Mesaj katmanı güvenliği için, güvenli bir kanal üzerinden güvensiz mesajlar göndermek yerine her mesaj güvenlidir. Mesaj seviyesi güvenliğinin faydası mesajın güvenli olmayan düğümlerden geçebilmesidir. Ayrıca, dijital imza kullanan mesaj seviyesinde reddedilemez. Bu durumda, imzalanmış mesajlar daha sonra mesaj iletiminin kanıtı olarak kaydedilmelidir Ancak, mesaj seviyesi güvenliği, taşıma katmanı güveninin aksine daha karmaşıktır.
Taşıma ve mesaj güvenliği için, PKI (genel anahtar altyapısı) tıbbi cihaz kimlik doğrulamasında temel bir gerekliliktir. Kullanıcı adı ve parola ile merkezi bir yaklaşım uygulanamaz. Tak ve çalıştır özellikleriyle çelişir, tek bir başarısızlık noktasını getirir ve yine de sunucuyu istemcilere kimlik doğrulaması yapmak için bir sertifika gerekir.
Web hizmetleri için kullanılabilirlik, temel ağa bağlıdır. Ethernet, önceliklendirmeyi destekleyen en iyi deneme ağıdır. Her neyse, sosyal olmayan davranışa sahip bir ağ düğümü diğer veri aktarımını bozabilir ve önemli veri paketleri aşırı yüklü anahtarlarda düşebilir. Sert gerçek zamanlı kısıtlamalar için tescilli Ethernet modifikasyonları mevcuttur. Bunlar Web servisleriyle uyumlu değildir. Normal Ethernet ve mülkiyete ait çözümler arasında bir tradeoff, adil bir şebeke anahtarı olabilir [18], gönderilen düğümler arasında mevcut veri oranını eşit olarak paylaşır. Böylece, sosyal olmayan düğümlerin eforu azaltılır ve minimum bir veri hızı garanti edilebilir.
İLK FİZİBİLİTE DEĞERLENDİRMELERİ
İlk fizibilite değerlendirmeleri, standart bilgisayar donanımı üzerinde demo programı ile yapılmıştır. WSEventing için birden fazla noktadan noktaya iletim için deneyim kazanmak için birkaç performans ölçümü yapıldı. Bunlar, hata ayıklama / günlüğe kaydetme özelliğine sahip DPWS araç setleri WS4D-gSOAP ve WS4D-JavaME [24] ile yapıldı. Sonuçlar Tablo 1’de özetlenmiştir.
Performans ölçümleri bir WS4D-gSOAP cihazı için gösterildi; bir WS4D-gSOAP dinleyicisi için etkinliği iletmek ve bir onay almak için 3,0 ms sürüyor. İki dinleyiciye olay 5.7ms sonra verilir. Bu sefer yalnızca dinleyicilere bağlı olan cihazların uygulanmasına bağlı değildir. WS4D-JavaME araç seti ile uygulanan bir Java dinleyicisi için, WS4D-gSOAP dinleyicisiyle birlikte 3.0ms yerine 3.8 ms sürmüştür.
Tablo 1: WS-Eventing’e göre farklı araç setleri için olay dağılımı için örnek performans sonuçları
Tablo 2: WS4D-gSOAP’taki normal mesajlar ve PC donanımında diğeri yükler için dijital imza içeren mesajlar için serileştirme yükü
Özellikle mesaj seviyesi güvenliği için yükü ölçmek için WS4D-gSOAP araç seti kullanılmıştır. Dijital imzaları destekleyen gSOAP araç kiti için eklenti [20] ‘dir. Tablo 2, hata ayıklama günlüğü varsayılan olarak etkinleştirildiğinde, farklı seri senaryolarda seri hale getirme süresi için ilk sonuçları özetlemektedir. İkinci sütundan, SOAP zarfı ve DPWS uyumlu SOAP üstbilgisi için yükün 1.3ms sürdüğü sonucuna varılabilir. Ek bir tamsayının seri hale getirilmesi sadece 22 μs alır. Üçüncü sütunda bir SOAP mesajının tüm gövdesi, 1024 bitlik bir RSA anahtarı ve SHA1 hash algoritması ile WS-Security’ye göre imzalanır. RSA anahtarı sertifikası, bu senaryoda alıcının zaten bildiği için dahil değildir. İmzalanan bir SOAP mesajında ek bir tam sayı 122 μs alır, bu da imzasız mesaja göre ek yükün 5 ila 6 katıdır. Bu yük, sadece imza prosedüründe SHA1 karma işleminden kaynaklanmaktadır. Son sütundan, gömülü bir belgenin seri hale getirme ve karma işlemi için 2 ms’lik bir masrafa neden olduğu sonucuna varılabilir.
Van Engelen ve ark. [21], güvenlik ek yükü ile ilgili performans ölçümleri yapmıştır. HTTPS iletimlerini simetrik ve asimetrik mesaj seviyesi güvenliği ile karşılaştırdılar.
SONUÇLAR
Tak ve çalıştır mimarisi konsepti tanıtıldı. Geçerli Web hizmetleri standartlarını temel alır ve birlikte çalışabilirliğin teknik katmanlarını kapsar. Bir altyapı mimarisidir ve dolayısıyla anlambilim kapsam dışındadır ve mevcut standartlar kullanılmalıdır. Diğer aygıtları keşfetmek için, mevcut alt ağ dışındaki hizmetlere erişme imkânı sağlamak için geliştirilmiş bir WS-Discovery sürümü kullanılır. Olay yayılımı için iki farklı çözüm WS-Eventing ve SOAP-over-UDP multicast birden fazla avantaj ile birlikte bulunur. Bilgi güvenliği, taşıma katmanında olduğu kadar ileti düzeyinde de geçerlidir. İlk performans testleri, Web servislerinin kullanımından kaynaklanan bir zamanlama yükü gösterdi. Emniyet nedenlerinden ötürü güvenlik gerekiyorsa, tabii ki kaçınılamayacak ek bir ek yük getirir.
TARTIŞMA
Tıbbi başvuru alanında, önerilen DPWS tabanlı mimari aygıt bağlantısının temelini oluşturuyor gibi görünüyor. Farklı satıcılardan gelen cihazlarla tam tak ve kullan yetenekleri elde etmek için tasarlanmıştır. Kaynak kısıtlı cihazlarda ve üst düzey bilgisayar sistemlerinde çalışır. Genel olarak Web hizmetleri, muhtemelen en çok araç desteğine sahip olan bir SOA için en geniş kabul görmüş yapı taşlarından biridir. Bunun sebepleri, muhtemelen platform ve programlama dili bağımsızlığı ve HTTP gibi bilinen İnternet teknolojilerinin kullanımı ile kombinasyonudur.
Tıbbi cihaz bağlantısı için Web servislerinin performansıyla ilgili bazı çekinceler olsa bile. Gerçekleştirilen ölçümler, düşük iletim gecikmesine ihtiyaç duysalar bile iletişim için kullanılabileceğini göstermektedir.
Olay ve gerçek zamanlı veri yayılımı için SOAP-over-UDP çok noktaya yayın, mevcut Web hizmetleri standartlarının üstünde gerekli işlevleri eklemeye çalışan WS-Eventing’in aksine, çok noktaya yayın bu amaçlar için tasarlandığından daha iyi ölçeklendirilmelidir. WSEventing için örnek ölçümler bu varsayımı destekler. Gecikme, dinleyicinin uygulanmasına ve gönderenin planlama stratejisine bağlıdır. Bir aygıtlar perspektifinden, dinleyici uygulaması etkilenemez. Gönderen dinleyiciyi sırayla veya eşzamanlı olarak bilgilendirebilir. Mesajları sıralı olarak iletirken, son abone dinleyiciye büyük bir gecikme ile bildirilir. Bunun aksine, birden çok iş parçacığı gerektiğinden, programlı olarak eşzamanlı iletim daha pahalı bir kaynaktır.
Ayrıca, UDP çoklu yayınının bir dezavantajı var. Güvenilir bir taşımayı desteklemez. Aktarılan tüm verilerin dinleyiciye ait olduğu kabul edilir. Bu nedenle, WS-Eventing ve SOAP-over-UDP çok noktaya yayın arasındaki karar bir Web servisi için özel bir karar değildir.
Her neyse, her iki durumda da en büyük sorun şudur: Başarısız yayınlarla ne yapılacağı? Onları kuyruklayın ve x dakika sonra deneyin veya bir olayı unutup tekrar deneyin. Bütün bu farklı yönler, hangi özümün daha pratik olabileceği özel olaya (yani, alarm veya gerçek zamanlı veri) bağlı olduğu sonucuna götürür.
Bilgi güvenliğinde bu karar daha da karmaşıktır. Van Engelen ve arkadaşları [21] mümkün olduğunda HTTPS’i kullanmayı öneriyorlar çünkü mesaj seviyesinde güvenlik daha iyi performans gösteriyor. İleti seviyesi güvenliği gerektiren çok noktaya yayın iletilerinin yapısı nedeniyle yalnızca HTTPS’yi WS-Eventing ile birlikte kullanmak mümkündür.
Önerilen sistem gibi merkezi olmayan bir tak ve çalıştır mimarisi, mevcut altyapıya düzgün bir şekilde geçiş yapmanın en iyi ihtimali olabilir, çünkü karmaşık bileşenler gerektirmez – iki modern cihaz yeterlidir.
Bu yazı aşağıda belirtilmiş makalenin çeviri notlarından oluşmaktadır.
Pöhlsen, Stephan, et al. “A concept for a medical device plug-and-play architecture based on web services.” ACM SIGBED Review 6.2 (2009): 6.
