Posts

Po více jak dvou letech se končí moje soupoutničení s verzovacím systémem Perforce (P4). Z počátku nebylo naše soužití zcela harmonické. Ale poté, co jsem přijal pravidla hry (které P4 nastavuje) jsem si tento systém oblíbil. A nyní bych se chtěl o své zkušenosti podělit.

Počáteční rozčarování a zklidnění

Srážka nepřipraveného vývojáře s P4 může být dost nepříjemná a frustrující. Vývojáři mají dost často rutinní zkušenost s SVN a podobnými nástroji. P4 má v některých aspektech jinou filozofii, která (z hlediska třeba SVN) nemusí být intuitivní. Když člověk nepochopí principy, které se za tím skrývají, může dopadnout podobně, jako evropský řidič v Anglii (Irsku, Austrálii, ...) - nadává, jak to "ty pitomý Angláni blbě vymysleli".

Pokud se člověk rozhodne nepřijmout filozofii P4, tak může skončit jako někteří z mých kolegů, kteří pořád trousí hlášky o "debilním Perforsu". Holt rok je asi příliš krátká doba na to, naučit se to pořádně ;-)

Mě zkušenost naučila číst (v) dokumentaci. Rád totiž dělám věci správně a (dobrá či dokonce kvalitní) dokumentace mi přijde jako efektivní způsob jak zjistit, jak věci fungují. A navíc si člověk zbytečně nepřenáší zlozvyky odjinud. Takže než s P4 bojovat, přijde mi lepší přijmout jeho pravidla hry. On se vám za to odvděčí a rozkvete vám pod rukama :-)

Možná teď čekáte, že napíšu něco o té filozofii a o věcech, které jsou "jinak". Ale nenapíšu. Nechci se pouště do nějaké srovnávací studie, kterou by to asi skončilo. Prostě jen teď uvedu, jak P4 používám já.

Typický lifecycle

Následující lifecycle mi vykrystalizoval během těch dvou let používání a osvědčil se mi, jako účinný prostředek proti některým nástrahám P4.

1. Check Out (Ctrl+E)    konkrétního projektu (nebo jeho části) do nového changelistu (Alt+N -> Alt+C).
2. Editace zdrojových kódů.
3. Na changelistu, který chci komitovat: Revert Unchanged Files   .
4. Na adresáři, který jsem původně checkoutoval: Reconcile Offline Work a přidat eventuální soubory do changelistu.
5. Kontrola souborů v changelistu. Pokud byly soubory modifikované, tak Diff Against Have Revision (Ctrl+D).
6. Submit (Ctrl+S -> Alt+S)   .

Z tohoto seznamu bych vypíchnul body 3 a 4. Revert Unchanged Files je důležitý, aby se nekomitovaly nezměněné soubory. Reconcile Offline Work zajistí přidání (Mark for Add   ) nových souborů do changelistu.

Changelisty

Changelist je v P4 seskupením souborů, které chci komitovat. Já si vytvářím nový changelist pro každý kousek práce, typicky jedna položka v issue tracking systému. Novému changelistu pak nejčastěji dávám popis ve stylu: <issue ID>; <issue name>, <description>. Např.: SWS-12; Gradle tutorial, Jetty initial implementation.

Pending Changelists

Na záložku Pending Chagelists, která zobrazuje moje chagelisty, se přepnu klávesovou zkratkou Ctrl+1, nebo ikonou   .

P4 nabízí také tzv. default changelist, který ale používám pouze v jediném případě - pokud v changelistu potřebuju mít něco, co nechci komitovat a později to revertnu. Pokud bych to náhodou přesto potřeboval, vždy se to dá převést do jiného changelistu. Důvod, proč něco nekomitovat a mít to v changelistu je prostý - pokud si natáhnu do lokálního workspace nějakou revizi z depotu, P4 všechny soubory nastaví na read-only. A to může některým editorům vadit. Takže to šupnu do defaultu.

Shelved Files

Aneb soubory na poličce. Někdy mám něco rozpracovaného, ale nechci to ještě komitovat. Zároveň ale nechci, aby úpravy byly pouze u mne na lokálním počítači. Tak je přesunu z changelistu do poličky na serveru.

Shelved Files

Bookmarks

Souborová struktura v rámci daného depotu může být velmi rozsáhlá (na aktuálním projektu je to přes 10 000 souborů). Proto jsem si oblíbil záložky (Bookmarks) s nastavenými klávesovými zkratkami.

Bookmarks

Klávesové zkratky

P4 má výborného grafického klienta: P4V. A tak jako u každé grafiky, i zde se hodí (a efektivitě napomůžou) klávesové zkratky. Tyhle jsem si oblíbil:

• Get Latest Revision: Ctrl+Shift+G
• Check Out: Ctrl+E
• Submit: Ctrl+S -> Alt+S
• Revert Files: Ctrl+R
• Diff Agains the Have Revision: Ctrl+D
• Next Diff (P4Merge): Ctrl+2
• Previous Diff (P4Merge): Ctrl+1
• Close (P4Merge): Ctrl+W
• Pending Changelists: Ctrl+1
• Submitted Changelists: Ctrl+2
• Skok na zazáložkovaný soubor/adresář: Ctrl+Shift+1 (až n)
• Skok do file browseru z daného adresáře/souboru: Ctrl+Shift+S

K dokonalé spokojenosti mi chybí absence dvou zkratek: Revert Unchanged Files a Reconcile Offline Work.

Závěr

Myslím, že dobrá znalost (aktuálně používaného) verzovacího systému patří ke ctnostem každého vývojáře. Za ty dva roky jsme se s P4 docela skamarádili a pokud bych ho někdy v budoucnu zase potkal, tak se rozhodně nebudu zlobit.

A co vy, máte nějakou oblíbenou P4 vlastnost? Nebo vás naopak na něm něco rozčiluje? ;-)

Související články

• Perforce, instalace serveru P4D
• Perforce, ignorování souborů a adresářů
• Perforce, ignorování souborů a adresářů ve streamu

Externí odkazy

Messaging bridge je šikovné řešení, pokud potřebujeme distribuovat zprávy mezi několika messaging systémy. Potřeboval jsem vytvořit JMS bridge na WebLogicu a protože jsem si oblíbil WebLogic Scripting Tool (WLST), tak jsem si napsal skript.

Nicméně dnes, vás milí čtenáři, nechci odfláknout pouhým WLST skriptem, ale podíváme se na téma trochu zeširoka. Prvně si zasadíme JMS bridge do kontextu Enterprise Integration Patterns (EIP), pak se podíváme, jak jde bridge naklikat ve WebLogic konzoli. A samozřejmě vás neochudím o to WLST :-)

Messaging Bridge

Nebyl bych to já, kdybych se nevytasil s nějakým patternem. Tak tady je - Messaging Bridge, jak je definován v EIP. (Věty kurzivou jsou citacemi z knihy Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions.)

Messaging Bridge řeší následující problém: "How can multiple messaging systems be connected so that messages available on one are also available on the others?" Integrační vzory řeší problémy obecně. V tomto případě jde o to, jak dostat zprávy z jednoho systému na jiný. Např. jak dostat zprávy z WebSphere MQ na MSMQ. Nebo JMS. Nebo TIBCO Randevouz. Nebo... Jasný, ne? Odkudkoliv kamkoliv.

Messaging Bridge tedy je "a way for messages on one messaging system that are of interest to applications on another messaging system to be made available on the second messaging system as well."

Protože většinou neexistuje způsob, jak propojit dva různé messaging systémy, propojují se jednotlivé, odpovídající kanály na daných systémech. "The Messaging Bridge is a set of Channel Adapters ... where each pair of adapters connects a pair of corresponding channels. The bridge acts as a map from one set of channels to the other and transforms the message format of one system to the other."

Vzor Messaging Bridge (zdroj EIP)

JMS Bridge

JMS bridge je speciální variantou Messaging bridge, který má několik omezení, nebo spíše možná zjednodušení. Tři hlavní jsou:

• Propojuje pouze JMS systémy (různých dodavatelů).
• Zprávy netransformuje (protože pracuje pouze s JMS zprávami).
• Zprávy z jednoho (zdrojového) systému přeposílá na jiný (cílový). Čili nečiní je pouze dostupnými, ale provádí routing/forwarding.

JMS bridge běžně poskytují všichni dodavatelé JMS systémů, např.:

• HornetQ (JBoss)
• ActiveMQ (Apache)
• WebLogic (Oracle)

Zajímavým atributem u JMS bridge je Quality of Service (QoS), který říká, v jakém modu budou zprávy přeposílány:

• At most once - nanejvýš jednou. Toto je nejbenevolentnější mod. Zpráva buď dorazí (maximálně jednou), anebo taky ne. A nám to tak vyhovuje.
• Duplicates OK - duplicity jsou v pořádku. V tomto modu jsou zprávy potvrzeny, že dorazily na cílový systém. Může se stát, že stejná zpráva nám dorazí ve více instancích, ale to je v pořádku - řekli jsme přece, duplicity jsou OK. Výhodou je, že se žádná zpráva neztratí.
• Exactly once - přesně jednou. Toto je nejvíc striktní mod, který nám nejen zaručuje, že každá zpráva dorazí na cílový systém, ale taky že tam dorazí právě jednou. Takový závazek není jen tak a zajistí nám ho JTA, čili distribuovaná transakce.

WebLogic JMS Bridge

Vytvoření JMS bridge na WebLogicu je otázkou chvilky, stačí mít připraveny správné ingredience. Co budeme potřebovat?

• URL (a credentials) zdrojového serveru,
• URL (a credentials) cílového serveru,
• JNDI JMS adapteru (transakční, nebo netransakční)
• eis.jms.WLSConnectionFactoryJNDIXA
• eis.jms.WSLConnectionFactoryJNDINoTX
• JNDI Connection Factory,
• JNDI JMS destinace (fronty),
• Quality of Service
• Exactly-once
• Duplicate-okay
• Atmost-once

Definice JMS bridge

Že nám bridge funguje, poznáme podle jeho stavu (záložka Monitoring) a taky doporučuju si nějakou zprávu cvičně přeposlat. Světe div se, ale transakce můžou zlobit.

Stavy JMS bridgů (záložka Monitoring)

WLST

No a máme tady velké finále, ke kterému jsem nenápadně, ale cílevědomě směřoval. Takže tady je: WLST v celé své pythoní kráse :-)

#
# properties
#
user = 'weblogic'
password = 'welcome1'
server = 't3://sandman:7001'
# source credentials
sourceJmsUser = 'weblogic'
sourceJmsPassword = 'welcome1'
sourceURL = 't3://sandman:7003'
# target credentials
targetJmsUser = 'weblogic'
targetJmsPassword = 'welcome1'
targetURL = 't3://sandman:7004'
# JMS servers
servers = ['SourceServer']
targets = []
# queues
queues = [
    'EVM_EVE_CMS',
    'EVM_EVE_FC',
    'EVM_EVE_GEN',
    'EVM_EVE_PTS',
    'NTF_PARTY',
    'NTF_PRODUCT']
adapterJNDI = 'eis.jms.WLSConnectionFactoryJNDIXA'
connectionFactory = 'jms/sws/SWSConnectionFactory'
qualityOfService = 'Exactly-once'
jndiPrefix = 'jms/sws/'

# connection
connect(user, password, server)

# edit mode
edit()
startEdit()

# get targets
for server in servers:
    targets.append(getMBean('/Servers/' + server))
print '\nTargets:', targets, '\n'

#
# create bridges
#
print '\n### Create bridges:\n'
for queue in queues:
    bridgeName = queue + '_bridge'
    sourceName = queue + '_source'
    targetName = queue + '_target'
    # delete an old bridge
    ref = getMBean('/MessagingBridges/' + bridgeName)
    if ref != None:
        cd('/MessagingBridges')
        delete(bridgeName, 'MessagingBridge')
    # delete an old source destination
    ref = getMBean('/JMSBridgeDestinations/' + sourceName)
    if ref != None:
        cd('/JMSBridgeDestinations')
        delete(sourceName, 'JMSBridgeDestination')
    # delete an old target destination
    ref = getMBean('/JMSBridgeDestinations/' + targetName)
    if ref != None:
        cd('/JMSBridgeDestinations')
        delete(targetName, 'JMSBridgeDestination')
    # create a new source destination
    cd('/')
    cmo.createJMSBridgeDestination(sourceName)
    cd('/JMSBridgeDestinations/' + sourceName)
    cmo.setAdapterJNDIName(adapterJNDI)
    cmo.setConnectionFactoryJNDIName(connectionFactory)
    cmo.setConnectionURL(sourceURL)
    cmo.setDestinationJNDIName(jndiPrefix + queue)
    cmo.setUserName(sourceJmsUser)
    cmo.setUserPassword(sourceJmsPassword)
    print 'Source:', cmo
    # create a new target destination
    cd('/')
    cmo.createJMSBridgeDestination(targetName)
    cd('/JMSBridgeDestinations/' + targetName)
    cmo.setAdapterJNDIName(adapterJNDI)
    cmo.setConnectionFactoryJNDIName(connectionFactory)
    cmo.setConnectionURL(targetURL)
    cmo.setDestinationJNDIName(jndiPrefix + queue)
    cmo.setUserName(targetJmsUser)
    cmo.setUserPassword(targetJmsPassword)
    print 'Target:', cmo
    # create a new bridge
    cd('/')
    cmo.createMessagingBridge(bridgeName)
    cd('/MessagingBridges/' + bridgeName)
    cmo.setSourceDestination(getMBean('/JMSBridgeDestinations/' + sourceName))
    cmo.setTargetDestination(getMBean('/JMSBridgeDestinations/' + targetName))
    cmo.setStarted(true)
    cmo.setQualityOfService(qualityOfService)
    cmo.setTargets(targets)
    print 'Bridge:', cmo, '\n'

# save and finish
save()
activate()
disconnect()
exit()

Související články

• Vytvoření WebLogic Distributed Queue pomocí WLST
• Vytvoření JDBC datasource na WebLogicu pomocí WLST
• Enterprise integrace, messaging
• Dead Letter Channel nebo Invalid Message Channel? Toť otázka

SOA Suite je zajímavou kompilací technologií, které, poskládány dohromady, stojí na architektonickém principu SCA (Service Component Architecture). Patří sem například implementace BPELu, business rules a human tasků. A jednou z těchto technologií je i Event Delivery Network (EDN), což je implementace paradigmatu Event Driven Architecture (EDA).

Event Driven Architecture

Even Driven Architecture (EDA) může být alternativou, nebo doplňkem k Servisně orientované architektuře (SOA). Ale EDN se netýká pouze SOA - tento architektonický princip najdeme i uvnitř GUI frameworků, jako je Java Swing, nebo Apache (dříve Adobe) Flex.

Jak už napovídá název, vše se v této architektuře motá kolem událostí. Událost je v EDA first-class citizen. Vlastně je to jediný citizen (obyvatel). Ale co to vlastně ta událost je? Událost je v podstatě zpráva, podobně jako zpráva má hlavičku a tělo. V hlavičce jsou samozřejmě meta-data, např. jméno a typ zprávy, timestamp apod. Zásadní rozdíl je v obsahu těla události (payload), ten bývá zpravidla velmi malý a měl by obsahovat pouze popis faktu, který událost instancoval. Někdy payload ani být nemusí - pokud je událost určitého typu, stačí pouze vědět, že nastala.

A jak taková událost zapadá do architektury? Dalším významem akronymu EDA by mohlo být: Extremely Decoupled Architecture. Události, které nejsou nijak svázány s konkrétním producentem, jsou publikovány do nějaké centrální generické infrastruktury. Producenti publikují události stylem fire-and-forget a vůbec se nestarají o to, kdo je jejich konzumentem.

Konzumentem je pak kdokoli, kdo se zajímá o výskyt určitého typu události. Pro konzumenty je původ události neznámý - neví kdo ji publikoval, oni se pouze dozvědí, že nastala. Na konzumentovi pak leží veškerá zodpovědnost za správné business zpracování události. S tím souvisí i to, že příjemce může konzumované události filtrovat.

Event Driven Architecture (barvy představují typy událostí)

Z předešlého komponentového diagramu vyplývá několik věcí. Jednak že v EDA existují v podstatě jen dva základní komponenty - Event Coordinator, který si můžeme představit jako jakýsi "event bus" (podle vzoru service bus) pro události, který se stará o publikování událostí, přihlášení (subscription) konzumentů apod.

A pak jednotlivé uzly (nody). Ty mohou fungovat buď jako producenti událostí (Node 3), nebo jejich konzumenti (Node 2, Node 5), anebo obojí (Node 1, Node 4). Každý node může publikovat nebo přijímat více typů událostí. Že jeden typ události může být konzumovaný více nody asi nikoho nepřekvapí (oranžová událost konzumovaná Nody 1 a 4). Daný typ události ale může taky být publikovaný více producenty (fialová událost publikovaná Nody 3 a 4).

To by, myslím, mohlo stačit, jako takový velmi lehoulilinký úvod do EDA a teď se podíváme na jednu její konkrétní implementaci.

Event Delivery Network

Event Delivery Network (EDN), která je součástí SOA Suite, je infrastruktura (postavená na JMS), která poskytuje deklarativní způsob definice událostí, jejich publikování a registraci jejich konzumace. Tři hlavní entity, se kterými pracuje jsou producent událostí, konzument událostí a události samotné.

Definice události

Události jsou v EDN definované názvem a typem a jsou uloženy v souboru s příponou edl. Tento soubor může být umístěný buď v rootu projektu, nebo v MDS (MetaData Services repository).

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<definitions
 xmlns="http://schemas.oracle.com/events/edl"
        targetNamespace="http://sw-samuraj.blog/events/SimpleEvent-v1">
  <schema-import
          namespace="http://sw-samuraj.blog/events/simpleMessage-v1"
          location="xsd/simpleMessage-v1.0.xsd"/>
  <event-definition name="SimpleEvent">
    <content
            xmlns:sim="http://sw-samuraj.blog/events/simpleMessage-v1"
            element="sim:simpleMessage"/>
  </event-definition>
</definitions>

Definice události

Typ je popsán pomocí XSD:

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
     xmlns:sim="http://sw-samuraj.blog/events/simpleMessage-v1"
     targetNamespace="http://sw-samuraj.blog/events/simpleMessage-v1"
     elementFormDefault="qualified">
  <xsd:element name="simpleMessage">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="timestamp" type="xsd:dateTime"/>
        <xsd:element name="status">
          <xsd:simpleType>
            <xsd:restriction base="xsd:string">
              <xsd:enumeration value="ON"/>
              <xsd:enumeration value="OFF"/>
            </xsd:restriction>
          </xsd:simpleType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Typ události definovaný v XSD

Publishers

Producentem události může být buď BPEL proces, nebo Mediator. V případě Mediatoru je publikování události přímočaré - v definici akce se místo invoke zavolá raise s patřičnou události.

Publikování události v Mediatoru

Graficky pak vypadá kompozitní aplikace s publikujícím Mediatorem takto:

Mediator event publisher (kompozitní aplikace)

U BPEL procesu je situace maličko složitější. Vzhledem k tomu, že BPEL je otevřený standard, do kterého události nepatří, řeší to SOA Suita (standardním) BPEL extension. Událost se tak dá publikovat pomocí rozšíření z aktivity Invoke.

Publikování události v BPELu z aktivity Invoke

BPEL event publisher (kompozitní aplikace)

Všimněte si, že jak v případě Mediatoru, tak BPELu končí implementace publikování události na dané komponentě. Kdyby totéž bylo implementováno pomocí messagingu, musel by být v kompozitní aplikaci definován ještě JCA adaptér s pevně uvedenou destinací. Tohle u EDA/EDN není potřeba.

Subscribers

Konzumentem události může být opět buď Mediator nebo BPEL komponent.

Subskripce události v Mediatoru

Mediator event subscriber (kompozitní aplikace)

Podobně jako u publikování i u konzumace událostí si BPEL vypomáhá rozšířením, tentokrát v rámci aktivity Receive.

Subskripce události v BPELu v aktivitě Receive

BPEL event subscriber (kompozitní aplikace)

Monitorování událostí

Asi trochu překvapí, že již publikované, ale ještě nezkonzumované události nelze nikde vidět. Alespoň ne standardními nástroji. V podstatě lze vidět pouze "historický otisk" událostí. Něco jako: tudy kráčely dějiny :-)

Cestu události lze vidět v Enterprise Manageru:

Audit trace události (Enterprise Manager)

V uvedeném logu publikuje Mediator Publisher událost, která je konzumována dvěma konzumenty: Mediator Subscriber a BPEL komponent BpelSubscriber. Zároveň je vidět, že Enterprise Manager loguje celou cestu události - ačkoliv jsou producent a konzumenti události od sebe odděleni a vůbec o sobě nemají povědomí, v audit logu je to zaznamenáno jako jeden souvislý tok události.

BPEL nebo Mediator?

Na základě čeho se rozhodnout, kterou komponentu použít pro konzumaci/publikování události? Jednodušší a přímočařejší je použití Mediatoru. Koneckonců to doporučuje i sám Oracle. BPEL má jedinou výhodu - jako konzument může události korelovat. Čili pokud je reakcí na nějakou událost jiná událost a obě dvě jsou zpracovávány stejnou kompozitní aplikací, tak jejich korelace je možná pouze v BPEL procesu.

Závěr

Event Delivery Network (EDN) je standardní součástí SOA Suity a nabízí out-of-the-box implementaci Event Driven Architecture (EDA). Pokud nepotřebujeme robustní a konfigurovatelné messaging řešení, může být EDN vhodnou, rychle provozovatelnou alternativou.

Rozhodně bych ale EDN nedoporučoval použít pro kritické části systému. Byť je postavena na prověřené JMS platformě, její možnosti z hlediska konfigurace, provozování, monitoringu atd. jsou velmi omezené - berte jak to je, nebo nechejte být.

Související články

• Odstranění metadat z MDS
• Java a fault handling policies v Oracle SOA Suite
• Custom XSLT funkce v Oracle SOA Suite

Půlrok se sešel s půlrokem a já jsem si vystřihnul další certifikaci. Tentokrát jsem chtěl něco, čím bych zakončil své roční působení na projektu a důstojně :-) tak završil trnitý proces získávání znalostí o nové technologii: Oracle SOA Suite.

Okolnosti tomu chtěly, že jsem se zrovna trefil do přelomu, kdy Oracle jednu  SOA certifikaci nahrazuje jinou. Aktuální certifikace, která je k dispozici od letošního ledna, se jmenuje  Oracle SOA Suite 11g Certified Implementation Specialist. Já, protože jsem se ke zkoušce přihlásil již dříve, jsem nyní obdržel certifikaci Oracle Service Oriented Architecture Infrastructure Implementation Certified Expert. Uff! To je titul :-/

Každopádně, co je nám po jménu? Podstatné je, jestli se obě zkoušky od sebe nějak obsahově liší. Liší? Ano, ale pouze drobně - v nové certifikaci přibylo pouze něco málo o governance, deploymentu a monitoringu, ale gró zůstává stejné: jednotlivé komponentní technogie (viz Exam Topics).

Jak dlouho jsem se na certifikaci připravoval? Přípravě přímo na zkoušku jsem věnoval cca 3 týdny - přečetl jsem si guide (viz dále) a prošel testovací otázky. Ale obecně jsem k certifikaci studijně směřoval téměř celý rok. Za jeden z podstatných zdrojů vědomostí totiž považuji přímou zkušenost s technologií - 7 měsíců intenzivního "programování".

Kniha

Vývoj samotný z učedníka mistra neudělá. Primárním zdrojem informací jsou pro mne knihy, takže od nich jsem začal: hned z počátku práce na projektu jsem si koupil knihu Oracle SOA Suite 11g Handbook.

Jde o 800stránkový opus a pokud to někdo myslí se SOA Suitou vážně, tak rozhodně tuto knihu doporučuji - obsahuje vyčerpávající sumu témat (daleko přesahující rozsah zkoušky), které umožní pochopit principy, které za SOA Suitou stojí a provede návrhem, vývojem, testováním a provozem jednotlivých komponent a technologií. Ještě jednou: vysoce doporučuji!

Školení

Školení obvykle v portfoliu přípravných zdrojů nemám, tentokrát se mi ovšem naskytla příležitost, tak jsem ji využil a absolvoval školení hned tři:

• Oracle SOA Suite 11g Implementation Bootcamp
• Oracle Service Bus 11g
• Oracle BPM Suite 11g Implementation Bootcamp

Certifikační guide

Závěr

Související články

Moje řešení má znaky obou výše uvedených vzorů, ale zároveň se jim i vymyká. Což není nic divného - moje platforma není messagingová, JMS fronty používá pouze jako rozhraní kvůli decouplingu.

Co si o tom myslíte vy? Jak byste nazvali takovou "odkládací" frontu? Nebo existuje nějaký vzor, který toto řešení/problém pokrývá lépe? Budu rád, když se v diskuzi podělíte.