İşlemleri kullanamıyorsanız web hizmetlerini kurumsal ortamda nasıl etkili bir şekilde kullanabilirsiniz?


14

Çalıştığım yer bazı temel kurallar oluşturmaya çalışıyor ve şu anda yaptığımız tartışma, kodların yeniden kullanımı için yerel kütüphaneler vs web hizmetleri. Web hizmetleri çoğu şirkette popüler bir seçim gibi görünüyor ve buradaki geliştiricilerin çoğu buna yöneliyor.

Herhangi bir ciddi iş için web hizmetlerini nasıl etkili bir şekilde kullanabileceğinizi göremiyorum. Bir işlemi kullanamıyorsam nasıl birden fazla servis çağrısı yapabilirim?

Diyelim ki, bilgilendirilmeleri gereken belirli bir koşula uyan müşterileri veritabanımızdan alan bir cron işim var. Bir faks, e-posta gönderilir ve sorunu dahili olarak izlemek için bir bilet oluşturulur. Bu, bir for döngüsündeki her müşteri için gerçekleşecek 3 farklı servis çağrısıdır.

Orada herhangi bir yerde bir hata oluşursa, örneğin müşteriye bir faks ve e-posta gönderilebilir, ancak bir bilet oluşturulmaz. Daha da kötüsü, bu cron işi her seferinde aynı noktada başarısız olmasına neden olan bir hatayı içerebilir ve aynı müşteriye tekrar tekrar e-posta gönderir. Kitaplıkların hepsi yerel olsaydı, her şey bir işleme sarılabilirdi ve bunların hiçbiri olmazdı. Ancak bu örnekte web hizmetlerini kullanıyoruz.

E-posta ve faks yöntemlerinin gerçekte verileri veritabanı destekli kuyruk tablolarına eklediğini ve bunun da ayrı bir cron iş süreci tarafından işlendiğini unutmayın. Dolayısıyla, "e-posta gönder" ve "faks gönder" hizmet yöntemlerine yapılan çağrılar, gerektiğinde yan etkisiz olarak iptal edilebilir.

Bir seçenek, bu kodun tamamını web hizmetinin kendisine koymaktır, böylece web hizmetinin kendisi bir işlemde e-posta, faks ve bilet oluşturma yöntemlerini çağırır. Ancak, yalnızca bir işlemin kullanımı için bir web hizmeti yöntemi oluşturuyoruz; bu yöntemi bu cron betiği dışında herhangi bir yerden çağırmamızın geçerli bir nedeni yoktur.

Bu yöntemi genel olarak nasıl ele alırsınız?


Tam bir cevap vermek için daha fazla bilgiye ihtiyacım var. Hizmet tabanlı bir mimariye geçerken göz önünde bulundurulması gereken çok şey vardır. Örneğin, heterojen (farklı diller ve platformlar) veya homojen (tek dil ve platform) ortamınız var mı? Servis otobüsü sisteminiz var mı? Değilse bir tane uygulamayı planlıyor musunuz? Hizmetlerinize nasıl erişmeyi planlıyorsunuz (tek konumlu İntranet, çok konumlu wan, kamu hizmeti API'sına isabet eden dağıtılmış istemci). "En uygun" çözümü etkileyen bir dizi değişken vardır.
Michael Brown

@MikeBrown: Hizmetlerin tümü tek bir dilde yazılır, ancak birden çok platform tarafından kullanılır. Bir EBS'nin uygulanması hakkında hiçbir fikrim yok, herhangi bir hizmet çalışmasına bile başlamadık, bu yüzden her şey mümkün. Hizmetler çoğunlukla yerel ağımız üzerinden dahili olarak tüketilecek, ancak mobil uygulamalar için halka açık olması gereken bazı şeyler olacaktır.
ryeguy

"Eğer kütüphanelerin hepsi yerel olsaydı, her şey bir işleme sarılabilirdi ve hiçbiri olmazdı". Yanlış. Hata , e-posta gönderildikten sonra ancak son veritabanı güncellemesinden önce ortaya çıkabilir . Bir işlem, e-postayı veya faksı geriye dönük olarak engellemez.
S.Lott

@ S.Lott: E-posta ve faks hizmeti çağrıları aslında onları sadece farklı bir işlemle teslim edilen bir sıraya ekliyor. Yukarıda tarif ettiğim işlem gerçekleşirse, kuyruk ekleme işlemi iptal edilir.
ryeguy

1
@ryeguy: Lütfen soruyu güncelleyin . Lütfen soruya yorum eklemeyin. Bu, mimarinizin önemli bir parçasıdır. Lütfen soruda açıklayınız.
S.Lott

Yanıtlar:


5

Açıkladığınız şey aslında iki aşamalı kesinleştirme uygulayan dağıtılmış bir işlemdir . Bazı kurumsal mesajlaşma platformları, bu tür şeyleri desteklemek için işlem yöneticileri içerir, ancak beton ürünler platforma / dile bağlıdır. Bu tür araçlarla somut bir deneyimim yok, ancak bu işaretçilerin yardımcı olacağını umuyorum.


3

Bu özel Soru-Cevap bölümüne katıldığım için, katıldığım DDD / CQRS posta listesinde birden çok platformu destekleyen hizmetler hakkında benzer bir konu var. Burada bazı tavsiyelerimi tekrarlayabilirim.

İşlemleri heterojen bir ortamda desteklemek için bir seçenek, işlemleri destekleyen ve kullanılacağı tüm platformlarda desteklenen bir aktarım mekanizması kullanmaktır. Gelişmiş Mesaj Kuyruk Protokolü (AMQP) desteği işlemlerini yapar ve bugün yaygın kullanılan hemen hemen her dil için bir yerli API yoktur. RabbitMQ , AMQP'yi uygulayan ve güçlü bir çözüm olarak sektörde denetlenen bir sunucudur.

RabbitMQ tabanlı bir sistemden faydalanmak, içinde büyümeniz gerektiğinde tam bir ESB'ye sahip olmanın yolunu açar. Bir kanala mesaj yayınlar ve bir kuyruğa abone olursunuz. Bunun gerçekten güçlendiği yerde, kanal ve kuyruk arasında çok ilginç şeyler yapabilirsiniz. Bir kanal birden fazla kuyruğu (pub / sub) besleyebilir, bir kuyruk birden fazla kanal tarafından beslenebilir, mesajları içeriğe dayalı olarak vb. Farklı kuyruklara yönlendirebilirsiniz.

Sadece işlemlere alternatifler okuyordum. RabbitMQ, yayıncı onayı olarak adlandırılanları destekler . Temel olarak, başarısız bir işlemi işlemek için yayınlanmış bir yöntem için geri arama kaydetmenizi sağlar. Sizin durumunuzda, e-posta / faks isteklerini geri alabilir ve bileti silebilir.

Tabii ki tavşan deliği (pardon pun) oradan daha da derine iner. Tavşan'ı hem dahili hem de harici web hizmetleriyle karmaşık düzenlemeler yapmak için kullanabilirsiniz.

Halka açık web servisleriniz için bu artık çok basit. Hizmetiniz (ister SOAP, REST veya JSON olsun), sadece uygun hizmet kuyruğuna bir mesaj yayınlar ve dahili sisteminizin oradan yönetmesine izin verir.

Ayrıca, bilgileri hızlı bir şekilde geri beklediğiniz senaryolar için bir istek / yanıt iletisi oluşturma işlevi de vardır.



1

Yazdığım bir hizmet uygulamasında bunu ele alma şeklim, gerekli işlemleri yapmak için bir sarıcı oluşturmaktı. Benim durumumda, web sitesi, masaüstü uygulaması veya Windows hizmeti tarafından yapılan kullanıcı isteği, bir web hizmetini sorgulamak zorunda kaldı ve sonuca ve kullanıcının seçeneklerine bağlı olarak, yerel bir DB'yi ve isteğe bağlı olarak uzak bir servisi güncellemek zorunda kaldı. bir web servisi aracılığıyla. Daha sonra derhal iade edilmesi, e-postayla gönderilmesi ve / veya fakslanması için bir rapor oluşturması gerekiyordu. Yerel DB, e-posta ve rapor oluşturma üzerinde kontrol vardı ama hiçbiri web hizmetleri veya faks sunucusu üzerinde.

Bir sarıcı oluşturmak daha iyi işlem kontrolü ve hata işleme olanağı sağladı. Ayrıca, dış kaynaklardan dahili ağ hizmetlerine erişimi kontrol ederek daha iyi güvenlik sağladı. Genel olarak, kod düzgün bir şekilde yeniden kullanıldığı sürece (cut-n-paste kodlaması yok), tek bir çözüm için uygun bir sarmalayıcı oluşturmak için hizmetin işlemlerine ve yönetimine duyulan gereksinimi geçerli bir neden olarak görüyorum.


1

Herhangi bir ciddi iş için web hizmetlerini nasıl etkili bir şekilde kullanabileceğinizi göremiyorum. Bir işlemi kullanamıyorsam nasıl birden fazla servis çağrısı yapabilirim?

Yapamazsın.

Sormanız gereken soru şudur: Web hizmeti çerçevesi X ile işlemleri nasıl uygularım? Şu anda, bunun imkansız olduğunu varsayıyorsunuz.

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.