Jestliže potřebujete stejně jako já synchronizovat obsah různých adresářů mezi PDA a počítačem, tak určitě používáte nějaké vlastní utilitky, protože ActiveSync je omezen na jeden pevně určený výchozí adresář. Dají se sice upravit registry a přesvědčit tím ActiveSync, že má soubory hledat jinde, ale podpory více složek stejně nijak nedosáhnete.

MobSync je prográmek, který tuto nedokonalost řeší. Stáhnout si jej můžete z jeho domovské stránky, pouze se nelekněte japonských znaků.:)

Uživatelské rozhraní MobSyncu zdařile imituje styl spráce s ActiveSyncem, takže ovládání je pro každého intuitivní.

Aby došlo k synchronizaci adresářů, musíte vytvořit tzv. joby, kterých může být libovolný počet. Při zakládání nového jobu zadáte jen jeho název, cestu ke složce na PC, cestu ke složce na PDA a vyberete si typ synchronizace (obosusměrná, jednosměrná -PDA, jednosměrná -PC). Dále můžete určit masky souborů, které nemají být do synchronizace zahrnuty a zvolíte, zda si přejete synchronizovat soubory automaticky při každém spojení s PDA, nebo manuálně po požadavku uživatele.

MobSync je stabilní a kvalitní software i v aktuální verzi 0.9 a doporučuji jej každému majiteli PDA alespoň vyzkoušet.

Dokážete najít dva ekvivalentní zápisy zámku (lock) v metodě AtomicOperation?

    class  AtomicTest
    {
        private int x = 0;
        private int y = 0;
        public void AtomicOperation(int arg)
        {
            lock(this)
            {
                x += arg;
                y += arg;
            }
        }
    }

Roman Pichlík svým nevinným povzdechnutím nad JAVA komunitou a srovnáním podpory Microsoftu a SUNu spustil diskuzi nad .Net komunitou, přidal se i Slavo, a celé to vyústilo v půvabné hledání nejzasloužilejšího iniciátora a šikovatele .Net komunity. Asi se budou udělovat medaile nebo jiné lukrativní benefity, protože jinak by se tomu určitě všichni zainteresovaní nevěnovali s takovým zaujetím. Mám pro všechny dobrou zprávu, protože znám jasného vítěze - medaile budou muset být expresně poslány vývojovému týmu Microsoftu odpovědnému za .Net Framework, protože by jinak MS komunita postrádala předmět, kolem kterého se nyní tak ráda "seskupuje", a s tichou závistí by jen mohla pozorovat, jak jim ze stále vzdálenějších a lepších SW zítřků spokojeně kynou JAVA programátoři, kteří jsou šťastní, že jejich technologie nemá žádnou konkurenci a prosazuje se navzdory vlastnímu pomalému technologickému vyspívání, liknavosti a neskutečné marketingové neschopnosti SUNu.;) .

Původně jsem na spot o .NET komunitě ani nechtěl reagovat, ale při přečtení si svého jména ve spotu Michala, se s ohlušující intenzitou rozezněly moje interní kontrolní mechanismy citlivé na každý kolektivní patos a identifikaci s nějakou skupinou.

Necítím se být exponentem žádné skupiny a dá snad Bůh, že jím nikdy nebudu. V tomto konkrétním případě hlavně nevím, co si mám pod .NET komunitou představit. Čechy jsou tak malé, že mi označení komunita nepřijde moc přiléhavé, protože na konferencích, blogu nebo v diskuzích pod články potkávám většinou stále stejnou skupinku lidí a i když vím, že pasivně se účastní všech aktivit (zní vám to také tak protismyslně?) mnohem více lidí, zdráhal bych se na ně alespoň prozatím použít slovo komunita. Pro mě jde o skupinku lidí se zájmem, ať už profesionálním (většinou) nebo nadšeneckým o .Net, ale těžko z toho vyvozovat, že jde o lidi, kteří by k sobě měli blízko, sdíleli názory, protože tohle vše mi evokuje pojem komunita a myslím, že zakládat lidské vztahy na něčem tak banálním jako je technologie snad ani nemá cenu. Řekněme, že spíše než komunitu připomínáme zájmový spolek jako jsou filatelisté nebo spolek přátel žehu:)

V čem bych viděl opravdový smysl takového spolku? Ve vytvoření takové atmosféry, kdy by si blog nebo jinou vlastní tribunu založili další zajímaví, ale zatím skoro neviditelní lidé (zvykem je nejmenovat, ale snad se nebudou zlobit - namátkou Zbyšek Hlinka, Petr Zahradník, Milan Múčka).

Ještě k tomu rozporu na Michalově blogu. Pro mě je zřejmé, že Javistům chybí nějaký nový "Michal Bláha", který by tvrdohlavě šel za svým cílem a nezištně by nabídl hostování blogu a dalších aktivit všem, kteří projeví zájem. Od minulého roku (a možná i dříve) je patrný silný zájem českého Microsoftu na zlepšení přímé komunikace s vývojáři a díky lidem jako je Honza Šeda (teď mě napadá, proč ty Honzo nemáš ještě blog? ;)), Michael Juřek, Jirka Burian a mnoho dalších se to opravdu daří. Já samozřejmě nevím, jestli třeba Michael Juřek nebo Petr Lazecký blogují proto, že Microsoft ústy Billa Gatese začal považovat blogy za účinný nástroj zakořeňování povědomí o svých produktech, nebo jde čistě o jejich soukromou iniciativu, ať tak či onak, tyto motivace jsou mi zcela volné - důležité je, že tyto blogy existují a že si na nich každý může vybrat články podle svého naturelu. Takže v činnosti Michala Bláhy a v působení Microsoftu je znát stejný zájem - poskytnout prostor vývojářům a hledat, kdo učinil víc, je asi nesmyslné a neplodné. Oba póĺy jsou komplementární a podmiňují se navzájem - nadšení jednotlivců v Microsoftu a mimo Microsoft i finanční, marketingová a manažerská záštita Microsoftu.

Líbí se mi, že tuhle diskuzi otevřel spot Romana Pichlíka - kovaného Javisty.;) Od prvního spotu svého blogu jsem byl proti budování ghet a ohrádek malých omezených prasátek-vyznavačů jediné správné technologie. Už jsem naznačoval výše, že nemám rád žádné kolektivní akce, proklamace a závazky. Myslel jsem tím také to, že občas se u některých lidí vynoří pochybnosti, zda se může MVP vůbec snažit psát objektivně a jestli již není tak svázán s Microsoftem, že mu jeho mozek před každý názor nejdříve vygeneruje stylové logo Windows, které působí jako autokastrační filtr nepatřičných myšlenek. Mám k MVP ocenění asi trochu jiný vztah než třeba Slavo. Slavo několikrát psal (promiň Slavo, jestli to nebude úplně přesné, ale přesný citát jsem na tvém blogu nedohledal), že chce působit v konferencích, protože chce být "valuable" a dostát tak titulu. Můj názor je, že MVP titul je udělován za činnost v předchozím roce a svého nositele k ničemu nezavazuje - pro mě je tento pocit důležitý, protože nezávislosti v konání, chtění a sebeprezentování, a to i tehdy když by mělo jít jen o iluzi nezávislosti ;), se nikdy nevzdám, protože jen těžko bych mohl žít s pocitem, že se ode mě něco vyžaduje a že nemám na výběr. Když mě přestane bavit psaní do konferencí nebo psaní do blogu, nebudu se nikoho ptát, co smím nebo nesmím, a proto ani nikdy nechci být s žádnou skupinou nerozlučně spojován jako její ikona. Jsem závislý jen na svých individuálních rozmarech, (pravda, teď i na rozmarech své dcerky:) ), a ne na rozmarech žádné, byť sebelepší komunity. A doufám, že je tomu tak u každého z vás. :)

P.S: Případné a v poslední době oblíbené tipy na velikost mého ega od vyznavačů anonymního bezbřehého kolektivismu jsou vítány.:)

UPDATE: Aby nedošlo k dezinterpretaci spotu. V poslední části jsem chtěl říct, že bez ohledu na různé postoje ke komunitě, jsou všichni MVP ve svých názorech na Microsoft ponecháni napospas jen sami sobě.

Tento spot přímo navazuje na starší spot o nejčastějších problémech v .NET Remotingu.

Dotazy v konferencích se často týkají událostí. Důvodem je hlavně to, že mnoho knih (namátkou třeba Building XML Web Services for Microsoft .Net platform) obsahuje “postup” pro rozchození události, který nefunguje. V čem je problém?

Když ve vzdáleném serverovém objektu nadeklarujete událost a pokusíte se k ní zaregistrovat delegáta ukazujícího na metodu na klientovi, dostanete při běhu aplikace výjimku, že se nepodařilo nahrát assembly s typem, ve kterém se nachází klientská obslužná metoda události. Server odmítne registraci delegáta u události, protože nedokáže ověřit signaturu metodu, na níž odkazuje delegát - server nemůže nalézt assembly s typem, ve kterém je deklarována metoda, protože assembly je známa a rozmístěna jen na klientovi.

Správný postup při deklaraci a používání událostí v .NET Remotingu

1. Vytvořte jednu assembly se serverovým objektem a nadeklarujte serverové události. Assembly umístěte pouze na serveru.
2. Vytvořte assembly, v níž bude sdílená třída s obslužnou metodou serverové události a dále bude třída obsahovat událost vlastní, která bude stejného typu jako serverová. V těle obslužné metody serverové události pouze vyvolejte událost vlastní - lokální a přepošlete argumenty obdržené ze serveru. Assembly umístěte na server i na klienta, protože klient si zaregistruje obslužnou metodu sdíleného typu k serverové události (v té chvíli již server dokáže ověřit signaturu metodu a nahrát typ, ve kterém je metoda deklarována) a současně si klient přihlásí odběr lokální události ze sdíleného typu a takto zprostředkovaně zpracuje událost ze serveru.
3. Vytvořte klientskou assembly. Assembly umístěte pouze na klienta.

Dalším problémem u vzdálených událostí je korektní ošetření stavu, kdy se klient odpojí a na serveru zůstane zaregistrován delegát (například spadne spojení). Aby nedošlo k výjimce na serveru při pokusu distribuovat událost, tak jako nejjednodušší cesta se nabízí dekorování obslužné metody na klientovi atributem OneWay - atribut způsobí, že server ignoruje všechny návratové hodnoty a výjimky z metody. Velkou nevýhodou je ale hromadění delegátů ukazujících do "prázdna" a tím zvýšená režie na distribuci každé události. Lepším řešením je ruční vyvolání každého delegáta registrovaného k události a po odchycení výjimky vyřazení delegáta z další distribuce událostí.

public void OnServerEvent(EventArgs e)
{
    Delegate[] delegatesList = ServerEvent.GetInvocationList();
    foreach(ServerEventHandler clientDelegate in delegatesList)
    {
        try
        {
            clientDelegate(e);
        }
        catch
        {
            ServerEvent -= clientDelegate;
        }
    }
}

Pár námětů na zamyšlení pro produktové manažery v Microsoftu ohledně rozšiřování BizTalku 2004 a "evangelizaci" jeho schopností a hranic. Jedná se o moje zkušenosti z prezentace možností BizTalku u jednoho klienta a dále z obecné konzultace o integraci aplikací přes XML. Posluchači byli z vyššího IT managementu. Konzultace většinou žádné nedělám, ale o projekt na BizTalku bych měl velký zájem, takže jsem udělal výjimku.;)

Výsledky jsou ale z mého pohledu tristní.

1. Největší zájem o BizTalk mají pobočky zahraničních firem, které chtějí integrovat nebo nahradit kvanta pidi aplikací na Lotus Notes.
2. Někteří zákaznící si myslí, že BizTalk=XML a XML vyléčí během jednoho dne všechny potíže při výměně dat s partnery. Bez námahy, programování atd.
3. Jiní zákaznící považují BizTalk za CASE nástroj pro návrh procesů, protože obsahuje Orchestration Designer!
4. BizTalk je v mysli mnohých také spjat s řízením projektů. Možná by mohl Microsoft zapracovat na posílení povědomí o svých serverových produktech a prodal by minimálně pár licencí na MS Project Server.
5. Také zaznělo, že BizTalk je nástroj pro vytváření OLAP kostek. Sice v něm tuto funkčnost naleznete, ale asi nikdo si nebude BizTalk kupovat jen kvůli OLAPu.

Konzultace se většinou nesly v duchu seznamování se základními principy SOA, webových služeb, "enterprise" integrace aplikací a většinu přítomných to evidentně zaujalo, hlavně když zjistili, že, jak již předtím instinktivně tušili, SOA a a potažmo BizTalk jim pomůže vyřešit jejich problémy s integrací mnoha a nejen Lotus Notes aplikací.

Pro mě je zřejmé, že potenciál k rozšiřování BizTalku v Čechách je, jen Microsoft zatím nedostatečně u zákazníků zmiňuje všechny přednosti a hlavní rysy BizTalku. A myslím, že si to tak skvělý produkt jako je BizTalk opravdu nezaslouží:(

Bonviván nové zkomercionalizované éry - milovník dobrého jídla, pití, drahých aut a pěkných holek. Vývojařinu si vybral, protože sní o zbohatnutí na jednom veleúspěšném projektu, které mu umožní konečně vést opulentní život rentiéra naplněný rozkošemi, z nichž tou nejlepší je soukromý a 24 hodin přístupný harém plný luxusních a roztoužených děvek. V mládí sbíral zkušenosti v zahraničí. Od té doby přesně ví, jak musí vývoj vypadat a v každé fiirmě své názory s mondénní a neodolatelnou gestikulací prosazuje. Vždyť je světák, žádná provinční krysa, a tak mu jeho názory všichni baští. Je freeelancer za všech okolností, zaměstnanecký poměr neuznává, protože v podvědomí mu zastydl starý dobrý twisťácký slogan "Nevaž se odvaž se". Zásadně dává nerealistické odhady své výkonnosti, takže ze 14 dnů práce sjednané se časoprostorovou trhlinou stává měsíc a půl práce fakturované. Ochomýtá se rád okolo návrhu aplikací, ale jeho nápady musejí být cenzurovány, protože ten lehkomyslný a přelétavý duch neriskuje nouzové přistání v nudné realitě, takže v praxi aplikaci pro současně přihlášených 1000 uživatelů nonšalantně dimenzuje na dva. Vyznačuje se rozvinutým pátým smyslem - schopností zvolit při návrhu vždy to nejméně dobré řešení, takže jeho kolegové žijí v nejhorším ze všech možných softwarových světů.

Jeho život neodvolatelně nabírá komediálně baladický ráz - místo dobrého jídla a pití mu roste panděro z přepálených jídel v nevalných hospodách, místo pěkných holek si ho vytipují třetiřadé odkvétající kurvičky a místo tuningu drahých aut tuní barvičky uživatelských rozhraní, v nichž se lesknou zbytky jeho estetického citu orientovaného od mládí na orientální krásu.

Arivista - povýšenec v IT oblasti, jehož vykulené oči a těkavé pohledy svědčí o tom, že by se lépe cítil při obdělávání domácího úhoru s bramborami než při programování. Je nesmělý a bázlivý, takže k jeho nástupu dojde spíše za nějaké šťastné konstelace hvězd, například když se za něj přimluví kolega, než že by se o něj přetahovali lovci mozků. Je ambiciózní, ale chybí mu talent, který vyvažuje svou přizpůsobivostí, takže si ve firmě nalezne své teplé místečko, ve kterém píše stále dokola ten samý kód. Nadřízení jej mají rádi, protože v něm je něco z lokajského charakteru, který ví, že vrchnost nebo její novodobý dědic má vždy pravdu. Pamatuje si, odkud přišel a že je profesionálním vývojářem spíše náhodou, takže jeho hlas se ozve vždy jen na obranu průměrné a šedé masy a líbí se mu vše, z čeho se vám zvedá žaludek - je to takový typický natěšený divák silvestrovských orgií na Nově a obdivovatel "originálního humoru" Petra Novotného. Skoro vždy stojí na straně většiny, aby nebyl nucen obhajovat svůj postoj nebo nést odpovědnost. Rozplizlé maso bez názoru. Proto jsou jeho zaklínadly praktičnost a jednoduchost, takže návrhy složitých aplikací nikdy dopodrobna nepochopí a ani nemůžete čekat, že sám přijde s nějakým nápadem. Je jen spokojeným kolečkem v hodinovém strojku, jímž je SW firma, a to kolečkem, které permanentně variuje z kolegů vycucané znalosti. Ač totiž není Sokratem promenádujícím se po tržišti, tak se neustále snaží, jak věčně hladová předzvěst kobylek z Apokalypsy, vyluxovat znalosti od svých kolegů. V období periodického návalu jeho ctižádosti a pod ochrannými křídly svého nadřízeného se snaží rýt i do vaší práce, aby se přiživil na vašem talentu, ale jeho argumenty jsou tak ploché a bez vazby na probíranou věc, že všem připomene jen legendární opožděnou postavu jménem Mlha z filmu Marečku, podejte mi pero. Na rozdíl od Bonvivána jde ale o spokojeného člověka, který je rád, "že to někam dotáhl".

Čerstvý absolvent ČVUT nebo MatFyzu - vzdělaný člověk, který se sice na úvodní pohovor dostaví s dvouhodinovým zpožděním, protože pro něj čas není rozhodující veličinou, ale z každého jeho gesta cítíte, že za ním stojí perfektně naprogramovaný stavový automat a že jeho nositel je sám prvním hybatelem a demiurgem svého chladně dokonalého racionálního světa. Je inteligentní a programování komerčních aplikací by zvládl jednou setinou výkonu svého velkokapacitního mozku. Bohužel, když mu objasníte, že pod komerční aplikací si nepředstavujete dva roky psanou prognózu úbytku ozonové vrstvy v dalších 20 letech, protože o ni pro něj velmi překvapivě nejeví žádný náš zákazník zájem a není tedy ochoten její vývoj sponzorovat, odejde do vědeckého ústavu, kde se může lépe realizovat.

1. I v PDa zařízeních s nainstalovaným compact .Net Frameworkem můžeme umísťit podepsané (strong name) assembly umístit do globálního úložiště (Global Assembly Cache - GAC). DO GAC by měly být umísťovány assembly, které používá více CF aplikací a které tedy není vhodné pokaždé instalovat v samostatné kopii. Postup umístění assembly do GAC se podstatně liší od umístění assembly do GAC na desktopu.
   1. Nakopírujte podepsanou assembly do jakéhokoli adresáře na PDA (například \Program Files\SharedDll\MyAssembly.dll)
   2. Vytvořte soubor s příponou gac, do kterého vložíte cestu k assembly (soubor se jmenuje MyDll.gac a obsahuje řádek \Program Files\SharedDll\MyAssembly.dll). V jednom souboru může být libovolné množství registrovaných dll a na jméně souboru nezáleží.
   3. Soubor s příponou gac umístěte do adresáře Windows.
   
   
2. Při vývoji aplikace pod compact .Net Frameworkem nám chybí základní statistiky o běhu aplikace, respektive o výkonnosti běhového prostředí. Alespoň základní výkonnostní ukazatele (Performance Counters) zjistíme po přidání klíče HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFramework\PerfMonitor do registrů. Pod nově vytvořený klíčem přidáme novou položku typu DWORD, nazveme ji Counters a její hodnotou bude číslo 1.
   Pak můžete spustit jednu CF aplikaci, simulovat běžnou práci uživatele a po ukončení aplikace analyzovat nově vygenerovaný soubor mscoree.stat v kořenovém adresáři PDA.

Dokážete poznat všechny nesmysly v tomto kódu? Nejde o žádný reálný příklad, jen o letmé zachycení a nakupení střípků potměšilých nočních programátorských můr, jimiž je moje podvědomí neodbytně zaplavováno a mučeno po duševně drásající  refaktorizaci cizího kódu...;)

using System;
using System.Collections;
namespace DirtyProject.BusinessModel
{
    public class Order
    {
        private int m_id;
        private ArrayList m_orderItems;
        public Order(int id)
        {
            m_id = id;
            LoadOrSave(false);
            m_orderItems = new ArrayList();
        }
        public virtual void DeleteAndNotifyCustomer()
        {
            //Implementace
        }
        public virtual void LoadOrSave(bool save)
        {
            //implementace perzistence
        }
        //Položky objednávky
        public ArrayList OrderItems
        {
            get
            {
                return m_orderItems;
            }
        }
    }

    public class OrderItem
    {
        private Order m_order;
        private int m_orderItemsCount;
        private decimal m_orderItemsPrice;
       
        public OrderItem(Order parent)
        {
            if (parent == null)
                throw new ArgumentNullException();
           
            m_order = parent;
            m_orderItemsCount = 0;
            m_orderItemsPrice = 0;
        }
        public Order Parent
        {
            get
            {
                return m_order;               
            }
            set
            {
                m_order = value;   
            }
        }
        //Počet kusů zboží v objednávce
        public virtual int OrderItemsCount
        {
            get
            {
                return m_orderItemsCount;
            }
            set
            {
                m_orderItemsCount = value;;
            }
        }
        //Celková cena všech kusů zboží v položce objednávce
        public virtual decimal OrderItemsPrice
        {
            get
            {
                return m_orderItemsPrice;
            }
            set
            {
                m_orderItemsPrice = value;
            }
        }
        public virtual void LoadOrSave(bool save)
        {
            //implementace perzistence
        }
    }
}

Pavel Koza, člověk, který se zasloužil o popularizaci PDA zařízení s operačním systémem Windows Mobile na svém kultovním serveru CEYOU ještě v době, kdy většina z nás tato zařízení považovala jen za předražené hračky, se stal MVP v oblasti Mobile Devices. Víte sami, že příliš často nechválím, ale Pavel Koza byl pro mě bez jakýchkoli pochybností jediným kandidátem v Čechách splňujícím bez kompromisů všechny nároky MVP programu.

Gratuluju Pavle a díky za všechnu práci, kterou ve svém volném čase na CEYOU pro všechny PDA nadšence odvádíš.

Je vzrušující pozorovat, jak na svém počátku amorfní a abstraktní vzor nabývá svébytného a ostře ohraničeného tvaru pri svém dospívání, když je adoptován různými technologiemi. Zasazením vzoru do jednoho vývojového prostředí a kontextu se může zdát, že je na univerzálnost svého použití aspirující smysl vzoru zastřen a překryt dominantním zaměřením a převládajícími výrazovými prostředky jedné technologie. Každý dobrý návrhový vzor se ale svojí konkretizací v jedné nebo i více technologiích nevyčerpává, ale je připraven vymanit se ze sevření každé technologie a při změně IT paradigmatu znovu nabídnout svoji plnou formativní potenci pro nové postupy, pravidla a vazby ve vývoji. Když se mění technologie, programovací jazyky nebo celé zažité programátorské návyky (strukturální versus objektové programování), tak esence kvalitního návrhového vzoru není dotčena a jeho abstraktní smysl začne být jen artikulován výrazovými prostředky žezlo přebírajícího paradigmatu a z něj vyplývajícího znalostního a pojmového horizontu. Dobrý návrhový vzor participuje na tvorbě struktur nového paradigmatu a současně je nově vznikajícími strukturami přetavován ve svou jinou, parciální a dočasnou formu.

Když nechcete, aby vaše znalosti beznadějně zastaraly za pár měsíců, nebazírujte na zvládnutí programovacích jazyků, vývojových prostředí nebo frameworků, ale stavte své znalosti na návrhových vzorech. .Net Framework nebo J2EE jsem se naučil tak, že jsem se za jednotlivými knihovnami nesnažil vidět deprimující změť tříd a metod, ale harmonii návrhových vzorů.

Jak se projevují migrace a proměny vzorů?

Vezměme si za příklad vzor Asynchronous Completion Token (ACT) popsaný v knize Patterns Oriented Software Architecture (autor Frank Buschmann a kolektiv). Tento vzor popisuje, jak dosáhneme efektivního a na zdroje počítače nenáročného zpracování odpovědí z více asynchronních požadavků. ACT je objekt (v obecném slova smyslu), který unikátně identifikuje každý asynchronní požadavek a slouží k výběru správného zpracovatele odpovědí. Participanti vzory jsou tři - iniciátor asynchronního požadavku, služba, která je volána a ACT pro korelaci požadavků a odpovědí.

V .NET je ACT vzor transformován do speciálního vzoru pro asynchronní volání, kdy je zavedena formální konvence, že asynchronní metody jsou prefixovány slovy Begin (začátek požadavku) a End (Konec požadavku), Každý delegát nabízí metody Begin a End, jejichž posledním parametrem je zase dle konvence jakýkoli objekt, který pak v systému hraje roli ACT. ACT neslouží ale k výběru primárního zpracovatele asynchronní odpovědi, protože ten je na začátku asynchronního volání determinován předposledním parametrem, jímž je delegát AsyncCallBack ukazující na metodu s kompatibilní signaturou. Předaný ACT ale může být klíčem k dynamickému určení sekundárního zpracovatele a/nebo je objektem pro přenos stavových informací.

.Net si tedy ACT vzor přizpůsobil k obrazu svému a vybral si jen některé jeho myšlenky.

ACT se také uplatňuje v SOA - v architektuře založené na službách, které si mezi sebou asynchronně vyměňují tisíce zpráv denně, potřebujeme prostředek pro korelaci zpráv-požadavků a návazných zpráv-odpovědí. V SOA je uplatňován návrhový vzor s názvem Correlation Identifier - v hlavičce zprávy je uložen jednoznačný identifikátor požadavku, který je v hlavičce odpovědi zaslán zpět odesílateli. Jsme v SOA a stále pracujeme se starým dobrým ACT vzorem, jen místo delegátů mluvíme o zprávách, dokumentech a hlavičkách s ACT informací.

Vzor Correlation identifier (a ACT) je dále rozpracováván ve specifikacích pro jednotlivé technologie. Když budeme mít SOA založenou na webových službách, setkáme se s normovaným ACT ve standardu ws:addressing, kde je stanovena a přijata konvence, že ACT musí odesílatel poslat v hlavičce nazvané MessageId a kdy je vyžadováno, aby hlavičku uvedl, a odesílatel je povinen hodnotu z MessageId poslat v hlavičce odpovědi s názvem RelatesTo.

Až skončí éra SOA, webových služeb, .Net Frameworku a přijde jiná, úžasnější, oslnivější a zase skoro dokonalá technologie, na které se bude hlavně dobře vydělávat,;) nepřežijí dílčí implementace ACT v těchto prostředích, ale můžeme si být skoro jisti, že vzor ACT jako bájný Fénix vstane omlazený z popela, změní svůj vnější vzhled, aby byl "in", ale jeho podstata zůstane beze změny, dokud budou existovat asynchronní volání.