WWF + WCF = BLL
2007-08-17T12:07:33+02:00
2007-09-02T01:43:50+02:00
2022-07-19T05:17:57+02:00
  • WCF kapcsán az MSDN nagyon lelkesen mesél az SvcTraceViewer-ről és a perfmon-ról. Elöbbi SDK, utóbbi ugye vindóztartozék - ám szinte egyikről sem találtam érdemi wcfes infót a neten.

    Használta ezeket valamelyikőtök? Any experience?
    Mutasd a teljes hozzászólást!
  • akkor jól gondoltam, merthogy eddig én is úgy tudtam, hogy ilyesmit a WF nem fog tudni, a feladat korrekt megoldása - a message boxing - majd a biztalk-ban lesz implementálva (aminek az új verziója meg különben wf alapú lesz...)
    Mutasd a teljes hozzászólást!
  • Aha, értem, mit mondasz. Mivel a WF engine Workflow Instance ID-k alapján dolgozik, ezért az effajta terheléselosztás ebben a verzióban nem implementált, bár nem kivitelezhetetlen. Pl. én úgy dolgozom (majd), hogy minden olyan feladatkör, ami több esetben, több projekthez is fog kelleni, külön szervízt kap, külön WF folyamatokkal. Így a tehelés elosztás is meg van oldava (biznonyos szinten), és az egész teljesen transzparens, a korrekt WCF + WF integráció miatt. Ebben az esetben a Data Contract-ek úgyis domain szintűek (erre az EF nyújt majd közvelen támogatást), szóval tud működni ez a koncepció.

    Apropó, domain level! A 3.5-ös WPF támogatja az add-in-ezést. Ez arra jó, hogy egy absztarkt Application-t implementálva a WPF képes a szerverről add-ineket lehúzni (plug-in DLL), és azt külön AppDomain alatt futtatni, automatikus (transzparens) WCF kommunikációval (HWND alapú). A verziókövetést is megoldották. Ez azt jelenti, hogy a kliensen mindig naprakészen tarthatók például a Data Contract-ek, és a hozzájuk tartozó Data Template-k. Nagyon-nagyon power!
    Mutasd a teljes hozzászólást!
  • a több node-s működést nem így kell érteni, hanem hogy mi van, ha a szervered több gépen fut valami terheléselosztásos rendszerben, és

    - alszik a workflow
    - bejön egy üzenet (node1), itt felébred (táblába bejegyzés kerül: node1-en él a wf példány)
    - a kliens lövi a következő üzenetet, de az a terheléselosztás miatt node2-re érkezik
    - node2 megpróbálja feléleszteni a wf-t, de az node1-en már él. emiatt mondjuk hibát jelez
    - a kliens azt látja, hogy elküldött egy normális üzenetet és időnként hibát kap, máskor meg feldolgozódik


    erre lesz megoldás benne? (a transzport szintű node affinity nem tetszik, mert akkor nem a wf oldja meg a problémát)
    Mutasd a teljes hozzászólást!
  • - nincs semmi támogatás a több node-os működésre


    3.5 alatt úgy kell elképzelni az egészet, hogy OperationContract-eken alapuló események érik a munkafolyamatokat. A kontextust teljes mértékben a szerveroldal kezeli. Ezek az események a WF szempontjából teljesen mindegy, hogy házon belülről, vagy házon kívülről jönnek, magyarul lehet ugrálni az egészben, mint a vizibolha, és teljesen transzparens, hogy honnan jön az esemény. Magyarul az ExternalDataExchange-dzsel való kínlódást nyugodtan el lehet felejteni. A munkafolyamatok is egy-egy WCF kontextus köré épülnek, ezeket a rendszer irányítja, nem kér enni. Duplex kommunikációval valósították meg. Egyszerű hívás/eseménykezelés a kliensen.

    - iis-ben hostolva kölcsönösen kinyírják egymást az aspnet thread poollal


    Erre sincs szükség. Az ASP.NET felület külön processz, külön hostolt alkalmazás. IIS 7 alatt a sebességgel sincs gond, házon belül nyugodtan mehet a pipe vagy a TCP/IP. Semmivel sem összetetteb a WCF + WF layerrel való kommunikáció és ennek kivitelezése, mint ha egy inprocess réteggel kommunikálnál. Metódusokat hívogatsz, eseményeket kezelsz.

    - a jelenleg elérhető verzióban a task perzisztencia állítólag nem kifejezetten kiforrott, majd az orcasos állítólag jobb lesz


    Erről nem beszéltek az okosok.

    - úgy általában, azt mondják a Bölcsek és a Nagyok, hogy ezt kliensoldali workflow-nak találták ki, tehát szerveroldalon csak fenntartásokkal használható egyelőre, megintcsak majd az orcas-os verzió jobb lesz


    Nem jobb lett. Egyszerűen csak befejezték, amit elkezdtek. Sürgősen ki kellett adni valami sz'rt a Vista-val, de az csak egy demo volt a végleges változathoz képest.

    Ugyan ez igaz például a WPF-re is. Egyszerűen a 3.5-ösben kezdett el muzsikálni minden úgy, ahogy annak működnie kell(ett volna). Pl.: teljesen ugyan az a 3D-s vezérlőstruktúra, mint a 2D. Ugyan abba a vizuális fába teheted a 3D és a 2D elemeket, a 2D textúraként jelenik meg, de teljesen interaktívan működik. Még ezer dolog van ott is.

    3.0 => 3.5 LOC ~70%! Sok dolgot átírtak, sok dolgot hozzátettek, a 3.0-s demoverziót el kell felejteni.
    Mutasd a teljes hozzászólást!
  • TechReady akart ez lenni.
    Mutasd a teljes hozzászólást!
  • Hozzám került a Teachready .NET 3.5-ös anyaga. Még csak egy órát néztem meg a WF + WCF-es prezentációkból, de már nem találom az állam, úgy leesett.

    WF + WCF = BLL?

    A .NET 3.5-ben igen. Nagyon-nagyon kemény. Ha végignéztem, megpróbálok valamit közzétenni a rengeteg információból a blogomba, mert sajnos a neten nincs még ennyire összeszedett anyag, ami alapján el lehetne indulni.
    Mutasd a teljes hozzászólást!
  • Egyébként: Workflow Foundation v2 RULEZ! Így, hogy megkapta maga alá a WCF-et, javítottak és hozzátettek pár dolgot, én azt mondom, hogy el lehet kezdeni komolyabban alkalmazni a rendszert.
    Mutasd a teljes hozzászólást!
  • Az az érdekes, hogy mind az EF, mind a LtS teljesen ugyan azzal a hibával, tök ugyanott omlik össze. Állítólag teljesen külön zajlik a fejlesztés, de ezek szerint csak van közös kódalap.
    Mutasd a teljes hozzászólást!
  • Nos, a tovabbi tesztekhez ezt a workaroundot hasznaltam en is, azzal a kulonbseggel, h szamomra nem megfelelo a NEWSEQUENTIALID() es a UuidCreateSequential()
    Mutasd a teljes hozzászólást!
  • Ó, hát ez még az EF-ben is elszáll. Azóta sem javították ki, pedig én már a March CTP-nél is szóltam érte. Sőt, ha GUID a tábla azonosítója, akkor az SQL 2005-nél illik NEWSEQUENTIALID()-del generáltatni, hogy az index ne daráljon a random számok miatt. Ezzel csak annyi a probléma, hogy a Management Studio minden olyan tábla mentésénél hibát jelez, aminek ez a default ID. Elmenti, csak zavaró. A workaround egyszerű, bár kissé körülményes. Az ID-et nem az SQL szerveren kell generáltatni, hanem szépen kódból kell létrehozni. Na, nem a random Guid.NewGuid() metódussal, hanem a UuidCreateSequential() Win32-es függvénnyel.
    Mutasd a teljes hozzászólást!
  • DAL: LINQ to SQL...


    a beta 2-ben ha a SQL tablaban uniqueidentifier az azonositod, lemodhatsz a LINQ to SQL -rol, mert hibas pl az insert, update
    a keszitok azt felteteleztek, hogy a kulcs int identity
    igyhat jon egy szep kis kivetel, hogy nem tudja decimalra konvertalni az uniqueidentifier-t

    ez ugy az elso percben jott ki amikor a beta 2-t nezegettem

    forumon talaltam megerositest a hibara, majd javitjak
    Mutasd a teljes hozzászólást!
  • Természetesen értem, hogy egy nagyvállalati környezethez fejlesztett szoftver más kategória, mint egy kisebb, bár többrétegű alkalmazás fejlesztése. Épp egy ilyenen dolgozom. A szerver saját, már fennt figyel a .NET 3.5 beta 2, a menedzsment alkalmazás deploy moduljában pedig ott fog figyelni az addigra kész .NET 3.5 install. Ilyen esetben könnyű belerajzolni a szerződésbe, hogy a követelmény minimum XP SP2.

    Egyelőre a designterveknél tart a projekt, de minden részhez készítettem proof of concept modulokat (erre ment el az első 1-2 hónap).

    A következőképpen fogjuk megoldani:

    - DAL: LINQ to SQL, külön libben, ahol a DAL közeli kód is szerepel.

    - BLL: WCF Workfolw Enabled Service, IIS host. A 3.5-ös verzió nagyon kellemes újításokkal jött ki. A Workflow részek csak kisegítő elemei a logikának, nem minden működés lesz így implementálva (simi.2 módszer).

    - Web: ASP.NET 2.0 AJAX + "Futures", Silverlight 1.0 videókkal és bannerekkel (ez utóbbi kínszenvedés egyelőre).

    - Management: WPF (csak, hogy élvezzem is, a deploy ez esetben nem gond). Még nem döntöttem el, hogy felhasználom-e a legújabb Acropolis-t. Jónak tűnik, de át kell néznem, hogy van-e annyira "feature complete" a jelenlegi CTP, hogy neki lehessen állni vele dolgozni. Attól is függ, mikorra lesz kész, mert a projekt átadásakor nem akarok CTP-t vagy bétát használni.

    Az az igazság, hogy ez elég nyúlfarknyi kis dolog ahhoz, hogy ekkora hátteret rajzoljak neki. Bőven elég lenne ide egy egyszerű .NET 2.0-s háttér. De, mivel szabadkezet kaptam, úgy döntöttem, hogy jó alkalom ez arra, hogy kipróbáljam, mit tud a kicsike. Ha jól okoskodtam, ennek megvalósítása sem vesz el több időd, mint a DataSet-es, kliensbe logikát bogozó megoldás. A blogomba majd beleírom a tapasztalatokat, úgyis nagy ott a pangás egy ideje (vártam a fícswörkomplít Orcas-t, na).
    Mutasd a teljes hozzászólást!
  • Kezdem érteni miről beszélsz...
    Mutasd a teljes hozzászólást!
  • WSSF-hez annyi, hogy az adatelérő réteg elég ratyi, ezért vagy érdemes húzni fölé egy réteget és kicsit buherálni a wizardokat (de ez kézimunka), vagy korábban szivesen használt megoldásra lecserélni.


    oOOoo, egyetertek
    Mutasd a teljes hozzászólást!
  • WSSF-hez annyi, hogy az adatelérő réteg elég ratyi, ezért vagy érdemes húzni fölé egy réteget és kicsit buherálni a wizardokat (de ez kézimunka), vagy korábban szivesen használt megoldásra lecserélni.
    Mutasd a teljes hozzászólást!
  • Köszönöm a válaszaitokat!

    Úgy döntöttem az itt és máshol olvasottak alapján hogy a Workflow csak óvatosan kerül alkalmazásra, viszont a WCF valóban nagyon jól használható.
    Eddig nem szenteltem kellő figyelmet a Software Factory-nek, pótoltam, valóban ütős párosnak tünik a SCSF+WSSF, pláne hogy létezik Mobile Client Software Factory.

    Azokat a technológiákat amik még béta formájában állnak rendelkezésre (amikrő chikk is írt) nagy figyelemmel kísérem, de éles alkalmazásra még nem kerülnek.

    Zs.
    Mutasd a teljes hozzászólást!
  • Mint írtam főleg operációs rendszer (vagy service pack) váltás különöseben problémás ahogy láttam, de nem csípik a plusz telepítéseket sem.

    Az ok igen egyszerű: ha bármi baj lesz a gépekkel a telepítés után/miatt/alatt, azt nekik kell kiganézni. Persze tesztgép, meg lokalizáció ellenőrzés, meg bevizsgálás, meg hatásvizsgálat van (ez önmagában is sok idő, vö. levelezés indus kollegákkal) és senki nem akar magának plusz munkát vagy cseszegetést. Merthogy erre százas nagyságrendű gépparkoknál jó esély van ugyebár.
    Mutasd a teljes hozzászólást!
  • Egy 3.5 Fx Setup XP-re pár perc, ezért nem értem, mi a gondjuk ezzel. Kva sok pénz meg lehet spórolni a fejlesztéseken, elég, ha csak a LINQ to SQL-t veszed az ADO.NET 2.0-hoz képest.
    Mutasd a teljes hozzászólást!
  • Szerintem meg x olajcégnek vagy y gyógyszergyárnak kéne inkább értelmes személyzeti politikát folytatnia. A rendszergizdák többnyire kényelmes és nyugis nyolc (értsd négy) órás melóra vágynak, minden átállás/kiegészítés/frissités maga a pokol, hogy a hardver- és support-vonzatokról szó se essék.

    Ha nincs külső nyomás az IT-n, vagy ha az IT ügyesen misztifikálja magát (mindkettővel találkoztam multinál), hónapokkal meg tud hosszabítani egy bevezetését.

    Szóval ez nem Microsoft kompetencia, ígérni meg nyilván nem ígérheti (senki nem hinné) h pl. az XP->Vista átállás sima ügy - mert garantáltan nem az.
    Mutasd a teljes hozzászólást!
  • külföldi IT központjai iszonyú lassan engednek bármilyen platformváltást a corporate gépeken.


    Szerintem itt a Microsoftnak kell lépnie elsősorban. Ahogy a fejlesztőket sikerüklt összefogniuk az utóbbi két évben, simán megtehetnék a nagyobb partnereikkel is 2008-tól kezdve. Nem lennék meglepve, ha lenne már erre is valami stratégiájuk.
    Mutasd a teljes hozzászólást!
  • Na ja, de Acropolis sajnos csak jövő, a SCSF(+WSSF) azonban a tökéletesen használható jelen. WPF, SQL2k8, .NET 3.5 és főleg a Vista-függő megoldások ráadásul még akár évekig(!) is elérhetetlenek, hiszen a partnereink külföldi IT központjai iszonyú lassan engednek bármilyen platformváltást a corporate gépeken. Hiába a durván jó megoldások, ha a rögvalóság más.

    Szerencsére azonban szinte minden elérhető a "jó öreg" .NET 2.0-val is ami még átgondoltabban .NET 3.x-ben van/jön, kivéve a lent emlegetettet. Szerintem iszonyú hatékonyan lehet fejleszteni a software factorykkal és felspécizett VS2k5-el. Ha pedig a fejlesztőeszköz vagy a partnercég váltása között kell választani, érthető módon mindig az eszköz fog idomulni.
    Mutasd a teljes hozzászólást!
  • Ezeket tudja felmutatni a 3.5. Jelenleg tesztelem, de a WF + WCF service projekt nagyon jónak tűnik.

    - A WCF-nek szerveroldalon van saját kontextusa, ugyanúgy, mint az ASP.NET-nek, tehát minden kérést külön lehet választani.

    - IIS-ben hostolva is pöccre működik, mert a WCF saját threading/policy rendszert használ, amire ráül a WF. Egyébként optimalizálták a szálkezelést a 3.5-ös verzióban. A WAS támogatása is be van építve a rendszerbe.

    Eddig ennyit derítettem ki.

    boj:
    Még valami lightweight cuccot idedobhatna az MS üzleti logikára mint tette a WPF-el a megjelenítő rétegre. Az lenne csak e ööm' bódottá, örö' bódottá.


    Biztos forrásból tudom, hogy készül. Kliensoldalra pedig ott az Acropolis projekt (aminek elméletileg lesz Silverlight 1.1 változata is).
    Mutasd a teljes hozzászólást!
  • BRMS/BRE-ben szerintem Java még ránkver (mármin dotnetekre), pl. a JBoss Rules (aka Drools) elég erős kifejezőkésséggel bíró cucc, ráadásul az Excelben megírt döntési táblákat ugyanúgy megeszi mint a plain text nyelvi fájlokat. Van .NET ikvm-es portja, nade akkor is... (Architektúra Fórumon láttam NxBRE postot, ezzel végképp csak végszükség esetén éri meg foglalkozni szvsz.)

    Még valami lightweight cuccot idedobhatna az MS üzleti logikára mint tette a WPF-el a megjelenítő rétegre. Az lenne csak e ööm' bódottá, örö' bódottá.


    WCF...ja:)
    Mutasd a teljes hozzászólást!
  • mifelénk az a tapasztalat, hogy a wf - bármi szép is - még nem teljesen kiforrott. lásd a következőket:

    - nincs semmi támogatás a több node-os működésre
    - iis-ben hostolva kölcsönösen kinyírják egymást az aspnet thread poollal
    - a jelenleg elérhető verzióban a task perzisztencia állítólag nem kifejezetten kiforrott, majd az orcasos állítólag jobb lesz
    - úgy általában, azt mondják a Bölcsek és a Nagyok, hogy ezt kliensoldali workflow-nak találták ki, tehát szerveroldalon csak fenntartásokkal használható egyelőre, megintcsak majd az orcas-os verzió jobb lesz


    (ennek ellenére használjuk :)

    mondjuk nem a teljes folyamat hangszerelésére, de pl. állapotgépet már nem implementálunk kézzel. a rules engine része is egész jó...


    a wcf viszont egy főnyeremény
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Jelenleg a fent említett környezetet találtam a legalkalmasabbnak egy elkészítendő rendszer üzleti logikájának az elkészítésére.
    Egyenlőre még csak külön-külön foglalkoztam velük, de a cél az intergrált használat lenne.
    Nagyszerű cikk van az MSDN -en erről.
    Mivel eléggé új mindkettő ezért gondolom sok gyakorlati és üzemeltetési tapasztalata még nem sok mindenkinek van vele, de ha mégis lenne ezek érdekelnének engem!
    Az integráció milyen buktatókat takar, mi az amit érdemes Workflow szinten modellezni és mi az amit nem (pl: teljes alkalmazás egy Activity vagy csak a kényesebb részfeladatok vannak így modellezve) .
    Az UI-el történő összekapcsolásra milyen módszert alkalmaztok (pl: ExternalDataExchange ,stb...).
    Tudom nagy témakör és kevés konkrétumot írtam, de összességében is érdekelne a tapaszataltotok.

    Üdv!
    Mutasd a teljes hozzászólást!
Címkék
abcd