Servicebus nedir ve ne zaman ihtiyacım olur?


101

NServiceBus hakkında konuştuğumu duydum , ancak ne olduğunu tam olarak anlamadım. ".Net için en popüler açık kaynaklı servis veri yolu" olduklarını iddia ediyorlar.

Yani; "servis otobüsü" nedir ve ne zaman ihtiyacım olur?


Partiye gerçekten geç kaldım, bunu cevap olarak göndermeyeceğim çünkü öyle değil ama kısaca, neden birine ihtiyacın olduğunu bilmiyorsan o zaman şansın yok ... belirli bir sorunu çözüyor uygulamaları bağlama ve işletmenize merkezi bir API sağlama konusunda muhtemelen sahip olmadığınız sorun.
Savaş

9
@Wardy İfadene katılmıyorum. Bir şeyi anlamamanız veya ne olduğunu
Cristian Toma

Bu cehalet için bir bahane değildi, ancak daha çok, servis otobüsünün çözdüğü türden bir soruna rastladığınızda çok fazla atılan bir terim olduğuna dikkat edin, böylece ya ihtiyacınız olacak ya da olmayacak ve bu nedenle asla endişelenmenize gerek kalmayacak. o.
Savaş

Bir düzenleme olarak eklersiniz ama temelde NServiceBus şimdi "Özel Servis Platformu" olarak bilinir ve bulunabilir ... soru değiştirecek particular.net (Neyse şimdi nereye NServiceBus.com yönlendirmeleri olan).
Dan Atkinson

Zaten var olan bir şeyin adını veya kavramını bilmiyorsanız, kişi muhtemelen kendi yazacaktır. Bu yüzden onları tanımak güzel, böylece onları kullanabilirsin (gerekirse)
noelicus

Yanıtlar:


80

Bir servis veri yolunu SOA'nın Ethernet'i olarak düşünebilirsiniz.

Birincisi ve en önemlisi, Ethernet'teki bir IP adresi gibi şeyleri tanımlayan bir dil sunar. Bu isim doğası gereği fiziksel bir şey değil.

Daha sonra, yarı bağlantılı iletişimi desteklemek için bir veri yolu durumunda bir sıra veya metafordaki bir Ethernet kartı gibi her düğümde fiziksel bir şey var.

Fizikselin ötesinde, Ethernet için OSI yığını gibi iletişimin "protokol" kısmı vardır. Veri yolu ile bu, uygulama kodu tarafından kullanılan istemci kitaplıklarıdır.

Nihayetinde, bir servis veri yolunu, dağıtılmış sistemler oluşturmak için bir sonraki daha yüksek düzeyde soyutlama sağlayan olarak görebilirsiniz. Bunu, size tek yönlü kalıcı mesajlaşma sağlamak için istemci-sunucu iletişimi için ve sunucunun bildirimleri istemciye geri göndermesi için de kullanabilirsiniz.

Özellikle, NServiceBus'un, seçtiğiniz RabbitMQ, MSMQ, Regular SQL Tables, Amazon SQS, Azure Storage Queues ve Azure Service Bus olan kuyruklama teknolojisinin kullanımıyla barıştıktan sonra oldukça hafif ve kullanımı kolay olduğunu göreceksiniz.


Teşekkürler! Sanırım büyük resmi şimdi anladım! Aslında bu soruyu bu gece yapacağınız seans için biraz hazırlıklı olmasını
istiyordum

12

Enterprise Service Bus için Wikipedia makalesine göz atın .

Bir Servis Veriyolu, iyi bir Servis Odaklı Mimari uygulamak için hiç bitmeyen arayışta bir başka soyutlama katmanı görevi görür. Servis Veri Yolu, Mesajlaşma, Yönlendirme ve Servis Koordinasyonu gibi iyi bir Servis Odaklı Mimarinin arkasında görülen ağır yüklerin bir kısmını halledebilir.

Neden böyle bir şey isteyeceğinizden emin değilseniz, iyi bir Servis Odaklı Mimari'yi neyin oluşturduğunu okumayı öneririm. Gözlerimi gerçekten açan ve sadece Web Servislerine sahip olmak ile gerçek bir Servis Odaklı Mimariye sahip olmak arasındaki farkı kanıtlayan kitap, Thomas Erl'in Servis Odaklı Mimari: Kavramlar, Teknoloji ve Tasarım'dı.


Yani bir masaüstü istemci uygulaması ile bir sunucu arasındaki iletişimi yapmak için kullanabilir miyim? Sunucunun kurum içinde olduğu yer, yani.
stiank81

Yapabilirdiniz. Ayrıca, farklı hizmetler, farklı hizmetlerin farklı sürümleri vb. Arasında iletişim için de kullanabilirsiniz (hizmetlerin farklı protokoller kullandığı durumlar dahil).
Justin Niessner

11

Bu terim ile tanıtıldı SOA ait (vızıltı kelime olarak) bir şekilde halefi olduğunu EAI .

İhtiyacın olduğu zaman? Bu iyi bir soru. Çok fazla karmaşıklıkla geliyor.

Temel bir kural, neden olduğundan daha fazla sorunu çözerse çözebilir.

Heterojen bir ortamınız varsa ve uygulamaları (farklı teknolojiler kullanarak) iş süreçleriyle uyumlu hale getirmek istiyorsanız ciddi olmak. O zaman orkestrasyon ve koreografi için BPEL kullanmak faydalı olabilir (ancak bu geçişle ilgili sorunları ortaya çıkarır )

DÜZENLEME: Wikipedia'da olmayan şey pratiktir: Bir ESB, birlikte çalışabilirlik anlamına gelen Corba veya Java Enterprise ile kullanım için özel konektörleri, eski terminal uygulamalarını kullanarak uyarlayabilir. Dezavantajı, çok fazla çaba sarf etmeden işbirliği yapmayan SOAP etrafındaki 100'den fazla 'Standart' olmasıdır.

2 büyük güvence şirketinin birleşmesinden sonra altı ay içinde BT sistemlerini birbirine bağlamanız gerekiyorsa kesinlikle buna ihtiyacınız var.


Öyleyse - sunucu tarafı ile "basit" bir iletişimi olan masaüstü uygulamamda, bir Servis Veriyolu ile büyümeye gerek yok mu? Sunucudan bir itme modeli uygulamama yardımcı olabilir mi? Yoksa bu senaryoda da kazançtan çok acı olacak mı?
stiank81

@ stiank81 özür dilerim (Enterprise) servis veriyolunu okudum ve sinapslar ateşlendi. NServiceBus'a olan bağlantınızı kontrol ettim, onlar aynı şeyi hedefliyor, bir istemci sunucu uygulamasında böyle bir şeye ihtiyacınız yok. Konsept ile tek bir iş sürecine dahil olan birden fazla uygulama için kastedilmektedir. Senin için işe yarayacaksa? Sebep olduğundan daha fazla sorunu çözerse.
Stacker

"Sebep olduğundan daha fazla sorunu çözerse" kullanın ... sevin.
noelicus
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.