Neden bir kütüphane yerine hizmetleri (REST / SOAP) kullanmalı?

Diyelim ki uygulamalarınızı hizmetlere bölmek. SOA yaklaşımını benimsemek için iyi bir neden var mı, sadece ihtiyaç duyan uygulamalar tarafından yüklenebilecek bir kütüphane API'si oluşturmak için.

Aradaki fark, ikisi arasında ince olabilir. Örneğin, .NET dünyasında, son kullanıcıya monolitik gibi hissedecek ve aynı makinede çalışacak, ancak içeride WCF servislerine ayrılacak bir uygulamanız olabilir. Ayrıca kütüphanelerin güçlü bir şekilde birbirine bağlı olmadığı (eklentiler / eklentiler) ve sadece birbirleriyle konuşurken bir protokolü takip eden mimarilere sahip olabilirsiniz.

Bu aracı durumlar hakkında konuşmaktan kaçınırsak ve yalnızca birbiriyle bağlantılı bir API kütüphanesi ile ayrı bir REST servisi ile ilgilenirsek, aşağıdaki noktaları göz önünde bulundurmak isteyebilirsiniz:

1. Aynı makinede bir kütüphane API'si çağrılıyor. Hizmetler herhangi bir yerde barındırılabilir ve her yerden çağrılabilir. Uygulamayı performans / ölçeklenebilirlik / güvenlik nedenleriyle birden fazla makinede barındırıyorsanız, hizmetleri kullanmanız gerekebilir.

2. Bu durum, birkaç makineye dağıtılmış bir uygulama tarafından tek bir servisi kullanmaya benzer. Örneğin, bazı finansal hesaplamalar yapan bir banka için bir başvuru yapıyorsanız, bunun bir yolu tüm büyük uygulamayı her masaüstüne dağıtmak ve her seferinde her müşteriye büyük boyutlu güncellemeler yapmak zorunda kalmaktır; Başka bir yaklaşım, hesaplama bölümünü sunucularda barındırmak ve masaüstlerine yalnızca bir UI ve bu sunuculara yapılan çağrıları içeren hafif bir uygulamayı dağıtmak olacaktır.

3. Bir REST servisi barındırıyorsanız, herkes kullanabilir: bir Mac kullanıcısı, Linux kullanan bir kişi vb. Visual Studio ile bir C # kütüphanesi oluşturduysanız ve bir DLL olarak dağıtırsanız, kullanıcıları (müşterileri unutun) unutmayın. ?) kim Windows'a sahip değil.

Servislerin diğer bir avantajı, servisi güncellediğinizde, servisin derhal tüm tüketicilere dağıtılmasıdır. Dolayısıyla, bir hatayı veya performans sorununu düzelttiyseniz, güncellenen hizmet yayınlanır yayınlanmaz, herkesin görmezden gelmeyi seçebileceği bir güncelleme dağıtmak zorunda kalmadan herkes yararlanır.

Kütüphane Avantajları:

• Görüşme başına daha düşük ek ücret (yalnızca atlama veya hatta bırakılmış ) = performansı artırabilir
• İşe yarayabilecek en basit şey
• Merkezi hizmetin aşağı inmesi ve tüm tüketicileri etkilemesi riski yoktur

Hizmet Avantajları:

• Herkes derhal ve şeffaf olarak yükseltme yapar (sürümlü API teklif edilmedikçe)
• Tüketiciler kodu çözemezler
• Servis donanımını ayrı ayrı ölçeklendirebilir
• Teknoloji agnostik. Ortak bir kütüphane ile tüketiciler uyumlu bir teknolojiden faydalanmalıdır.
• Daha güvenli. Kullanıcı arayüzü, doğrudan DB'ye erişmek yerine, bir güvenlik duvarının arkasındaki servisi arayabilir.

SOA yaklaşımı, çeşitli hizmetlerin ayrı ayrı barındırılmasını ve korunmasını sağlar. Koda ek olarak, belirli bir hizmetin dağıtılması birçok özel yapılandırma gerektirebilir (şifreler, portlar, sertifikalar, vb.). Bir REST servisini kullanmak, açıkça belgelenebilen ve kolayca anlaşılabilen sınırlı bir karmaşıklığa sahiptir. Ayrıca daha güvenlidir, çünkü istemcilere DB'lere veya diğer kaynaklara erişim izni vermeniz gerekmez.

Bir SOA hizmetinde bir değişiklik olursa, SOA hizmetinin yeniden geliştirilmesi, yeniden test edilmesi ve yeniden konuşlandırılması gerekir. Bu hizmeti kullanan tüm uygulamalar bunu yapmaya devam edebilir. Bir DLL dosyasındaki bir kitaplıkta değişiklik yapılması, o kütüphanenin tüm tüketicilerinin bu DLL'e başvurmak için yeniden geliştirilmesi gerektiği, hepsinin tekrar test edilmesi ve hepsinin yeniden dağıtılması gerektiği anlamına gelecektir. Bunun doğru şekilde gerçekleşmemesi tehlikesi de vardır ve farklı uygulamalar DLL'in farklı sürümlerine sahip olacaktır. Bazen bu bir problem olmayabilir - belki de her sistemin konuşlandırma sırasında mevcut olan kütüphanenin sürümüne sahip olmalıdır (kayıt sisteminizi yararlı yeni özelliklere sahip olacak şekilde güncellemiş olabilirsiniz - gerçektenonunla her sistemi güncellemeniz gerekiyor mu?) bu durumda bir kütüphane iyi. Ancak vergi oranını hesaplamak için bir hizmetiniz olduğunu ve vergi yasalarının değiştiğini varsayalım. Bu değişikliği dahil etmek için her sistemi güncellemek zorunda değilsiniz, tek bir yerde yapmak daha iyi olacaktır. Bu durumda bir servis daha iyi bir seçenektir.

Birkaç iyi cevap var ama verilen cevaplara daha fazla şey eklemek istiyorum:

API kütüphanesi yöntemi, olabildiğince az ek yükü olan şeylerle etkileşimde bulunmak istediğinizde çok kullanışlıdır. Sonuç, API ile onu kullanan uygulamalar arasında daha yüksek bir eşleşme olmasıdır. Bazen, bu uygulama için uygundur ve hatta gereklidir, ancak çok dağınık bir sisteminiz varsa veya birlikte çalışabilirliğin çok büyük bir sorun olduğunu düşünüyorsanız, soyutlamanın bir adımına kadar çıkmanız ve başka iletişim yolları kullanmanız gerekebilir. Özellikle, dağıtılmış bir sisteme sahip olmak istiyorsanız, SOAP, SOA'daki bir sonraki adımdır, ancak birbirlerinin prosedürlerini bilmek zorunda olduklarından üniteler arasındaki bağımlılıktan hala mahrum kalacaksınız. REST, bir makinenin diğer hizmetlerdeki içerik hakkında birleştirilmiş bir şekilde bir şeyler öğrenmesini sağlayarak yeni bir düzeye çıkarır.

Sizin durumunuzda, başvurunuz dağıtılmamışsa, başvurunuzu SOA'ya dönüştürmek için herhangi bir sebep görmüyorum.