Re: Vyvojove prostredi pro SOA
Oto 'tapik' Buchta wrote: No, tak tato diplomka by mne velmi zajimala. Jinak doporucuji prostudovat velka BPMka a klikatory k ebXML. Bohuzel aktualni status nevim, posledni solidni BPMko, o kterem jsem vedel, bylo eXcelon BPM, ktere spolu s celym eXcelonem sezral Progress Software a jak vsichni zname Progress ... Tak jsem nasel velmi zajimave klikadlo jmenem Componet-X (http://enterprisecomponent.com/products/). Umi vizualne vytvaret aplikace podle EDOC. Zakladni myslenkou je, ze si komponenty vymenuji dohodnutym protokolem dokumenty, ktere postupne transformuji. Jako aplikacni server pouzivaji Tomcat, komponenty jsou hlavne v Java. Ted maji novy projekt, ktery bude postaveny nad Eclipse, ktery bude o dost chytrejsi. Je zajimave, ze tento projekt sponzoruje/podporuje USA Government. Vizte: http://blogs.ittoolbox.com/eai/bpel/archives/006642.asp
Re: Vyvojove prostredi pro SOA
Oto 'tapik' Buchta wrote:
Ja v tom draftu vidim v casti 2.2 explicitne uvedene, ze SOA *neni*
Objektove Orientovana tj. CORBA-like.
OOP neni CORBA.
A navic to je asi tak, jako kdyz Paroubek v televizi rekl, ze ten, kdo
vyklada, ze CSSD prosazuje zakony za pomoci komunistu, lze. Nekladou duraz na
zakladni principy OOP jako je dedicnost a enkapsulace, ale napriklad
Booz-Allenove vidi kazdou servisu jako xicht pro s databazi manipulijici
business logic. Bohuzel :-(
Na ksichtu pro manipulaci s databazi jeste neni nic spatneho.
K tomu OOP - nejde o OOP, ale o ditribuovane objekty.
Ze v distribuovanem pripade se neda distribuovanost objektu schovat
pekne popisuje tohle:
[1] Samuel Kendall and Jim Waldo and Ann Wollrath and Geoff Wyant:
Note on Distributed Computing, 1994,
http://research.sun.com/techrep/1994/abstract-29.html
A vyborny clanek, proc distribuovane objekty jsou spatne je tohle:
[2] Werner Vogels: Web Services Are Not Distributed Objects,
IEEE Internet Computing, Volume 7, Number 6, 2003,
http://csdl.computer.org/dl/mags/ic/2003/06/w6059.htm
(asi je to videt jenom pro predplatitele IEEE Digital Library)
v podstate pise, ze problem s objekty v distribuovanem pripade
jsou vzajemne reference objektu a orientace na operace
misto na dokumenty, protoze prvni vyzaduje distribuovane
garbage collectory a druhe znemoznuje evoluci.
A velice trefny postreh je v
[3] Pat Helland: Data on the Outside Versus Data on the Inside,
{CIDR, Second Biennial Conference on Innovative Data Systems Research,
2005, http://www-db.cs.wisc.edu/cidr/cidr2005/papers/P12.pdf
totiz ze prechod od DOO k SOA je jako prechod od Newtonovske
k Einsteinove fyzice - prvni predpoklada, ze existuje jakysi
pozorovatelny soucasny stav celeho systemu, kdezto druha
musi pocitat s tim, ze viditelny je vzdy jen obraz minuleho
stavu vzdaleneho systemu.
No a mne pripada, ze ten draft od OASIS si je tehto problemu
s DOO vedom, coz je pozitivni.
Souhlasim s tebou, lec:
V dokumentu neni o semantice nic poradneho napsano a pokud vim, tak onou
semantikou byla prave myslena implicitni semantika dana standardizovanymi XML
schematy. Bohuzel. Prestoze pouzili slovo ontologie, o RDF si mysli sve :-(
Co se ontologii tyce, tak si o RDF taky myslim sve, a myslim,
ze OWL by se dal postavit i bez RDF.
Vis, Makube, toto preci neni o transakcnosti. To je o schopnosti resit
nezvykle situace. Co udelas, kdyz si koupis tapetu presne na miru a pak pri
lepeni zjistis, ze jsi spatne meril? Kdyby slo rollbacknout tapetu a lepidlo
zpatky do obchodu, bylo by to prima. Jenomze takto to nefunguje. A uplne
stejne je to ve svete long-running loosely-coupled procesu. I v tvem pripade.
Zavolas si na hotel, tam ti reknou:
a) ano, muzeme zrusit rezervaci
b) za poplatek ji zrusime
c) mate smulu
Mas pravdu, ale pokud vis predem, ktera z moznosti a)-c) muze nastat,
muzes s tim pocitat. A pri sestavovani slozitejsiho workflow
muzes predem pocitat s tim, ze kdyz dojde k nejake chybe (vypadne
letadlo), muzes udelat jistou kompenzacni akci (zrusit i hotel).
Muzes to misto transakcnosti nazvat kompenzovatelnosti vypadku,
ale je to jisty aspekt :-)
Problem je v jedne veci: neexistuje ucelena architektonicka studie. Dodavatele
nechavaji tuto bohulibou cinnost na Gartnerech a Burtonech a ZiffDavisech a
jim podobnych a vzdy, kdyz nejaka takova analyticka skupúina s necim prijde,
snazi se ukazat, jak napasovat sve produkty prave do te ktere strategie.
Treba zajimavy link od celkem mene znamych je na
http://www.newrowley.com/reports/soa_nrg_v1_0.pdf
Diky za odkazy. Tenhle je pekne napsany, ale v podstate rikaji jenom
ze SOA = neco postavenene na XML a WS.
Mali jsou moc mali a velci (MS a IBM) jsou rozhadani. A tak se hlavni
architektonicky vyvoj deje vice mene zakulisne pri osobnich jednanich na
face-to-facech, interopech ci conf-callech ruznych komisi. Spousta stripku se
objevuje na Blozich architektu a evangelistu. Jenom obcas vyleti neco jako
IONA seven points
(http://whitepapers.zdnet.co.uk/0,39025945,60040064p-39000575q,00.htm),
Na tohle se nedostanu, chce to clenstvi :-(
Ale smer je vice mene dany uz tri roky: jedine, co ma vyznam, jsou data. Neni
ani tak dulezite KDO provede danou akci, ale ZE se provede. Enrichment dat
je uprednostnen nad procesy. Mizi klasicke consumer-provider kontrakty, do
popredi se dostavaji dynamicke kontraktory. Dokumenty putujici po Internetu a
hledajici-si svuj cil. A je jedno, jestli putuje po ESB, Content-Based
Routeru, je jedno, jestli je pouzito UDDI, superinteligentni Broker nebo nas
Blizzard, je jendo, jestli je zprava zpracovana sofistikovanym Gridem, tupym
BPELem, C# servisou, EJBckem nebo jenom proleti nasim Arkem, a temi je jedno
muzeme pokracovat.
Proste vztah klient-sluzba v pojeti teto specky je velmi eqivalentni vztahu
CORBA-klient - remote-object. V SOA takovy staticky kontrakt neni. Kdo si jej
vytvori, prichazi o SOA. Takove srandicky jako QoS-based runtime licitace
staveni
Re: Vyvojove prostredi pro SOA
Martin Krajci wrote: Dobry den, Tiez som zbieral informacie o SOA a zatial najlepsi zdroj som nasiel tu http://searchwebservices.techtarget.com/topics/0,295493,sid26_tax299037,00.html a tu reklamahttp://www.systinet.com//reklama. O vyvojovom prostredi som vsak zatial nepocul. Delal jsem si o SOA resersi, a zatim to vypada, ze sice vam kazdy vyrobce rad proda nejaky produkt, ktery ma SOA v nazvu, ale jinak neni zatim moc teoreticky zvladnute, co SOA je. Vi se, ze by mela byt lepsi nez Distribuovane Objektove Orientovane systemy (DCOM, CORBA), protoze DOO systemy kvuli referencim mezi objekty a RPC-stylu volani nejsou vhodne pro opravdu rozlehle systemy, kde kazdou cast vyviji nekdo jiny, neb zpusobuji tight-coupling mezi klientem a serverem. Ale jak vlastne spravne navrhnout sluzby a jejich rozhrani, aby byly loosely coupled, se moc nevi. Makub -- ~~ Supercomputing Center Brno Martin Kuba Institute of Computer Scienceemail: [EMAIL PROTECTED] Masaryk University http://www.ics.muni.cz/~makub/ Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775 -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Vyvojove prostredi pro SOA
Martin Kuba napsal(a): Delal jsem si o SOA resersi, a zatim to vypada, ze sice vam kazdy vyrobce rad proda nejaky produkt, ktery ma SOA v nazvu, ale jinak neni zatim moc teoreticky zvladnute, co SOA je. Vi se, ze by mela byt lepsi nez Distribuovane Objektove Orientovane systemy (DCOM, CORBA), protoze DOO systemy kvuli referencim mezi objekty a RPC-stylu volani nejsou vhodne pro opravdu rozlehle systemy, kde kazdou cast vyviji nekdo jiny, neb zpusobuji tight-coupling mezi klientem a serverem. Ale jak vlastne spravne navrhnout sluzby a jejich rozhrani, aby byly loosely coupled, se moc nevi. Ja v ramci diplomky delam reseris na to, jak muze MDA pomoci pri vyvoji SOA. Tj. jak usnadni propojovani sluzeb az na uroven transakci, profilu, spravy sezeni apod. (tj. napr. i to aby to usnadnilo volne sprazeni sluzeb). Zatim jsem zjistil, ze MDA usetri praci pri vyvoji jednotlivych sluzeb. Pro pokrocilejsi veci nastroje zatim nejsou (teda jsou, ale teoreticky, napr. ty od IBM umi jakekoliv transformace, jen je nekdo musi implementovat, coz je tak slozite, ze to zatim nikdo nedela). Dalsi zajimavy problem je, ze jsou nastroje na integraci sluzeb orientovany na programatory, nikoliv na uzivatele. Takze je nelze pouzit napr. v business intelligence. Pak by si byznys analytik naklikal potrebny proces a mohl ho rovnou pouzit. To narazi i na jinem miste, ze sluzby (procesy) nemaji uzivatelske rozhrani (napr. webove). Tady by MDA mela pomoci vytvaret ti rozhrani a byt zdrojem metadat pro propojovani (generovat RAS - reusable asset specification). IBM na to ma i metodiku ABD (assest based development - doplnek k RUP). Ale maji zatim jedno prakticke pouziti. (oni i nasazeni MDA je v praxi bidne a realnych projektu je jako safranu). Jeste ke standardum - TOGAF ma mapovani pro MDA, tedy zrejme i mapovani SOA a MDA. Zhruba takoveto: CIM - byznys model PIM - model jednotlive sluzby PSM - model jednotlive sluzby zavisle na platforme (napr. WS). A jelikoz nastroje pro MDA jsou zatim jen PIM a PSM (CIM moc zapojit neumi), tak se pro SOA pouzivaji spatne. (to je i ma poznamka s rozhranim orientovanym na programatora).
Re: Vyvojove prostredi pro SOA
Oto 'tapik' Buchta wrote: A trochu informaci ze zakulisi: vysledky teto komise budou pravdepodobne velmi irelevantni a hodne o tom svedci i jejich draft :-( Diky za informace ze zakulisi, ale mam pripominky. O mnohem napovida jiz http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm-editors Velmi dobre si prohlednete cleny. Vetsinou se jedna o velke uzivatele a hlavni zakazniky. Je zvlastni, ze velci uzivatele neceho, co o cem se mluvi uz nekolik let, si stanovi komisi pro navrh referencniho modelu, aby se vlastne vedelo, o cem se mluvi. A vetsinu prace nechaji na trech firmach: Adobe, Booz Allen Hamilton a Fujitsu. To, ze se o necem mluvi uz nekolik let, jeste neznamena, ze vsichni mluvi o tom stejnem nebo ze se vi, co to vlastne je a jak to ma fungovat. Kdyz si prectes definice SOA od velkych prodejcu jako IBM, Microsoft, BEA a podobni, tak se neshodnou ani na tom, jestli je SOA architektonicky styl, komponentovy model, architektura, metodologie nebo politiky a frameworky. Humbuku zivenych vyrobci jsme zazili uz dost, takze to, ze neco velci vyrobci prosazuji, jeste neznamena, ze to je pouzitelne nebo uzitecne, a uz vubec ne, ze by se uzivatele nemeli snazit definovat, co potrebuji. Jinak o teto specce ani nemuzeme rici, ze je slusne receno na nic a nic. Je to krok do pekel, ve kterem se tukani snazi dat do hromady to, jak pochopili, ze by SOA mela fungovat a to, co po SOA chteji. Jenomze vyjde paskvil, protoze nekdo potrebuje toto a jiny toto a nevidi si za spicku sveho nosu. Radeji si udelaji komisi nez aby si vyslechli, jak SOA definuji jednotlivi hraci na trhu. A ti ji musi definovat ruzne, protoze kazdy se pozicionuje jinam a tvrdi, ze zrovna ta jeho cast je ta nejdulezitejsi na celem svete (a je jedno, zda ma nebo nema pravdu), kazdopadne v globalech se zas az tak nelisi od Gartneru, kteri to maji zmaknute celkem pekne. To je sice drtiva kritika, ale mne ten draft prijde uchazejici, uz proto, ze za cestu do pekel naopak povazuji, kdyz pod stejnym nazvem mysli kazdy neco jineho, protoze si to kazdy nadefinuje, jak se to hodi zrovna jemu. A ted k draftu: Kapitolka 3.2.1.3 Reachability je presne to, o cem SOA byt nema ;-) Dale doporucuji kapitolu 2.2 (a jeji posledni odstavec ;-) ), ktera je opravdu reprezentativnim vzorkem. Lide znali historie CORBY se opravdu budou za bricho popadat ;-) Tady bych byl opatrnejsi. Trh s CORBA komponentami nevznikl s vice duvodu, jako ze implementace CORBY nebyly interoperabilni, a ze OO rozhrani nedovoluji nezavisly vyvoj komponent. SOA nemusi opakovat stejne chyby prave proto, ze neni OO. A co treba takova citace o provadeni akci against the service? Nene. Nekdo proste neslysel o WS-Addressingu. Tvurci teto specky si mysli, ze SOA je jenom tzv. XORBA (nepatentovano, lec priznano Radovanovi Janeckovi), neboli CORBA over XML. Jenze to je SOAP pet let stary a hlavni hraci na trhu SOA jsou jiz nekde UPLNE jinde (Pozor! MS o sobe tvrdi, ze SOA nema a neposkytuje!). Ja v tom draftu vidim v casti 2.2 explicitne uvedene, ze SOA *neni* Objektove Orientovana tj. CORBA-like. A kecy o semantice dat to nenapravi (kdo kdy slysel, ze ZML-Schema definuje semantiku?) Co to ? Slova XML a schema se v tom dokumentu vubec nevyskytuji ! Explicitni semantika je velice dulezita, protoze WSDL definuji pouze lokalne nazvy XML elementu, ale pokud vyznam jejich obsahu neni urcen zadnou explicitni specifikaci zpracovatelnou programem, musi byt vyznam hardkodovan do programu programatory. A to je velice neflexibilni. A uplne nejvic to dorazili, kdyz pisou o transakcinich aspektech servisy. Transakce v SOA zkratka nefunguji a vi to uz uplne vsichni, kdo s nimi meli co do cineni. A vsechny ty snahy o BTP, WS-TX ci WS-Transaction skoncili krachem. Nefunguji ACID transakce, na ktere jsou vsichni zvykli z databazi. Ale to neznamena, ze sluzba nemuze mit transakcni aspekty. Pokud sis napriklad pres dve sluzby zarezervoval letadlo a hotel, tak jsou to dve transakce, a kdyz ti zrusi letadlo, tak bys mel zrusit i hotel, to proste je transakcni aspekt, i kdyz se to neda vyresit klasickou transakci se zamykanim zdroju. Bojim se, ze bude-li tento draft prijat jako 1.0 a bude nekym prosazovan, stahne to SOA zase na zacatek dlouho ji tam udrzi. Hm hm, a kde ze to teda vlastne SOA dneska je (krome toho, ze UPLNE jinde ?). Jestli mas odkaz na nejaky rozumny text, ktery nejsou jenom marketingove zvasty, tak si ho velice rad prectu. Makub -- ~~ Supercomputing Center Brno Martin Kuba Institute of Computer Scienceemail: [EMAIL PROTECTED] Masaryk University http://www.ics.muni.cz/~makub/ Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775 -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Vyvojove prostredi pro SOA
On Monday 20 of March 2006 18:29, Martin Kuba wrote: Oto 'tapik' Buchta wrote: A ted k draftu: Kapitolka 3.2.1.3 Reachability je presne to, o cem SOA byt nema ;-) Dale doporucuji kapitolu 2.2 (a jeji posledni odstavec ;-) ), ktera je opravdu reprezentativnim vzorkem. Lide znali historie CORBY se opravdu budou za bricho popadat ;-) Tady bych byl opatrnejsi. Trh s CORBA komponentami nevznikl s vice duvodu, jako ze implementace CORBY nebyly interoperabilni, a ze OO rozhrani nedovoluji nezavisly vyvoj komponent. SOA nemusi opakovat stejne chyby prave proto, ze neni OO. Co se tyce interoperability mas pravdu - XSLT a XQuery jsou mnohem hezci nastroje nez CORBA2CORBA convertory. Na druhou stranu interoperabilita nad IDLky byla asi na stejne urovni jako mezi MS-serializaci a Apache-serializaci, o hratkach s datumem, nullem ci choicem ani nemluvim. Navic jsem ochoten tvrdit, ze kdyby v CORBA svete byla firma kalibru MS (maj to vsichni, ale nic horsiho neni), i tam by se vsichni prizpusobovali jednomu hraci. A co treba takova citace o provadeni akci against the service? Nene. Nekdo proste neslysel o WS-Addressingu. Tvurci teto specky si mysli, ze SOA je jenom tzv. XORBA (nepatentovano, lec priznano Radovanovi Janeckovi), neboli CORBA over XML. Jenze to je SOAP pet let stary a hlavni hraci na trhu SOA jsou jiz nekde UPLNE jinde (Pozor! MS o sobe tvrdi, ze SOA nema a neposkytuje!). Ja v tom draftu vidim v casti 2.2 explicitne uvedene, ze SOA *neni* Objektove Orientovana tj. CORBA-like. OOP neni CORBA. A navic to je asi tak, jako kdyz Paroubek v televizi rekl, ze ten, kdo vyklada, ze CSSD prosazuje zakony za pomoci komunistu, lze. Nekladou duraz na zakladni principy OOP jako je dedicnost a enkapsulace, ale napriklad Booz-Allenove vidi kazdou servisu jako xicht pro s databazi manipulijici business logic. Bohuzel :-( A kecy o semantice dat to nenapravi (kdo kdy slysel, ze ZML-Schema definuje semantiku?) Co to ? Slova XML a schema se v tom dokumentu vubec nevyskytuji ! Explicitni semantika je velice dulezita, protoze WSDL definuji pouze lokalne nazvy XML elementu, ale pokud vyznam jejich obsahu neni urcen zadnou explicitni specifikaci zpracovatelnou programem, musi byt vyznam hardkodovan do programu programatory. A to je velice neflexibilni. Souhlasim s tebou, lec: V dokumentu neni o semantice nic poradneho napsano a pokud vim, tak onou semantikou byla prave myslena implicitni semantika dana standardizovanymi XML schematy. Bohuzel. Prestoze pouzili slovo ontologie, o RDF si mysli sve :-( A uplne nejvic to dorazili, kdyz pisou o transakcinich aspektech servisy. Transakce v SOA zkratka nefunguji a vi to uz uplne vsichni, kdo s nimi meli co do cineni. A vsechny ty snahy o BTP, WS-TX ci WS-Transaction skoncili krachem. Nefunguji ACID transakce, na ktere jsou vsichni zvykli z databazi. Ale to neznamena, ze sluzba nemuze mit transakcni aspekty. Pokud sis napriklad pres dve sluzby zarezervoval letadlo a hotel, tak jsou to dve transakce, a kdyz ti zrusi letadlo, tak bys mel zrusit i hotel, to proste je transakcni aspekt, i kdyz se to neda vyresit klasickou transakci se zamykanim zdroju. Vis, Makube, toto preci neni o transakcnosti. To je o schopnosti resit nezvykle situace. Co udelas, kdyz si koupis tapetu presne na miru a pak pri lepeni zjistis, ze jsi spatne meril? Kdyby slo rollbacknout tapetu a lepidlo zpatky do obchodu, bylo by to prima. Jenomze takto to nefunguje. A uplne stejne je to ve svete long-running loosely-coupled procesu. I v tvem pripade. Zavolas si na hotel, tam ti reknou: a) ano, muzeme zrusit rezervaci b) za poplatek ji zrusime c) mate smulu Vsechna tri chovani se ti v beznem zivote pri rezervaci pokoju mohou stat. Jaky je teda transakcni aspekt te ktere situace? Opravdu to neni jenom o ACIDite. Je ot celkem principialni. Bojim se, ze bude-li tento draft prijat jako 1.0 a bude nekym prosazovan, stahne to SOA zase na zacatek dlouho ji tam udrzi. Hm hm, a kde ze to teda vlastne SOA dneska je (krome toho, ze UPLNE jinde ?). Jestli mas odkaz na nejaky rozumny text, ktery nejsou jenom marketingove zvasty, tak si ho velice rad prectu. Problem je v jedne veci: neexistuje ucelena architektonicka studie. Dodavatele nechavaji tuto bohulibou cinnost na Gartnerech a Burtonech a ZiffDavisech a jim podobnych a vzdy, kdyz nejaka takova analyticka skupúina s necim prijde, snazi se ukazat, jak napasovat sve produkty prave do te ktere strategie. Treba zajimavy link od celkem mene znamych je na http://www.newrowley.com/reports/soa_nrg_v1_0.pdf Mali jsou moc mali a velci (MS a IBM) jsou rozhadani. A tak se hlavni architektonicky vyvoj deje vice mene zakulisne pri osobnich jednanich na face-to-facech, interopech ci conf-callech ruznych komisi. Spousta stripku se objevuje na Blozich architektu a evangelistu. Jenom obcas vyleti neco jako IONA seven points (http://whitepapers.zdnet.co.uk/0,39025945,60040064p-39000575q,00.htm),
Re: Vyvojove prostredi pro SOA
On Monday 20 of March 2006 11:52, Lukas Barton wrote: Ja v ramci diplomky delam reseris na to, jak muze MDA pomoci pri vyvoji SOA. Tj. jak usnadni propojovani sluzeb az na uroven transakci, profilu, spravy sezeni apod. (tj. napr. i to aby to usnadnilo volne sprazeni sluzeb). No, tak tato diplomka by mne velmi zajimala. Jinak doporucuji prostudovat velka BPMka a klikatory k ebXML. Bohuzel aktualni status nevim, posledni solidni BPMko, o kterem jsem vedel, bylo eXcelon BPM, ktere spolu s celym eXcelonem sezral Progress Software a jak vsichni zname Progress ... -- Oto 'tapik' Buchta, [EMAIL PROTECTED] http://www.buchtovi.cz __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Vyvojove prostredi pro SOA
Oto 'tapik' Buchta wrote: On Monday 20 of March 2006 11:52, Lukas Barton wrote: No, tak tato diplomka by mne velmi zajimala. Trochu starsi odkazy k propojeni SOA a MDA: http://xml.coverpages.org/Larsen-RAS200311.pdf - od IBM, Asset-based development, ktery predpoklada ze prave MDA sluzby prinesou velmi kvalitni RAS http://www.omg.org/registration/registration-mdasoa.htm - od SUNu, popis toho, co vsechno by mohli prinest MDA sluzby do moznosti jejich integrace http://www.bptrends.com/publicationfiles/12-03%20COL%20Frankel%20-%20MDA%20SOA%20-%20Rosen.pdf - i kdyz pan Frankel si mysli, ze SOA = WS. Problem je, ze MDA narazi na nedostatek (nekvalitu) standardu pro dane oblasti nasazeni. Problem je, kdyz chcete propojit dve sluzby zalozene na MDA od ruznych dodavatelu. Pro snadne propojeni o tech modelech musi platit volnejsi omezujici podminky - napr. pouzivaji stejny profil a modelovaci jazyk pro PSM. Bohuzel implementace nastroje, kde to propojeni pujde naklikat, je znacne netrivialni. A uroven abstrakce diky nutnosti propojovat se na urovni PSM je jen o kousek vetsi, nez kdyz to programujete. Samozrejme, ze muzeme propjovat na urovni CIM modelu, ale z toho po transformaci do PIM a PSM zase vypadne nedoplneny PSM model. Od rucniho propojovani by nas mohlo zachranit jedine standardizovane mapovani z PIM do PSM (tj. platformy) pro vsechny ruzne platformy a to, ze ho dodavatele budou dodrzovat, coz je nepredstavitelne sci-fi. (kdyz se nedohodnou ani pro webove sluzby). Jinak doporucuji prostudovat velka BPMka a klikatory k ebXML. Bohuzel aktualni status nevim, posledni solidni BPMko, o kterem jsem vedel, bylo eXcelon BPM, ktere spolu s celym Xcelonem sezral Progress Software a jak vsichni zname Progress ... Bohuzel, jsou klikatka, ktere neni mozne sehnat pro vyzkouseni, napr. WebSphere Business Integration Modeler Advanced Edition. Ale u techto klikatek ten vyvoj na dlouhou dobu zustane. Proste neco pro vyvojare jako IBM WebSphere Studio Application Developer Integration Edition, ktere usnadni propojovani mezi sluzbami nekolika vendoru. PS: cely tento text je hodne ovlivnen tim, jak se na to diva IBM. Protoze maji na webu nejdostupnejsi zdroje i trial verze programu. A umi toho precejen nejvic.
Re: Vyvojove prostredi pro SOA
Zdravim, neviem sice ake vsetky atributy ma mat SOA vyvojove prostredie.. SOA chapeme skor ako IT strategiu. Na vacsinu veci (pre portalove a integracne sluzby) pouzivame najma BEA WebLogic Workshop. S pozdravom, IP __ Od: [EMAIL PROTECTED] Komu: Java konference@java.cz CC: Datum: 19.03.2006 11:34 Předmět: Vyvojove prostredi pro SOA Zdravim, pouzivate nekdo nejake jine komplexni vyvojove prostredi pro SOA nez to od IBM? Tj. neco co nahradi celou sadu nastroju od IBM Websphere Business Modeler, pres IBM Rational Software Architect, IBM Rational Application Developer az po Tivoli Application Manager.* *Diky, Lukas
Re: Vyvojove prostredi pro SOA
Ivan Pavelovic wrote: Zdravim, neviem sice ake vsetky atributy ma mat SOA vyvojove prostredie.. SOA chapeme skor ako IT strategiu. Slovo prostredi melo byt v uvozovkach. S chapanim SOA se stotoznuji, ale vzdy to nakonec musi podporovat nejake konkretni nastroje. Jinak mne zajimaji zejmena nastroje, ktere umoznuji kombinovat SOA a MDA, jako napr. IBM Rational Software Architect. Lukas
