ESB nedir ve ne işe yarar?

Önceki bir işte, "Kurumsal Hizmet Veriyolu" (ESB) hakkında pek çok konuşma vardı. Kavramsal bir kitabın bazı kısımlarını okudum, ancak onu nasıl somut terimlerle uygulayacağınızı / bütünleştireceğinizi asla tam olarak anlamadım. SOA / queuing / directory services / etc konusunda bilgi sahibiyim. ama ESB'nin tam olarak ne olduğunu anlamıyorum.

Tüm uygulamalarınızı ona farklı şekillerde bağlamanız somut bir şey mi (hizmet / sunucu / komisyoncu / vb.), Yoksa sistem tasarlamanın kavramsal bir yolu mu?

İyi örneklerle ilgili herhangi bir açıklama veya bağlantı çok takdir edilecektir. Teşekkürler.

Oldukça yüksek düzeyde bir soyutlama kavramı. Ana konsept, ESB'nin işletmelerin uygulamalarını kod yazmadan bağlamasına izin veren ara yazılım ve arayüzler sağlamasıdır.

Bu, uyumsuz protokolleri, verileri ve etkileşimi uzlaştırmak için arabuluculuğu içerebilir.

Her şeyin geçtiği merkezi bir otobüs fikri, ek soyutlama katmanları için fırsat verir. Diğer uygulamaları, istemcileri ve benzerlerini bu veri yoluna "takmak" için endüstri standartlarını kullanmak, yeni hizmetleri, veri kaynaklarını, farklı ihtiyaçları olan istemcileri bağlamayı nispeten kolaylaştırır.

Gerçek uygulamalar

Gerçek uygulamalara gelince, bu çok büyük kurumsal destek işletmelerinin etki alanıdır. Çok moda olsa da, amaç, küçük bir düzeyde internetle karşılaştırılarak anlaşılabilecek bir ideal:

İnternete benzerlik

Çok farklı kullanımlara ve verilere sahip tek bir büyük iletişim veri yolu, ancak tüm çalışan protokolleri standartlaştırır.

Aslında, tarayıcıların bir FTP istemcisini çağırmadan FTP sitelerine erişmesine izin veren bir HTTP'den FTP'ye bağlayıcısı yazılabilir (genellikle tarayıcıda artık yerleşiktir).

Mashup'lar

Mashup'lar ilginç bir uygulama gösterir - San Francisco otoritesinden bazı otobüs güzergah verilerini, google'dan harita ve yahoo'dan suşi bar konumlarını derecelendirmelerle birlikte alın ve size en yakın suşi çubuğunu veren basit bir sorgu çalıştırın daha iyi bir bar için biraz daha uzağa gitmeye istekli.

Tüm tamamen farklı hizmetler, kendi başlarına uyumsuz, ancak standart bağlayıcılar (örneğin yahoo borular) kullanılarak, uyumlu ve kullanışlı bir bütün halinde bir araya getirilebilirler.

-Adam

Sorumluluk Reddi: IBM için çalışıyorum ve ESB'ler oluşturmak için tasarlanmış bir IBM ürünü olan WebSphere ESB'ye danışıyorum. Aşağıdakiler benim görüşlerimdir ve IBM'in pozisyonunu yansıtması gerekmez.

ESB maalesef farklı kişiler için farklı şeylerdir.

Bana göre ESB, farklı sistemleri birbirine bağlamanıza izin veren bir SOA'ya (Servis Odaklı Mimari) ekleyebileceğiniz herhangi bir teknolojidir. Genellikle protokol dönüşümü, mesaj değiştirme, yönlendirme, günlüğe kaydetme, bir güvenlik ağ geçidi görevi görme vb. İşlevlerini yerine getirir. Örneğin, daha önce yalnızca Web Hizmeti olarak JMS tabanlı bir hizmet olarak sunulan bir hizmeti ortaya çıkarmak için bir ESB kullanabilirsiniz.

Bu açıdan, ESB uygulamaları (veya daha doğrusu, ESB'leri oluşturmak için satılan yazılımlar - danıştığım gibi), genellikle bir mesajlaşma veya kuyruk komisyoncusu olarak bilinenlere teknolojik olarak benzerdir, ancak amaç biraz farklıdır. , çünkü (kısaltmaların ima ettiği gibi) mesajları bir yerden diğerine taşımaktan ziyade hizmetlere yöneliktir. Ayrımın teknolojik olarak ne kadar önemli olduğu bir fikir meselesidir.

Ticari ESB ile ilgili deneyimim, çözdüğü kadar çok sorun yaratan aşırı ve pahalı bir teknolojidir. ESB yeni sistemleri ve mirası birbirine bağlayacak, mesajlar otobüsün üzerinden uçacak ve her şey diğer her şeyle sorunsuz bir şekilde konuşabilecek. Biraz esneklik, düzenleme ve çok güçlü bir kurumsal uygulama yazılımına sahip olun.

Sorun, onları gerçekten kullanmaya çalıştığınızda ortaya çıkar, otobüs için yazmanın ek yükü, mesaj yapılarını oluşturma vb. Faydaları ağırlaştırabilir. Yüksek maliyetli bir öğe olarak ESB, olmadığı tüm teknik sorunlar için her derde deva olarak görülüyor, bağlanan uygulamalar / verilere değil, otobüste çok fazla zaman harcanıyor. Çoğu zaman, birden fazla rekabet eden standardın aynı organizasyonda üstünlük için savaşması, bu sistemlerin aslında düzeltmesi gereken klasik teknoloji hakimiyetindeki silolara yol açmasıdır.

IMHO, tipik olarak yalnızca ihtiyaç duyan sistemler arasında web hizmetlerini kullanarak az sayıda özel arabirim oluşturmak çok daha iyidir.

Bu, temelde bir sistem tasarlamanın kavramsal bir yoludur - yazılım şirketleri, 'ESB' etiketini yapıştırarak size daha fazla satış yapmaya çalışır ve yöneticiler, bir ESB'nin 'üst düzeyden' iyi görünmesinden hoşlanır.

ESB, temelde ek bir veri modeli ve yapı tanımlama yönetimi içeren bir MOM'dur (mesaj yönelimli ara yazılım). Bu veri yolundaki tüm uygulamalar ve bağdaştırıcılar için ortak bir veri tanımınız vardır (paylaşılan bir XSD ile XML olabilir). Bağlanan her şey, bilgilerini bu veri tanımına bağlı kalarak göndermelidir * ZORUNLU *. ESB, bu ortak veri tanımının yüklenmesini, paylaşılmasını ve versiyonlanmasını destekler. Bir ESB'ye yeni bir bileşen bağlarken, bir MOM'a bağlamaya kıyasla kutudan daha fazla 'uyumluluk' bekleyebilirsiniz. Bu veriyolundaki her bileşen kavramsal olarak bir 'kaynak' olarak ele alınır - bu nedenle göndericiyi alıcıdan ayırmak için ek bir soyutlama uygulanır.

Örnek: Diyelim ki standart bir mesaj odaklı ara yazılımda A uygulamasını B uygulamasıyla bağlamak istiyorsunuz, JMS'yi ele alalım. B uygulaması üzerinde çalışan meslektaşlarınızla konuşun, bir konu, mesaj türü ve alanlar üzerinde anlaşın ve gönderin (sözde kod): sendJms ("TRADE.MSFT", {MapMessage trader = "pete" price = 101.4 vol = 100})

Aynı şeyi hizmet odaklı bir mimaride yaparsanız,

1. ek yazılım yükleyin
2. birçok yeni kavram öğren
3. ESB'nin yönetici kullanıcı arayüzünde yeni Java bileşeninizi tanımlayın
4. ESB tarafından kontrol edilen bazı arayüzleri uygulayın
5. sendJms (getDestination (), {MapMessage trader = "pete" price = 101.4 vol = 100}) - hedefin ESB'den enjekte edildiğine dikkat edin

İlk seferinde muhtemelen biraz acı verici, ama sanırım alışabilirsin, tıpkı EJB'lere alışabildiğin gibi ;-)

Bir ESB 'yazılırken' (statik yapı) MOM sisteminin 'türsüz' (dinamik yapı) olduğunu söyleyebilirsiniz. Ham Mesajlaşma ile ESB arasındaki ödünleşimler, diğer türlenmemiş / yazılan seçeneklere benzer:

• REST ve SABUN
• XSD ile doğrulanmış XML ile doğrulanmamış XML
• Groovy ve Java
• yorumlanmış dil ile derlenmiş dil

Daha küçük projeler için işlevselliğe hızlı bir şekilde hashing uygulamak güzeldir (örn. Groovy kodu), ancak daha büyük projeler için bir hata ayıklayıcıya (örneğin Java) sahip olmak, işler bozulduğunda önceden uyarılmak ve insanlar için taahhütte bulunmadan önce bir standarda sahip olmak iyidir . proje.

Öyleyse, projeniz, doğrulanmamış değişiklikleri kontrol ederek sistemi çok fazla insanın kırmasından muzdaripse - daha fazla yapıya doğru ilerleyin (MOM yerine ESB). Projeleriniz zamanında yeterince iş yapamamaktan muzdaripse - daha basit, türlenmemiş çözümü seçin. İkisi de varsa - bir danışman bulun (sadece şaka ;-)

Pekala, bu kime sorduğunuza bağlı ... Birçoğu, bu modüller arasındaki mesajlaşmadan kodlamayı çıkarmak için çeşitli "iş mantığı" parçalarını birbirine bağlayan bir "Ara Yazılım" parçası olduğunu söyleyebilir. Sanırım bu yeterince genel bir tanım, ama eminim oraya Wikipedia aracılığıyla zaten ulaşmışsınızdır.

Dünyayı kurtaran harika ESB'ye sahip olanlar, onu en yaygın olarak sunulduğu şekliyle, her şeyi yapmak için bir merkez olarak görüyorlar. Çoğu ESB uygulaması, iş yazılımında gördüğümüz tüm tekrarlayan görevleri kapsamak için çaba gösterir. Bu, çoğu ESB'nin veri aktarımı, güvenlik, günlüğe kaydetme, protokol çevirisi, olay sistemleri, web hizmetleri aracılığıyla api'ye maruz kalma vb. İle ilgilendiği anlamına gelir.

Sanırım bu olabildiğince açık ... Umarım yardımcı olur.

Sunumuma bir göz atın " Seçim için Şımarık - Doğru ESB nasıl seçilir .

Bir ESB, Entegrasyon Paketi veya sadece bir Entegrasyon Çerçevesinin (Apache Camel gibi) ne zaman kullanılacağını açıklarım. Ayrıca açık kaynak ve tescilli ESB'ler arasındaki farkları da tartışıyorum.

Wikipedia'dan edinebileceğiniz standart tanımın ötesinde . Bunu, bir grup eski sistemi birden çok platform ve teknolojiye bağlamak için harika bir araç olarak görüyorum. Ayrıca, dağıtılmış iş akışları ve durum yönetimi sistemleri (genel muhasebe gibi) oluşturmak için iyi bir araçtır.

Bununla birlikte, bakımı ve genişletmesi oldukça pahalı, karmaşık ve elverişsizdir, bu da onu, uygulamalarınızı ölçeklendirmek için genel amaçlı bir araç olarak zayıf bir teknoloji seçimi yapar.