SOA hizmet kompozisyonu aslında pratikte çalışıyor mu?

Ana SOA hizmet tasarımı ilkelerinden biri Hizmet Oluşturulabilirlik ilkesidir ( https://en.wikipedia.org/wiki/Service_composability_principle ).

Buradaki fikir, mevcut hizmetleri yapı taşı olarak kullanarak yeni hizmetler oluşturarak, hızlı bir şekilde yeni hizmetler geliştirebilir. Yeni yöntemler uygularken nesnelerin varolan yöntemlerini nasıl çağırdığınıza benzer şekilde. SOA'nın üretkenlik artışının çoğunun geleceği yer burasıdır.

Birisi bunu pratikte gerçekten yapıyor mu? Bunu yazılı metinde sürekli tekrarladım, ama gerçek dünya uygulamalarını kendim yaşamaya çalışmadım. Metnin çoğu aynı zamanda işlemlerin ele alınışından bahsetmemektedir , bu da bana, kompozit hizmetler gerçekleştirmenin önündeki en büyük engel gibi görünmektedir.

Öncelikle, önemsiz olmayan hizmetleri oluşturmadan önce işlemlerle ilgili sorunu çözmeniz gerekir. Elbette, örnekte "findCurrentTime ()" ve "writeLogMessage ()" hizmetleri varsa, işlemler hakkında endişelenmek kolaydır, ancak "depositMoney ()" ve "withdrawMoney ()" gibi gerçek dünya örneklerine sahipken bu kolay değildir.

İki seçeneği biliyorum:

1. WS-Atomic Transaction vb. İle gerçek işlemleri gerçekleştirin
2. A'ya yapılan çağrıyı "cancelA ()" ile telafi eden veya B çağrısı başarısız olursa buna benzer bir telafi tabanlı çözüm uygulayın

Bunların her ikisi de benim için çok sorunlu / yakın değil:

• WS-Atomik İşlem
  • bir sürü karmaşıklık, bulduğum çoğu tavsiye sadece "kıçından acı, yapma" uyarısında bulundu
  • destek sınırlıdır, örneğin açık kaynaklı ESB'ler alırsanız, ServiceMix, Mule veya WSO2 ana alternatifleri desteklemez
• tazminatlar
  • tazminatlarla başa çıkmak benim için çok karmaşık görünüyor. Hizmet A başarılı olursa ve hizmet B'den asla yanıt alamazsak ve başarısız veya başarılı olup olmadığını bilmiyorsak ne yapacağız? Bu tür bir mantığı manuel olarak kullanmak (birleştirme hizmetlerinin uygulayıcısı olarak) bileklerimi kesmemi istiyor - bu, bazı araçların benim için yapması gereken bir iş!
  • Ayrıca önemsiz olmayan hizmetlerde tazminat yöntemlerine nasıl sahip olabileceğinizi de görmüyorum. Diyelim ki A hizmetiniz "depositMoney ()" dır ve bu başarılı olur, başka bir işlem hızla parayı başka bir yere aktarır ve sonra "compensateDepositMoney ()" alırız, şimdi ne yapacağız? Büyük bir solucan kutusu gibi görünüyor.

Bana göre, hizmet kompozisyonu öyle temel bir SOA ilkesi gibi görünüyor ki, hizmetleri (uygun bir şekilde) oluşturamazsanız gerçekten SOA'nın avantajlarından yararlanamazsınız . Gerçek nedir? SOA kullanıcılarının% 90'ı gerçek hizmet bileşimi olmadan "şifreli SOA" kullanıyor mu? Ya da çoğu kullanıcı aslında hizmet kompozisyonunu kullanıyor ve bunun zorluğunu abartıyorum?

Kısa cevap Evet!

Bunun birkaç büyük finans kuruluşunda yapıldığını gördüm ve iyi çalıştı.

İşlem sorunları karmaşık olmakla birlikte genellikle Oracles WebLogic EAI veya IBM Websphere ESB gibi (pahalı) ara yazılım tarafından ele alınır.

Evet, pratikte çalışmak için yapılabilir. Bununla birlikte, en iyi yaklaşım olmayabilir ve belki de olması gerekenden daha fazla varsayılan seçenek olarak kullanılır. Kanımca, kuruluşlar daha büyük görevleri otomatikleştirmek için BT'lerini geliştirdikçe SOA, eski sistemleri entegre etmenin bir yolu olarak popüler oldu. Çok dağınık olabilir, ancak eski sistemler tekrar kullanılabilirse buna değebilir. Bir yeşil alan projesine başlayacak kadar şanslıysanız, gidilecek en iyi yol olduğunu varsaymadan önce diğer yaklaşımlar dikkate alınmalıdır.

Daha spesifik endişelerinizden bazılarını yanıtlamak için ...

İşlemleri kullanabilirsiniz:

1. WS-TX bir PITA ve bundan kaçınırdım.
2. Tüm hizmetleriniz tek bir uygulama sunucusunda çalışıyor olabilir, bu durumda hepsini bir XA işlemiyle dağıtabilirsiniz. Bu yüzden uygulama sunucuları gibi şeyler icat edildi.

Tazminat temelli yaklaşım dikkate alındığında:

Telafi edici eylemlerin yalnızca bir arıza olduğunda dikkate alınması gerekir. Hizmet kompozisyonu aracında, bir iş akışı adımını ilk kez çalıştırırken temizlenecek ancak sonraki çağrılarda ayarlanan, denetleyebileceği bir bayrak var mı? JMS'deki olası yeniden gönderme bayrağı gibi. Daha sonra 1,5 fazlı kesinleştirme olarak adlandırılan şeyi kullanabilirsiniz, bu da bayrak açıksa devam et anlamına gelir, ancak bayrak ayarlanırsa, önce durumun zaten güncellenip güncellenmediğini ve ikinci kez yapılması gerekip gerekmediğini kontrol etmek için bir arama yapın. . Bu yine de manuel hata işleme gerektirir ve işaret ettiğiniz gibi karmaşık hatta imkansız olabilir.

Bazı durumlarda önemli değil:

Sonunda tutarlı yaklaşım budur. Bir hizmetin bir e-posta gönderdiğini varsayalım. Hizmet kompozisyonu başarısız olursa ve yeniden başlatılırsa, e-posta tekrar gönderilir. Bu, alıcı için biraz sinir bozucu, ancak muhtemelen bunun bir kopyası olduğunu fark ediyorlar ve her şey çok fazla sorun olmadan devam edebilir.

Ayrıca, gönderilen e-postaların bir günlüğünü tutabilir ve bayrak ayarlandığında bunu kaldırmak için bunu kullanabilir ve bu şekilde e-postayı yalnızca bir kez gönderebilirsiniz.

İşlemleri daha küçük parçalara bölmek için eşzamansız mesajları kullanabilirsiniz:

İşlemsel olan bir JMS kuyruğunu düşünün. Servis koordinatörünüz durumunu güncelleyebilir ve sıraya tek bir Tx'de mesaj gönderebilir. Alt servisler mesajları çıkarabilir ve durumlarını tek bir Tx'de güncelleyebilir. Şimdi hizmetleri birden çok iş biriminde koordine ediyorsunuz, ancak her biri atomik. Bir şey başarısız olursa ve yeniden başlatılması gerekiyorsa sorun yok.

Bu, veritabanı ve bir JMS kuyruğu üzerinde XA işlemleri yaptığınız anlamına gelir, ancak bu, XA'nın tam olarak aşılmasını önlemek için son kaynak gambiti kullanılarak yine de verimli olabilir.

Alternatif olarak, bu kalıbı kullanabilirsiniz, ancak veritabanına ve JMS'ye 1,5 aşamalı bir taahhütte bulunabilirsiniz. VEYA JMS'yi işlem yapmadan çalıştırabilir, ancak kümeleme yoluyla daha güvenilir hale getirebilirsiniz.

Async mesajlaşma, üreticilerin ve tüketicilerin birbirinden daha bağımsız hale gelebilmesi, genel sistemdeki bağlantı miktarını azaltabilmesi ve daha esnek hale getirebilmesi için sistemleri ayırmaya da yardımcı olabilir. Bu tür ayırma, çok çeşitli hizmetlere sahip büyük kuruluşlar söz konusu olduğunda oldukça önemlidir.

Hayır, bu bir efsane. Hizmet mimarisi tasarlanırken bu yanlış bir niyettir. Bir sürü sorun var:

1. Çok sıkı bağlantı. Bir hizmet değiştirildiyse, tüm sistemi test etmeniz gerekir.
2. Bu tür hizmetler çok hassastır, bu nedenle çok fazla iç iletişim vardır.
3. İnce taneli olmanın bir sonucu olarak birçok hizmet vardır. Sistemin anlaşılması zorlaşıyor, sorguların izlenmesi zorlaşıyor.
4. Varlık hizmetleri zayıf bir şekilde kapsüllenmiş durumda: orada iş kurallarının hiçbiri denetlenmiyor, bu mantık işlem hizmetlerinde. Böylece herhangi bir hizmet, herhangi bir varlık hizmetini çağırabilir ve verilerini arabiriminde bulunan ortak güncelleme sorgusuyla güncelleyebilir. Bu tür varlık hizmetleri, süreç merkezli, davranış merkezli hizmetlerin aksine, veri merkezli olarak adlandırılır.
5. Bu hizmetler arasındaki iletişimin doğası gereği eşzamanlıdır. Dolayısıyla, seçilen ulaşımın http olması ihtimali vardır. Bu yüzden biraz sonra konuşacağım tüm dezavantajları.

Hizmet mimarisine yaklaşmanın daha da yanlış yolları var . Bu yüzden dikkatli olun.