Servis Odaklı Mimari - Service-oriented architecture

Gelen yazılım mühendisliği , hizmet odaklı mimari ( SOA ) bir mimari tarzı bu destekleri hizmet yönelim olduğunu. Sonuç olarak, hizmetlerin bir ağ üzerinden bir iletişim protokolü aracılığıyla uygulama bileşenleri tarafından diğer bileşenlere sağlandığı yazılım tasarımı alanında da uygulanmaktadır . Hizmet, çevrimiçi olarak kredi kartı ekstresi almak gibi, uzaktan erişilebilen ve buna göre hareket edilip bağımsız olarak güncellenebilen ayrı bir işlevsellik birimidir. SOA'nın ayrıca satıcılardan, ürünlerden ve teknolojilerden bağımsız olması amaçlanmıştır.

Hizmet odaklılık, hizmetler ve hizmete dayalı geliştirme ve hizmetlerin sonuçları açısından bir düşünme biçimidir.

Bir hizmetin birçok SOA tanımından birine göre dört özelliği vardır:

  1. Mantıksal olarak, belirli bir sonucu olan tekrarlanabilir bir ticari faaliyeti temsil eder.
  2. Kendi kendine yeten.
  3. Tüketicileri için bir kara kutudur , yani tüketicinin hizmetin iç işleyişinin farkında olması gerekmez.
  4. Diğer hizmetlerden oluşabilir.

SOA'nın modüler programlama ile paylaştığı bir ilke olan, büyük bir yazılım uygulamasının işlevselliğini sağlamak için bir hizmet ağı olarak farklı hizmetler birlikte kullanılabilir . Hizmet odaklı mimari, dağıtılmış, ayrı olarak muhafaza edilen ve dağıtılan yazılım bileşenlerini bütünleştirir. Bileşenlerin bir ağ üzerinden, özellikle bir IP ağı üzerinden iletişimini ve işbirliğini kolaylaştıran teknolojiler ve standartlar tarafından sağlanır.

SOA, yazılımın uygulanmasını ve bakımını basitleştirmeyi amaçlayan bir bilgisayar programının farklı bölümleri arasındaki bir arabirim veya iletişim protokolü olan uygulama programlama arabirimi (API) fikriyle ilgilidir . Bir API, hizmet ve SOA, hizmetin çalışmasına izin veren mimari olarak düşünülebilir.

genel bakış

SOA'da hizmetler, açıklama meta verilerini kullanarak mesajları nasıl ilettiklerini ve ayrıştırdıklarını açıklayan protokoller kullanır . Bu meta veriler, hem hizmetin işlevsel özelliklerini hem de hizmet kalitesi özelliklerini tanımlar. Hizmet odaklı mimari, kullanıcıların yalnızca mevcut hizmetlerden oluşturulan ve bunları geçici bir şekilde birleştiren uygulamalar oluşturmak için büyük işlevsellik parçalarını birleştirmesine izin vermeyi amaçlar. Bir hizmet, istekte bulunana, bir kara kutu gibi davranan temel karmaşıklığı soyutlayan basit bir arabirim sunar. Diğer kullanıcılar, dahili uygulamaları hakkında herhangi bir bilgi sahibi olmadan bu bağımsız hizmetlere de erişebilir.

kavramları tanımlama

Hizmet odaklılığın teşvik ettiği ilgili terim , hizmetler arasında gevşek bağlantıdır . SOA, kullanıcıların bunları uygulama üretiminde birleştirmelerine ve yeniden kullanmalarına izin vermek için geliştiricilerin bir ağ üzerinden erişilebilir kıldığı işlevleri farklı birimlere veya hizmetlere ayırır. Bu hizmetler ve bunlara karşılık gelen tüketiciler, verileri iyi tanımlanmış, paylaşılan bir biçimde ileterek veya iki veya daha fazla hizmet arasındaki bir etkinliği koordine ederek birbirleriyle iletişim kurar.

Ekim 2009'da hizmet odaklı mimari için bir manifesto yayınlandı. Bu, aşağıdaki gibi sıralanan altı temel değerle geldi:

  1. İş değerine teknik stratejiden daha fazla önem verilir.
  2. Stratejik hedeflere projeye özel faydalardan daha fazla önem verilir.
  3. Dahili birlikte çalışabilirliğe özel entegrasyondan daha fazla önem verilir.
  4. Paylaşılan hizmetlere özel amaçlı uygulamalardan daha fazla önem verilmektedir.
  5. Esnekliğe optimizasyondan daha fazla önem verilir.
  6. Evrimsel arıtmaya , ilk mükemmelliğin peşinde koşmaktan daha fazla önem verilir.

SOA eski kavramından aralıkları bütünün parçası olarak görülebilir dağıtılan bilgisayar ve modüler programlama uygulamaları ile, SOA kanalıyla ve üzerinde mashup , SaaS ve bulut bilgi işlem (ki SOA yavru gibi bazı bkz).

Prensipler

Pek çok endüstri kaynağı kendi ilkelerini yayınlamış olsa da, hizmet odaklı bir mimarinin tam bileşimi ile ilgili endüstri standardı yoktur. Bunlardan bazıları aşağıdakileri içerir:

Standartlaştırılmış hizmet sözleşmesi
Hizmetler, belirli bir hizmet kümesi içinde bir veya daha fazla hizmet açıklaması belgesiyle toplu olarak tanımlandığı gibi standart bir iletişim sözleşmesine bağlıdır.
Hizmet referans özerkliği (gevşek bağlantının bir yönü)
Hizmetler arasındaki ilişki, yalnızca varlığından haberdar oldukları düzeye indirgenir.
Servis konumu şeffaflığı (gevşek bağlantının bir yönü)
Servisler, nerede bulunursa bulunsun, bulunduğu ağ içinde herhangi bir yerden çağrılabilir.
Hizmet ömrü
Hizmetler uzun ömürlü olacak şekilde tasarlanmalıdır. Mümkünse servisler, yeni özelliklere ihtiyaç duymazlarsa tüketicileri değiştirmeye zorlamaktan kaçınmalı, bugün bir servisi aradığınızda yarın aynı servisi arayabilmeniz gerekir.
Hizmet soyutlaması
Hizmetler kara kutu görevi görür, yani iç mantığı tüketicilerden gizlenir.
Hizmet özerkliği
Hizmetler bağımsızdır ve kapsadıkları işlevselliği Tasarım zamanı ve çalışma zamanı perspektifinden kontrol eder.
Hizmet vatansızlığı
Hizmetler durumsuzdur, yani istenen değeri döndürür veya bir istisna verir, bu nedenle kaynak kullanımını en aza indirir.
Hizmet ayrıntı düzeyi
Hizmetlerin yeterli boyut ve kapsamda olmasını sağlama ilkesi. Hizmet tarafından kullanıcıya sağlanan işlevsellik ilgili olmalıdır.
Hizmet normalleştirme
Fazlalığı en aza indirmek için hizmetler ayrıştırılır veya birleştirilir (normalleştirilir). Bazılarında bu yapılmayabilir. Bunlar, performans optimizasyonu, erişim ve toplamanın gerekli olduğu durumlardır.
Hizmet şekillendirilebilirliği
Hizmetler, diğer hizmetleri oluşturmak için kullanılabilir.
Hizmet keşfi
Hizmetler, etkili bir şekilde keşfedilip yorumlanabilecekleri iletişimsel meta verilerle desteklenir.
Hizmet yeniden kullanılabilirliği
Mantık, kodun yeniden kullanımını teşvik etmek için çeşitli hizmetlere ayrılmıştır.
Hizmet kapsülleme
Başlangıçta SOA kapsamında planlanmayan birçok hizmet kapsüllenebilir veya SOA'nın bir parçası olabilir.

desenler

Her SOA yapı taşı, üç rolden herhangi birini oynayabilir:

Servis sağlayıcı
Bir web hizmeti oluşturur ve bilgilerini hizmet kayıt defterine sağlar. Her sağlayıcı, hangi hizmetin ortaya çıkarılacağı, hangisinin daha fazla önem verileceği gibi birçok neden ve neden üzerinde tartışır: güvenlik veya kolay kullanılabilirlik, hizmeti hangi fiyata sunacağı ve daha fazlası . Sağlayıcı ayrıca, belirli bir komisyoncu hizmeti için hizmetin hangi kategoride listelenmesi gerektiğine ve hizmeti kullanmak için ne tür ticaret ortağı anlaşmalarının gerekli olduğuna karar vermelidir.
Hizmet komisyoncusu, hizmet kaydı veya hizmet deposu
Ana işlevi, web hizmetiyle ilgili bilgileri herhangi bir potansiyel istek sahibine sunmaktır. Aracıyı uygulayan kişi, aracının kapsamına karar verir. Kamu komisyoncuları her yerde ve her yerde mevcuttur, ancak özel komisyoncular yalnızca sınırlı miktarda halka açıktır. UDDI , Web hizmetleri keşfi sağlamak için artık aktif olarak desteklenmeyen erken bir girişimdi .
Hizmet talep eden/tüketici
Çeşitli bulma işlemlerini kullanarak aracı kayıt defterindeki girdileri bulur ve ardından web hizmetlerinden birini çağırmak için hizmet sağlayıcıya bağlanır. Hizmet-tüketiciler hangi hizmete ihtiyaç duyarlarsa onu aracılara almak, ilgili hizmete bağlamak ve sonra kullanmak zorundadırlar. Hizmet birden fazla hizmet sağlıyorsa, birden çok hizmete erişebilirler.

Hizmet tüketicisi-sağlayıcı ilişkisi, bir ticari bölüm, bir işlevsel bölüm ve bir teknik bölümden oluşan standart bir hizmet sözleşmesi tarafından yönetilir .

Hizmet kompozisyon modellerinin iki geniş, üst düzey mimari stili vardır: koreografi ve orkestrasyon . Belirli bir mimari stile bağlı olmayan alt düzey kurumsal entegrasyon modelleri, SOA tasarımında ilgili ve uygun olmaya devam ediyor.

Uygulama yaklaşımları

Servis odaklı mimari, web servisleri veya Mikroservisler ile uygulanabilir . Bu, işlevsel yapı taşlarını platformlardan ve programlama dillerinden bağımsız standart İnternet protokolleri üzerinden erişilebilir kılmak için yapılır. Bu hizmetler, ya yeni uygulamaları temsil edebilir ya da sadece mevcut eski sistemlerin ağ üzerinden etkinleştirilmesini sağlamak için bunların etrafını sarabilir.

Uygulayıcılar genellikle web hizmetleri standartlarını kullanarak SOA'lar oluşturur. Bir örnek SABUN (aynı zamanda olarak anılacaktır 2003 Bu standartlarda W3C (World Wide Web Consortium) den Version 1.2 önerisi sonrasında geniş sanayi kabul görmüştür, web hizmeti özelliklerine de büyük çalışabilirliği ve bazı koruma kilidi-in sağlamak) tescilli satıcı yazılımına. Bununla birlikte, Jini , CORBA , Internet Communications Engine , REST veya gRPC gibi diğer hizmet tabanlı teknolojileri kullanarak da SOA uygulayabilirsiniz .

Mimariler belirli teknolojilerden bağımsız olarak çalışabilir ve bu nedenle aşağıdakiler de dahil olmak üzere çok çeşitli teknolojiler kullanılarak uygulanabilir:

Uygulamalar, bu protokollerden birini veya daha fazlasını kullanabilir ve örneğin, SOA konseptine uyan süreçler arasında tanımlanmış bir arayüz spesifikasyonunu izleyerek verileri iletmek için bir dosya sistemi mekanizması kullanabilir. Anahtar, çağıran uygulama hakkında önceden bilgi sahibi bir hizmet olmaksızın ve hizmetin görevlerini fiilen nasıl gerçekleştirdiğine dair bilgiye sahip olmayan veya bu bilgiye ihtiyaç duyan bir hizmet olmaksızın standart bir şekilde görevlerini gerçekleştirmek için çağrılabilen tanımlanmış arayüzlere sahip bağımsız hizmetlerdir. SOA, gevşek bağlı ve birlikte çalışabilir hizmetleri birleştirerek oluşturulan uygulamaların geliştirilmesine olanak tanır .

Bu hizmetler, temeldeki platform ve programlama dilinden bağımsız olan resmi bir tanıma (veya sözleşme, örneğin WSDL) dayalı olarak birlikte çalışır. Arayüz tanımı , dile özgü hizmetin uygulamasını gizler . SOA tabanlı sistemler bu nedenle geliştirme teknolojilerinden ve platformlardan (Java, .NET, vb.) bağımsız olarak çalışabilir. Örneğin, .NET platformlarında çalışan C# ile yazılmış hizmetler ve Java EE platformlarında çalışan Java ile yazılmış hizmetler , ortak bir bileşik uygulama (veya istemci) tarafından tüketilebilir. Her iki platformda da çalışan uygulamalar, diğerinde çalışan hizmetleri yeniden kullanımı kolaylaştıran web hizmetleri olarak da tüketebilir. Yönetilen ortamlar ayrıca eski COBOL sistemlerini sarabilir ve bunları yazılım hizmetleri olarak sunabilir. .

BPEL gibi yüksek seviyeli programlama dilleri ve WS-CDL ve WS-Coordination gibi spesifikasyonlar , ince taneli hizmetlerin daha kaba taneli iş hizmetlerine düzenlenmesini tanımlayan ve destekleyen bir yöntem sağlayarak hizmet konseptini genişletir ve mimarlar da bunu yapabilir. bileşik uygulamalarda veya portallarda uygulanan iş akışlarına ve iş süreçlerine dahil edin .

Hizmet odaklı modelleme , SOA uygulayıcılarına hizmet odaklı varlıklarını kavramsallaştırma, analiz etme, tasarlama ve tasarlama konusunda rehberlik eden çeşitli disiplinleri tanımlayan bir SOA çerçevesidir. Hizmet odaklı modelleme çerçevesi (SOMF) teklifler bir modelleme dili ve çalışma yapısı veya başarılı hizmet odaklı modelleme yaklaşımı katkıda çeşitli bileşenlerini gösteren "Harita". Bir hizmet geliştirme planının "ne yapılması gerektiğini" belirleyen ana unsurları gösterir. Model, uygulayıcıların bir proje planı oluşturmasına ve hizmet odaklı bir girişimin kilometre taşlarını belirlemesine olanak tanır . SOMF ayrıca iş ve BT organizasyonları arasındaki uyumu ele almak için ortak bir modelleme gösterimi sağlar.

Elements of SOA, Dirk Krafzig, Karl Banke ve Dirk Slama
SOA meta modeli, The Linthicum Group, 2007

Kurumsal faydalar

Bazı kurumsal mimarlar , SOA'nın işletmelerin değişen piyasa koşullarına daha hızlı ve daha uygun maliyetli yanıt vermesine yardımcı olabileceğine inanıyor. Bu mimari tarzı, mikro (sınıflar) düzeyden ziyade makro (hizmet) düzeyinde yeniden kullanımı teşvik eder. Ayrıca mevcut BT (eski) varlıklarına ara bağlantıyı ve bunların kullanımını basitleştirebilir.

SOA ile fikir, bir kuruluşun bir soruna bütünsel olarak bakabilmesidir. Bir işletme daha fazla genel kontrole sahiptir. Teorik olarak, onları memnun edebilecek araç setlerini kullanan bir geliştirici kitlesi olmazdı. Ama bunun yerine, iş içinde belirlenmiş bir standarda kodlama yapacaklardı. Ayrıca, iş odaklı bir altyapıyı kapsayan kurumsal çapta SOA geliştirebilirler. SOA ayrıca araç sürücüleri için verimlilik sağlayan bir otoyol sistemi olarak da gösterilmiştir. Mesele şu ki, herkesin arabası olsa ve hiçbir yerde otoyol olmasaydı, herhangi bir yere hızlı veya verimli bir şekilde ulaşmak için herhangi bir girişimde işler sınırlı ve düzensiz olurdu. IBM Web Hizmetleri Başkan Yardımcısı Michael Liebow, SOA'nın "otoyollar inşa ettiğini" söylüyor.

Bazı açılardan SOA, bir devrimden ziyade mimari bir evrim olarak kabul edilebilir. Önceki yazılım mimarilerinin en iyi uygulamalarının çoğunu yakalar . Örneğin iletişim sistemlerinde, ağdaki diğer ekipmanlarla konuşmak için gerçekten statik bağlantılar kullanan çözümlerin çok az gelişimi gerçekleşti. Bir SOA yaklaşımını benimseyerek, bu tür sistemler kendilerini iyi tanımlanmış, yüksek düzeyde birlikte çalışabilir arayüzlerin önemini vurgulayacak şekilde konumlandırabilirler. SOA diğer öncülleri içerir Bileşen tabanlı yazılım mühendisliği örneğin uzak objelerin ve Nesne yönelimli analiz ve tasarım (OOAD), ÇORBA .

Bir hizmet, yalnızca resmi olarak tanımlanmış bir arabirim aracılığıyla kullanılabilen bağımsız bir işlevsellik birimi içerir. Hizmetler, üretilmesi ve geliştirilmesi kolay bir tür "nano-işletmeler" olabilir. Ayrıca hizmetler, alt hizmetlerin koordineli çalışması olarak inşa edilen "mega şirketler" olabilir.

Hizmetlerin uygulanmasının daha büyük projelerden ayrı projeler olarak ele alınmasının nedenleri şunları içerir:

  1. Ayırma, hizmetlerin organizasyonda yaygın olan daha büyük ve daha yavaş hareket eden projelerden bağımsız ve hızlı bir şekilde sağlanabileceği kavramını işletmeye teşvik eder. İş, hizmetleri çağıran sistemleri ve basitleştirilmiş kullanıcı arayüzlerini anlamaya başlar. Bu çevikliği savunur . Başka bir deyişle, ticari yenilikleri teşvik eder ve pazara sunma süresini hızlandırır.
  2. Ayırma, hizmetlerin tüketen projelerden ayrılmasını teşvik eder. Bu, hizmet, tüketicilerinin kim olduğu bilinmeden tasarlandığından, iyi tasarımı teşvik eder.
  3. Hizmetin dokümantasyonu ve test yapıları, daha büyük projenin ayrıntılarına dahil edilmez. Bu, hizmetin daha sonra yeniden kullanılması gerektiğinde önemlidir.

SOA, dolaylı olarak testi basitleştirmeyi vaat ediyor. Hizmetler özerktir, durumsuzdur, tam olarak belgelenmiş arayüzlere sahiptir ve uygulamanın kesişen endişelerinden ayrıdır. Bir kuruluş uygun şekilde tanımlanmış test verilerine sahipse, bir hizmet oluşturulurken test verilerine tepki veren ilgili bir saplama oluşturulur. Hizmet için tam bir regresyon testleri, komut dosyaları, veriler ve yanıtlar da yakalanır. Hizmet, çağırdığı hizmetlere karşılık gelen mevcut taslaklar kullanılarak bir 'kara kutu' olarak test edilebilir. Test ortamları, ilkel ve kapsam dışı hizmetlerin saplamalar olduğu, ağın geri kalanının ise tam hizmetlerin test dağıtımları olduğu yerlerde oluşturulabilir. Her arayüz kendi tam regresyon testi dokümantasyon seti ile tamamen belgelendiğinden, test servislerindeki sorunları belirlemek kolaylaşır. Test etme, yalnızca test hizmetinin belgelerine göre çalıştığını doğrulamak için gelişir ve ortamdaki tüm hizmetlerin belgelerinde ve test durumlarında boşluklar bulur. Tek karmaşıklık , idempotent hizmetlerin veri durumunu yönetmektir .

Örnekler, bir hizmetin yararlı olduğu düzeye kadar belgelenmesine yardımcı olmak için yararlı olabilir. Java Topluluk Süreci içindeki bazı API'lerin belgeleri iyi örnekler sağlar. Bunlar kapsamlı olduğundan, personel genellikle yalnızca önemli alt kümeleri kullanır. JSR-89 içindeki 'ossjsa.pdf' dosyası böyle bir dosyaya örnektir .

eleştiri

SOA, Web servisleri ile birleştirilmiştir ; bununla birlikte, Web hizmetleri, SOA stilini oluşturan kalıpları uygulamak için yalnızca bir seçenektir. Yerel veya ikili uzaktan yordam çağrısı (RPC) biçimlerinin yokluğunda, uygulamalar daha yavaş çalışabilir ve daha fazla işlem gücü gerektirebilir, bu da maliyetleri artırır. Çoğu uygulama bu ek masraflara maruz kalır, ancak SOA , uzaktan prosedür çağrılarına veya aracılığıyla çeviriye bağlı olmayan teknolojiler (örneğin, Java İş Entegrasyonu (JBI), Windows Communication Foundation (WCF) ve veri dağıtım hizmeti (DDS)) kullanılarak uygulanabilir. XML veya JSON. Aynı zamanda, ortaya çıkan açık kaynaklı XML ayrıştırma teknolojileri ( VTD-XML gibi ) ve çeşitli XML uyumlu ikili formatlar, SOA performansını önemli ölçüde iyileştirmeyi vaat ediyor.

Durum bilgisi olan hizmetler, hem tüketicinin hem de sağlayıcının, sağlayıcı ile tüketici arasında değiş tokuş edilen mesajlara dahil edilen veya bunlara atıfta bulunulan tüketiciye özgü aynı bağlamı paylaşmasını gerektirir. Bu kısıtlamanın dezavantajı , hizmet sağlayıcının her bir tüketici için paylaşılan bağlamı koruması gerekiyorsa, hizmet sağlayıcının genel ölçeklenebilirliğini azaltabilmesidir . Ayrıca, bir hizmet sağlayıcı ile bir tüketici arasındaki bağlantıyı arttırır ve hizmet sağlayıcıları arasında geçiş yapmayı daha zor hale getirir. Sonuç olarak, bazı eleştirmenler, SOA hizmetlerinin temsil ettikleri uygulamalar tarafından hala çok kısıtlı olduğunu düşünüyor.

Hizmet odaklı mimarinin karşılaştığı birincil zorluk, meta verilerin yönetimidir. SOA'ya dayalı ortamlar, görevleri gerçekleştirmek için birbirleriyle iletişim kuran birçok hizmeti içerir. Tasarımın birlikte çalışan birden fazla hizmeti içerebilmesi nedeniyle, bir Uygulama milyonlarca mesaj üretebilir. Daha fazla hizmet, farklı kuruluşlara veya hatta büyük bir güven sorunu yaratan rakip firmalara ait olabilir. Böylece SOA yönetişimi şeylerin planına girer.

SOA'nın karşılaştığı bir diğer önemli sorun, tek tip bir test çerçevesinin olmamasıdır. Servis odaklı bir mimaride bu servisleri test etmek için gerekli özellikleri sağlayan araçlar bulunmamaktadır. Zorlukların başlıca nedenleri şunlardır:

  • Çözümün heterojenliği ve karmaşıklığı.
  • Otonom hizmetlerin entegrasyonu nedeniyle çok sayıda test kombinasyonu.
  • Farklı ve rakip satıcılardan hizmetlerin dahil edilmesi.
  • Platform , yeni özelliklerin ve hizmetlerin kullanılabilirliği nedeniyle sürekli değişiyor.

Uzantılar ve varyantlar

Olay odaklı mimariler

Ana madde: Olaya dayalı mimari

Uygulama programlama arayüzleri

Ana madde: Uygulama programlama arayüzleri

Uygulama programlama arayüzleri (API'ler), geliştiricilerin bir web uygulamasıyla etkileşime girebilecekleri çerçevelerdir.

Web 2.0

Tim O'Reilly , algılanan, hızla büyüyen bir dizi web tabanlı uygulamayı tanımlamak için " Web 2.0 " terimini kullandı . Kapsamlı bir kapsamı olan bir konu, Web 2.0 ve hizmet odaklı mimariler arasındaki ilişkiyi içerir.

SOA, hizmetlerde uygulama mantığını tek tip olarak tanımlanmış bir arabirimle kapsülleme ve bunları keşif mekanizmaları aracılığıyla herkese açık hale getirme felsefesidir. Karmaşıklık-gizleme ve yeniden kullanım kavramı, aynı zamanda hizmetleri gevşek bir şekilde birleştirme kavramı, araştırmacılara iki felsefe, SOA ve Web 2.0 ve bunların ilgili uygulamaları arasındaki benzerlikleri detaylandırma konusunda ilham verdi. Bazıları Web 2.0 ve SOA'nın önemli ölçüde farklı unsurlara sahip olduğunu ve bu nedenle "paralel felsefeler" olarak kabul edilemeyeceğini iddia ederken, diğerleri iki kavramı tamamlayıcı olarak görüyor ve Web 2.0'ı küresel SOA olarak görüyor.

Web 2.0 ve SOA felsefeleri, farklı kullanıcı ihtiyaçlarına hizmet eder ve böylece tasarım ve ayrıca gerçek dünya uygulamalarında kullanılan teknolojiler açısından farklılıkları ortaya çıkarır. Ancak, 2008 itibariyle, kullanım durumları, hem Web 2.0 hem de SOA teknolojilerini ve ilkelerini birleştirme potansiyelini göstermiştir.

mikro hizmetler

Ana madde: Mikro hizmetler

Mikro hizmetler, dağıtılmış yazılım sistemleri oluşturmak için kullanılan hizmet odaklı mimarilerin modern bir yorumudur . Bir mikro hizmet mimarisindeki hizmetler, bir amacı gerçekleştirmek için ağ üzerinden birbirleriyle iletişim kuran süreçlerdir . Bu hizmetler , dil ve çerçeve seçimini kapsüllemeye yardımcı olan ve seçimlerini hizmetin içinde bir endişe haline getiren teknolojiden bağımsız protokolleri kullanır . Mikro hizmetler, 2014'ten bu yana (ve DevOps'un piyasaya sürülmesinden sonra) popüler hale gelen ve aynı zamanda sürekli dağıtım ve diğer çevik uygulamaları vurgulayan yeni bir SOA gerçekleştirme ve uygulama yaklaşımıdır .

Mikro hizmetlerin ortak olarak kabul edilen tek bir tanımı yoktur. Aşağıdaki özellikler ve ilkeler literatürde bulunabilir:

  • ince taneli arayüzler (bağımsız olarak konuşlandırılabilir hizmetlere),
  • iş odaklı geliştirme (örneğin etki alanı odaklı tasarım ),
  • İDEAL bulut uygulama mimarileri,
  • çok dilli programlama ve kalıcılık,
  • hafif konteyner dağıtımı,
  • merkezi olmayan sürekli teslimat ve
  • Bütünsel hizmet izleme özelliğine sahip DevOps.

Etkileşimli uygulamalar için hizmet odaklı mimariler

Gerçek zamanlı yanıt süreleri gerektiren etkileşimli uygulamalar, örneğin düşük gecikmeli etkileşimli 3d uygulamalar, bu tür uygulamaların özel ihtiyaçlarına hitap eden belirli hizmet odaklı mimariler kullanıyor. Bunlar, örneğin düşük gecikmeli optimize edilmiş dağıtılmış hesaplama ve iletişimin yanı sıra kaynak ve örnek yönetimini içerir.

Ayrıca bakınız

Referanslar

Bu makaleyi dinleyin ( 54 dakika )
Sözlü Wikipedia simgesi
Bu ses dosyası , 27 Ekim 2011 tarihli bu makalenin bir revizyonundan oluşturulmuştur ve sonraki düzenlemeleri yansıtmamaktadır. ( 2011-10-27 )
( Sesli yardım  · Daha çok konuşulan makaleler )