Vítejte na blog.vyvojar.cz Přihlásit | Registrovat | Pomoc
Titulní Blogy Fotky Soubory

Endpoint

SOA a web services radio

  • Loučím se

    Jak vidíte na stránkách Endpoint blogu, moje blogovací aktivita odumřela. Jako u každého, nadšení pro blogování jde v čase nahoru a dolu a moje je zjevně na zero levelu. Neznamená to, že mediální prostor orientující se na IT úplně opouštím, mj. své aktivity zvolna napírám směrem k pěkné open-source platformě - pokouším se rozjet web o JBossu. Ale tam jde o technologie odlišné od světa Microsoftu, kterému se věnuje většina bloggerů na Vývojáři. Bylo tu fajn, mějte se pěkně, Michalovi děkuji za prostor pro vytrubování endpointích zpráviček, snad zase někde někdy... :)
  • High Availability webových služeb

    Jedním z nároků na "mission critical" aplikace je vysoká dostupnost. Služby musí být stále přístupné, v přijatelném a předvídatelném čase. Řešením pro tento požadavek je fail-over clustering, tedy redundance serverů zajišťující převzetí zpracování, pokud jeden ze serverů selže. Pro různé technologie je to prošlápnutá cesta, ale co clustering webových služeb? Nejjednoduší variantou jsou bezestavové služby, zde je jedno, který uzel v clusteru požadavek zpracuje. Pro tento případ vidím dvě možnosti:
    1. Umístit do WSDL služby více soap adres a zajistit, aby se klient při selhání jednoho uzlu zkusil připojit na další. Toto je velmi nevhodné řešení, protože klient by o existenci clusteru neměl mít ani ponětí. Jestliže by byl cluster někdy překonfigurován, znamenalo by to změnu WSDL a propagaci této změny ke klientům, což není zrovna žádoucí.
    2. Zajistit, aby klient směřoval své volání na load balancer, který přepošle požadavek na jeden z dostupných uzlů. Load balancer je podstatným prvkem clusteru a přepisování HTTP hlavičky není žádný problém, tedy proč ne.
    Mnohem horší situace začíná u webových služeb, které jsou stavové - mezi klientem a službou probíhá konverzace ve formě výměny více zpráv. Opět se hlásí řešní s load balancerem, který podle nějakého algoritmu rozhazuje požadavky na žijící uzly. Navíc musíme zajistit, aby se stavová informace replikovala na všechny uzly, aby zpracování nebylo závislé na dostupnosti uzlu, který požadavky daného klienta začal řešit. Opět je několik možností:
    1. Replikace HTTP sessions - není vhodná, protože nic nezajišťuje, že si klient drží během konverzace stejnou session, zvlášť když půjde o konverzaci dlouhotrvající.
    2. Replikace objektů, na které je možné se odkazovat nějakým identifikátorem. V J2EE je to případ stateful session beanů, které je možné identifikovat tzv. handlem. Webová služba při zpracování příchozího požadavku vyhledá příslušnou stavovou beanu např. s využitím patternu Service Locator), která zajistí zpracování.
    3. Ukládání stavu do databáze. Pak není co řešit, webová služba vyzobne z databáze stav, požadavek zpracuje a modifikovaný stav uloží.
    Bohužel, nic není tak růžové, jak se zdá. Napovím, že jeden problém přichází s WS-Addressingem, ale o tom až někdy příště.
  • Medicína na logovací soubory - mTail

    I když plně mimo topic blogu, tahle free windows utilitka mě při pondělním ránu naladila, že se s vámi musím podělit. Pokud máte problém sledovat dlouhé logy např. aplikačních serverů, do kterých je připisováno na konec, pomůže jednoduchý nástroj, který uživatele Linux/UNIXů dávno znají - tail. Ten vám zobrazí poslední řádky daného souboru. mTail je rozšířená varianta pro Windows, která přidává hezké možnosti pro filtrování, alerting, konfiguraci bufferu atd.
  • Weblogic Workshop & Eclipse

    Jak jsem poslední dobou zaměstnaný, a také líný, tato zpráva mě potěšila natolik, že se s vámi chci podělit. WebLogic Workshop IDE bude předělán do Eclipsu, release s kódovým jménem Daybreak můžeme čekat na podzim tohoto roku, už se těším. Že by mě tedy konečně mohlo být dovoleno umět ovládat jen jedno IDE? ;)
  • WS a transakce

    Dělat transakce v těsně propojených systémech je dávno prošlapaná cesta - ACID principy. Co ovšem s aplikacemi propojenými volnou vazbou, např. přes webové služby? Zde mohou transakce trvat mnohem déle - hodiny, dny... Ale zdroje nemohou být po celou dobu zamčené. Řešení se těžko hledá, ale pomoci může: asynchronicita komunikace, zajištění její spolehlivosti a kde to jde, kompenzační transakce místo zamykání zdrojů. Microsoft, IBM a BEA vytvořily trojici specifikací WS-Coordination, WS-BusinessActivity a WS-AtomicTransaction. Proběhl interop workshop, ale žádný z vendorů zatím tyto specifikace v komerčním produktu neimplementoval. Nezbývá, než si zatím poradit sami.
  • Business rules

    Představte si, že máte integrační platformu, na které zpracováváte business procesy. Vše už je v produkčním nasazení, ale čas od času se ukáže, že je nutné udělat drobnou změnu. Editovat kvůli tomu na x místech business proces, to není to pravé ořechové. Řešením mohou být business pravidla, která se uplatňují v procesu, ale je možné je měnit vně.
    Na trhu je pro business rule management (BRM) mnoho řešení, já jsem nyní věnoval nějaký čas evaluaci ILOG JRules. Hezké na této aplikaci je možnost vytváření pravidel v (téměř) přirozeném jazyce. Tedy, nejdříve musíte vhodně onálepkovat metody tříd ve vašem objektovém modelu, pak z nich můžete teprve pravidla tvořit. Přirozený jazyk je fajn pro managery. Ale samozřejmě, každé pravidlo v přirozeném jazyce má ekvivalentní low-level reprezentaci, pro programátory. A v tom mají JRules jednu limitující vlastnost: převod pravidel mezi reprezentacemi je jednosměrný - z high do low level. Navíc, práce s pravidly v přirozeném jazyku je možné jen v JRules IDE, neexistuje plugin např.do Eclipse, který by to plně umožňoval. To mě trochu mrzí, jinak mají JRules mnoho dobrých vlastností, např. integraci s WLI atd.
    Pokud znáte někdo nějaké jiné kvalitní BRM řešení, prosím dejte vědět, rád se přiučím (já vím, BizTalk je fajn, ale něco pro J2EE ;)
  • Přesun na blog.vyvojar.cz

    Je mi potěšením, že mohu využívat služeb serveru vyvojar.cz a přesunout sem svůj blog o webových služnách a architektuře orientované na služby. Nějaký čas mi bude trvat přesun starých příspěvků, prosím o trpělivost. Zatím si je můžete přečíst zde. Děkuji Michalu Bláhovi za zřízení a pomoc.
  • Java for .NET

    Asi se divíte názvu, ale je to tak, IKVM je implementace Javy pro .NET umožňující zpřístupnit javovský kód v .NETu. Skvělá věc!
  • Konec ESB?

    Phil na Loosely Coupled (přes Radoše) předpovídá konec pro ESB. Základním argumentem je, proč duplikovat schopnosti messagingu, když už je máte ve svém stávajícím řešení? Lépe udělat řešení jen na WS standardech a ESB se svými omezeními přeskočit.
  • Amazon Simple Queue Service

    Minulý týden Amazon ve svém developerském newsletteru představil beta verzi webové služby pro bufferování zpráv mezi distribuovanými komponentami aplikací. Každý zaregistrovaný vývojář si může vytvořit množství front, limitem je jen počet 4000 záznamů ve frontách a velikost 4 KB na zprávu. Fronty jsou spolehlivé (reliable) a použití této web service je prozatím bezplatné. Je to tedy cesta, jak efektivně a levně provést decoupling aplikace a vyřešit problém producent-konzument za pomoci webových služeb.

  • Registr

    Při přechodu na SOA se přirozeně objevuje otázka, kde ukládat metadata o dostupných službách, jak je organizovat, aby byly dohledatelné a použitelné, jak spravovat jejich životní cyklus, jak zajistit verzování, znovuvyužitelnost atd. atd. K tomu všemu by měl sloužit registr.

    V současné době jsou k dispozici tři použitelná řešení: Blue Titan Data Director, Systinet Registry a Infravio X-registry. První dvě stručně představuje Jeff Schneider ve své nedávném příspěvku.
  • Odborníci o SOA

    Na SearchWebServices.com se zeptali expertů z několika firem, co chápají pod pojmem architektura orientovaná na služby. Mě se nejvíce líbila odpověď Randyho Heffnera z Forrester a Stefana Tilkova z InnoQ.

    Zarazilo mě, že chybí odpovědi lidí z IBM a Microsoftu. Nemají, co k tomu říct, co nabídnout?

  • Rozhovor s CEO Systinetu

    Na Infoworldu vyšel rozhovor s šéfem Systinetu, který rozpráví o vývoji web services, SOA a budoucnosti Systinetu.
  • WS-Management

    Microsoft, Intel, AMD, Dell a Sun zveřejnili specifikaci popisující protokol pro management nejen webových služeb, ale i zařízení jako set-top boxy, PCčka, servery apod. Specifikace vychází z již existujího WS-Transferu, WS-Eventingu, WS-Enumeration atd.

    Částečně se překrývá se specifikací Web Services Distributed Management (WS-DM). Ta je navržená ke sledování performance webových služeb, WS-Management je zamýšlen ke správě zařízení za pomocí WS protokolů.
  • Analýza a design SOA

    SOA neříká přímo, jak provést analýzu a design aplikace. Lze využít starší techniky jako OOAD nebo BPM? Jednotlivé elementy analýzy a designu jsou rozebrány ve výborném článku na IBM developerWorks.
Více článků Další stránka »
Powered by Community Server (Personal Edition), by Telligent Systems
Vyvojar.cz na prodej!