CORBA vs. Web Services
64 отговора
2205 прегледа
Re: CORBA vs. Web Services
На всеки 5-6 години се появява нов стандарт, който претендира че прави (почти) същото като стария, но по-лесно.
И когато е направен да поддържа всичко, се оказва, че изобщо не е по-лесно да се използва.
Сравнението между Web Services и CORBA е неуместно, ако ти трябват транзакции, security, сесии и т.н.
И когато е направен да поддържа всичко, се оказва, че изобщо не е по-лесно да се използва.
Сравнението между Web Services и CORBA е неуместно, ако ти трябват транзакции, security, сесии и т.н.
Re: CORBA vs. Web Services
>>Сравнението между Web Services и CORBA е неуместно, ако ти трябват >>транзакции, security, сесии и т.н.
Има auto-support за транзакции, тоест ти не трябва да правиш почти нищо:
[линк]
Няма абсолютно никакъв проблем със сесии:
[линк]
И освен това хората са помислили съвсем професионално за секюрити:
[линк]
>>>Сравнението между Web Services и CORBA е неуместно,
Неуместно е единствено да си правиш изводи при непознаване на фактите.
Има auto-support за транзакции, тоест ти не трябва да правиш почти нищо:
[линк]
Няма абсолютно никакъв проблем със сесии:
[линк]
И освен това хората са помислили съвсем професионално за секюрити:
[линк]
>>>Сравнението между Web Services и CORBA е неуместно,
Неуместно е единствено да си правиш изводи при непознаване на фактите.
Re: CORBA vs. Web Services
значи като го гледам тия статии от мсдн,
сесиите са си на IIS-to, а транзакциите са това, което беше MTS(COM+) + ASP.
и по една щастлива случайност уеб сървисите вървящи на IIS, ползват и двете благини, просто щото върват на IIS, a не защото са SOAP ili Веб сървиси....
сесиите са си на IIS-to, а транзакциите са това, което беше MTS(COM+) + ASP.
и по една щастлива случайност уеб сървисите вървящи на IIS, ползват и двете благини, просто щото върват на IIS, a не защото са SOAP ili Веб сървиси....
Re: Да
>Та в крайна сметка ако искаш веб сървиси - или WINDOWS, или се е**ш в гъза.
>Не е готино така, не е готино ..........
>:-(
[линк]
pochti tolkova lesno kakto i .NET implementaciqta. generira proxyta i stubove, s koito da vikash java metodi prez sapuna. ne te kara da dyvchesh wsdl-to... no to ne e tolkova trudno i pomaga ako znaesh koe za kakvo e.
sorry za latinicata, shte q opravq ASAP
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
>Не е готино така, не е готино ..........
>:-(
[линк]
pochti tolkova lesno kakto i .NET implementaciqta. generira proxyta i stubove, s koito da vikash java metodi prez sapuna. ne te kara da dyvchesh wsdl-to... no to ne e tolkova trudno i pomaga ako znaesh koe za kakvo e.
sorry za latinicata, shte q opravq ASAP
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
Re: Да
Това което го описах по-горе го прави автоматично Визуалното Студио, но и аз предпочитам на ръка да видя генерирания WSDL от дадения Уеб-Сървис и ръчно да си генерирам стъбове и прокситa със wsdl.exe. Обичам и лично да видия какви СОАП заявки генерира фреймуърка, понеже ми е интересно от гледна точка на интероперабилити.
Пича се притеснява, че .НЕТската имплементация на Уеб-Сървиси няма да е съвместима със примерно Жава клиент, което разбира се не е вярно понеже всичко се свежда до СОАП.
И въобще като цяло Уеб-сървис подхода е определено доста по-приятно и лесно (и интересно!) за писане, отколкото безумни технологии като корба.
Пича се притеснява, че .НЕТската имплементация на Уеб-Сървиси няма да е съвместима със примерно Жава клиент, което разбира се не е вярно понеже всичко се свежда до СОАП.
И въобще като цяло Уеб-сървис подхода е определено доста по-приятно и лесно (и интересно!) за писане, отколкото безумни технологии като корба.
Re: Да
>Пича се притеснява, че .НЕТската имплементация на Уеб-Сървиси няма
>да е съвместима със примерно Жава клиент, което разбира се не е вярно
>понеже всичко се свежда до СОАП.
prav si. probvali sme s kolegite - pone za vikane na webmetod vyrvqsht na tomcat s axis ot C# tvorenie na drugoto pc problemi nqma.
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
>да е съвместима със примерно Жава клиент, което разбира се не е вярно
>понеже всичко се свежда до СОАП.
prav si. probvali sme s kolegite - pone za vikane na webmetod vyrvqsht na tomcat s axis ot C# tvorenie na drugoto pc problemi nqma.
--
"Agile is a mindset, not a set of practices, rules, or tools."
Tom Poppendieck
Re: CORBA vs. Web Services
Ами аз именно затова постнах линка към СОАП сайта на w3c и наблегнах че 2 от 5-мата човека отговарящи за СОАП стандартизацията са от Майкрософт.
Де факто, целия шум около XML и в частност СОАП и Уеб-Сървисес е изцяло дело на Майкрософт, така че ако очакваш стандарти за по-сложните неща като транзакции и сесии на платформа различна от .НЕТ определено ще си имаш доста проблеми.
Доколкото знам стандартния съпорт от Сън за Уеб-Сървисес във Жава е доста куц и затова в момента и АйБиЕм и Беа и Апаче презглава пишат адд-он-и за по нормална подръжка. За транзакции, сешън и секюрити- според зависи на кой апликейшън сървър ще рънваш апликейшъна (толкова за "write once run everywhere"). Лично аз определено не бих се наел да пиша Уеб-Сървисес сървър на платформа различна от .НЕТ. За клиент може би е по-лесно.
Де факто, целия шум около XML и в частност СОАП и Уеб-Сървисес е изцяло дело на Майкрософт, така че ако очакваш стандарти за по-сложните неща като транзакции и сесии на платформа различна от .НЕТ определено ще си имаш доста проблеми.
Доколкото знам стандартния съпорт от Сън за Уеб-Сървисес във Жава е доста куц и затова в момента и АйБиЕм и Беа и Апаче презглава пишат адд-он-и за по нормална подръжка. За транзакции, сешън и секюрити- според зависи на кой апликейшън сървър ще рънваш апликейшъна (толкова за "write once run everywhere"). Лично аз определено не бих се наел да пиша Уеб-Сървисес сървър на платформа различна от .НЕТ. За клиент може би е по-лесно.
Re: CORBA vs. Web Services
Чакай, чакай. Преди да започнеш да плюеш Sun и IBM, че не поддържали добре SOAP, ми покажи _къде_ точно в стандарта за SOAP се дефинира как се поддържат транзакции и сесии. Ако няма такова нещо в стандарта (а в 1.2 няма), няма какво да говорим, че Web Services го поддържат.
Това, че Майкрософт са написали някакви надстройки върху уеб сървисез, не ги прави част от стандарта.
Когато ми покажеш къде ги пише в стандарта, тогава ще призная, че се поддържат.
Ясно е, че в/у web services могат да се напишат както сесии, така и транзакции. И върху IP може да се напишат протоколи които поддържат състояние (пример TCP), но това не прави IP по-малко stateless.
Това, че Майкрософт са написали някакви надстройки върху уеб сървисез, не ги прави част от стандарта.
Когато ми покажеш къде ги пише в стандарта, тогава ще призная, че се поддържат.
Ясно е, че в/у web services могат да се напишат както сесии, така и транзакции. И върху IP може да се напишат протоколи които поддържат състояние (пример TCP), но това не прави IP по-малко stateless.
Re: CORBA vs. Web Services
Доста подробна дискусия се получи и доста неща бяха засегнати което е добре.
Лично съм ползвал SOAP (1.0) в проект където трябваше да се комуникира с около 40 различни компютърни системи (на търговски партнъори на фирмата клиент). Досегашните връзки бяха реализирани като различни вариации на тема EDI (или на тема какво дадения програмист си е мислел че EDI е). Вървяха по наети линии. Целта беше да се направи целия интерфейс на WSDL/SOAP и всички клиенти да се свързват по този начин.
Направихме ги ние веб сървисите (на COM/ASP платформа, че клиента не щеше .НЕТ), имплементнахме няколко клиента за тях - прости програмки пращащи и получаващи данни на Java (1.2 с апашки библиотеки за сапун), .NET и старовремски виндовс - това искаха другите 40 фирми. Беше много лесно и просто, дебъгването беше много лесно защото е текст, колегите в другите фирми се справиха бързо и безпроблемно. За сигурност ползвахме SSL и очевидно работеше и с МС и с Java на клиента доста добре. Транзакции в явен вид нямаше - всички операции бяха атомарни и сами за себе си. Изобщо всичко тип топ, лесно, без проблеми.
Мисля че на доста места в обсъждането прозираше мнението че МС са едва ли не единствените които бутат сапуна да се продава. Това далеч не е така. MS и IBM бяха тези които започнаха, но към тях се включиха Sun, Oracle, SAP и кой ли не. Така че всички са 'за' сапуна.
Нещо за което не видях да се говори е броят на обръщенията които се правят. Не познавам CORBA и не мога да кажа за нея как точно стоят нещата, но за DCOM знам че за всяко малко извикване се правят много, много повиквания - дърдорят си системите за разни клас факторита, обекти, интерфейси и т.н. Което е до голяма степен следствие от това че DCOM е просто COM over RPC. Използването на properties вместо параметри на функции никак не опростява нещата.
Та дори и да прехвърлим DCOM върху HTTP да може да надскача проксита (то си има DCOM over HTTP, не съм го пробвал де), ще стане много бавно защото многото извиквания в една локална мрежа може и да са ОК, но в интернет с да кажем 200 мс закъснение не са. Затова в Интернет SOAP е по-добър от DCOM въпреки допълнителното натоварване от XML и обработката на текст.
Въпросът ми е следния - как се решава този проблем в CORBA? Предполагам след като това е протокол който е предназначен изначално за ползване в мрежи, създателите са помислили за това. Имат ли SOAP или XML RPC или просто тъпа проста HTTP заявка предимство пред CORBA в мрежа с относително висока латентност по този параграф?
Hidden Treasures
Лично съм ползвал SOAP (1.0) в проект където трябваше да се комуникира с около 40 различни компютърни системи (на търговски партнъори на фирмата клиент). Досегашните връзки бяха реализирани като различни вариации на тема EDI (или на тема какво дадения програмист си е мислел че EDI е). Вървяха по наети линии. Целта беше да се направи целия интерфейс на WSDL/SOAP и всички клиенти да се свързват по този начин.
Направихме ги ние веб сървисите (на COM/ASP платформа, че клиента не щеше .НЕТ), имплементнахме няколко клиента за тях - прости програмки пращащи и получаващи данни на Java (1.2 с апашки библиотеки за сапун), .NET и старовремски виндовс - това искаха другите 40 фирми. Беше много лесно и просто, дебъгването беше много лесно защото е текст, колегите в другите фирми се справиха бързо и безпроблемно. За сигурност ползвахме SSL и очевидно работеше и с МС и с Java на клиента доста добре. Транзакции в явен вид нямаше - всички операции бяха атомарни и сами за себе си. Изобщо всичко тип топ, лесно, без проблеми.
Мисля че на доста места в обсъждането прозираше мнението че МС са едва ли не единствените които бутат сапуна да се продава. Това далеч не е така. MS и IBM бяха тези които започнаха, но към тях се включиха Sun, Oracle, SAP и кой ли не. Така че всички са 'за' сапуна.
Нещо за което не видях да се говори е броят на обръщенията които се правят. Не познавам CORBA и не мога да кажа за нея как точно стоят нещата, но за DCOM знам че за всяко малко извикване се правят много, много повиквания - дърдорят си системите за разни клас факторита, обекти, интерфейси и т.н. Което е до голяма степен следствие от това че DCOM е просто COM over RPC. Използването на properties вместо параметри на функции никак не опростява нещата.
Та дори и да прехвърлим DCOM върху HTTP да може да надскача проксита (то си има DCOM over HTTP, не съм го пробвал де), ще стане много бавно защото многото извиквания в една локална мрежа може и да са ОК, но в интернет с да кажем 200 мс закъснение не са. Затова в Интернет SOAP е по-добър от DCOM въпреки допълнителното натоварване от XML и обработката на текст.
Въпросът ми е следния - как се решава този проблем в CORBA? Предполагам след като това е протокол който е предназначен изначално за ползване в мрежи, създателите са помислили за това. Имат ли SOAP или XML RPC или просто тъпа проста HTTP заявка предимство пред CORBA в мрежа с относително висока латентност по този параграф?
Hidden Treasures
Re: CORBA vs. Web Services
>>_къде_ точно в стандарта за SOAP се дефинира как се поддържат >>транзакции и сесии
СОАП е акроним от Simple Object Access Protocol - и именно това му е целта - единствено и само да предостави канал за комуникация (аксес) до ремоут обект - като комуникацията става чрез incoming (request) и outgoing (response) XML Messages още известни като SOAP Envelopes. "Стандарта СОАП" както ти го наричаш няма нищо общо със транзакции.
Специално аз никога не съм работил с транзакции въобще, но е напълно логично всяка среда да си ги имплменентира чрез своя си софтуер - Майкрософтската среда със МТС, АйБиЕм - чрез техния си транзакшън сървър и прочие. Това клиента (subscriber) на дадената Уеб Услуга въобще не го интересува - интересува го само че може да участва в транзакция и това е напълно достатъчно. Именно в това се получава красотата - правиш си сървъра с каквата технология на теб ти е удобна, имплементираш логика за транзакции и сесии спрямо плафтормата която си избрал ако е необходимо, а клиента може да е всичко - дори и Джаваскрипт - като комуникацията е със напълно разбираеми и лесни за дебъгване ЕксЕмЕл меседжи и сървъра напълно ясен какво предоставя като услуги чрез WSDL-а, който expose-ва.
СОАП е акроним от Simple Object Access Protocol - и именно това му е целта - единствено и само да предостави канал за комуникация (аксес) до ремоут обект - като комуникацията става чрез incoming (request) и outgoing (response) XML Messages още известни като SOAP Envelopes. "Стандарта СОАП" както ти го наричаш няма нищо общо със транзакции.
Специално аз никога не съм работил с транзакции въобще, но е напълно логично всяка среда да си ги имплменентира чрез своя си софтуер - Майкрософтската среда със МТС, АйБиЕм - чрез техния си транзакшън сървър и прочие. Това клиента (subscriber) на дадената Уеб Услуга въобще не го интересува - интересува го само че може да участва в транзакция и това е напълно достатъчно. Именно в това се получава красотата - правиш си сървъра с каквата технология на теб ти е удобна, имплементираш логика за транзакции и сесии спрямо плафтормата която си избрал ако е необходимо, а клиента може да е всичко - дори и Джаваскрипт - като комуникацията е със напълно разбираеми и лесни за дебъгване ЕксЕмЕл меседжи и сървъра напълно ясен какво предоставя като услуги чрез WSDL-а, който expose-ва.
Re: CORBA vs. Web Services
> и именно това му е целта - единствено и само да предостави канал
> за комуникация (аксес) до ремоут обект
Това го прави достатъчно добре. Ама нали мисълта е че трябва и транзакции да се поддържат. Примерно аз съм банка ползваща МС сървъри (има такива, примерно bank one) а ти си банка ползваща джавска история от IBM. Искам да ти преведа малко парички и то през сапуна. Как ще стане? Отговора в края на 2003 година е - никак. И това което казваше гореспоменатата статия е, че отговора и в края 2004 ще е никак, че може и в края на 2005 ....
> Специално аз никога не съм работил с транзакции въобще, но е напълно
> логично всяка среда да си ги имплменентира чрез своя си софтуер -
> Майкрософтската среда със МТС, АйБиЕм - чрез техния си транзакшън сървър
> и прочие. Това клиента (subscriber) на дадената Уеб Услуга въобще не
> го интересува - интересува го само че може да участва в транзакция и това
> е напълно достатъчно.
Ъъъъъ и как правиш двоен commit като клиента не разбира от транзакции?
Hidden Treasures
> за комуникация (аксес) до ремоут обект
Това го прави достатъчно добре. Ама нали мисълта е че трябва и транзакции да се поддържат. Примерно аз съм банка ползваща МС сървъри (има такива, примерно bank one) а ти си банка ползваща джавска история от IBM. Искам да ти преведа малко парички и то през сапуна. Как ще стане? Отговора в края на 2003 година е - никак. И това което казваше гореспоменатата статия е, че отговора и в края 2004 ще е никак, че може и в края на 2005 ....
> Специално аз никога не съм работил с транзакции въобще, но е напълно
> логично всяка среда да си ги имплменентира чрез своя си софтуер -
> Майкрософтската среда със МТС, АйБиЕм - чрез техния си транзакшън сървър
> и прочие. Това клиента (subscriber) на дадената Уеб Услуга въобще не
> го интересува - интересува го само че може да участва в транзакция и това
> е напълно достатъчно.
Ъъъъъ и как правиш двоен commit като клиента не разбира от транзакции?
Hidden Treasures
Re: CORBA vs. Web Services
Защо да няма транзакции клиента?
Примерно, в жавешкия клиентски код в транзакция пращам СОАП заявка за плащане към уеб-сървиса на банк-уан. Те го обработват (също в транзакция) и ако всичко е точно ми пращат ОК СОАП отговор. Ако има грешка пращат отговор с грешката. Клиентския код commit-ва транзакцията само ако е получил ОК. Ако е получил грешка или не е получил никакъв отговор поради проблеми с връзката, ролбаква транзакцията.
Moже и да пропускам нещо, но си мисля че подобен сценарий не е толкова невъзможен.
Примерно, в жавешкия клиентски код в транзакция пращам СОАП заявка за плащане към уеб-сървиса на банк-уан. Те го обработват (също в транзакция) и ако всичко е точно ми пращат ОК СОАП отговор. Ако има грешка пращат отговор с грешката. Клиентския код commit-ва транзакцията само ако е получил ОК. Ако е получил грешка или не е получил никакъв отговор поради проблеми с връзката, ролбаква транзакцията.
Moже и да пропускам нещо, но си мисля че подобен сценарий не е толкова невъзможен.
Re: CORBA vs. Web Services
> Стандарта СОАП" както ти го наричаш няма нищо общо със транзакции.
Именно затова казвам, че web services (както са дефинирани в стандартите), не могат да се сравняват с CORBA. CORBA дефинира и stateful обекти, и транзакции и още много услуги. В стандарта.
> Това клиента (subscriber) на дадената Уеб Услуга въобще не го интересува -
> интересува го само че може да участва в транзакция и това е напълно достатъчно.
Как участва в транзакция? Как прави commit или rollback? Кой се грижи сървисите X от сайта ala.com и Y от сайта bala.com (използвани от клиента в една транзакция) да направят commit или rollback? А services които ползват други services?
Личи си, че никога не си работил с транзакции :) Просто не се излагай да пишеш за неща които не разбираш :)
Пак питам -- в коя спецификация на webservices са дефинирани транзакции и състояние на service?
Именно затова казвам, че web services (както са дефинирани в стандартите), не могат да се сравняват с CORBA. CORBA дефинира и stateful обекти, и транзакции и още много услуги. В стандарта.
> Това клиента (subscriber) на дадената Уеб Услуга въобще не го интересува -
> интересува го само че може да участва в транзакция и това е напълно достатъчно.
Как участва в транзакция? Как прави commit или rollback? Кой се грижи сървисите X от сайта ala.com и Y от сайта bala.com (използвани от клиента в една транзакция) да направят commit или rollback? А services които ползват други services?
Личи си, че никога не си работил с транзакции :) Просто не се излагай да пишеш за неща които не разбираш :)
Пак питам -- в коя спецификация на webservices са дефинирани транзакции и състояние на service?
Re: CORBA vs. Web Services
> Примерно, в жавешкия клиентски код в транзакция пращам СОАП заявка
> за плащане към уеб-сървиса на банк-уан. Те го обработват (също в
> транзакция) и ако всичко е точно ми пращат ОК СОАП отговор. Ако има
> грешка пращат отговор с грешката. Клиентския код commit-ва
> транзакцията само ако е получил ОК. Ако е получил грешка или не е
> получил никакъв отговор поради проблеми с връзката, ролбаква транзакцията.
Значи нещата са малко по-сложни. В сценария който описваш могат да се случат такива неща, че единия участник в разпределената транзакция да си мисли че тя е успяла, а връзката да се разпадне и другия да си мисли че се е провалила ... много неща могат да станат.
Хубавата новина е че хората са го измислили. Извън рамките на темата е, но единствения сигурен начин да правиш разпределени транзакции е т.нар. two-phase commit който се прави на две стъпки. Примерно при релационните БД за това отговаря XA протокола.
За да се реализира two-phase commit е необходимо всички участници в транзакцията да го поддържат. Примерно COM+ с ADO и подходяща БД (SQL Server, Oracle) и друга система на среща която може да работи с техния transaction coordinator го поддържат.
В сървърите за интеграция (WebMethods, BizTalk) има и понятието за long running transaction което може да е подходящия начин да се реализират транзакции в SOAP (нали може и по SMTP да се предава). Обаче пак трябва и двата участника да разбират за какъв механизъм за транзакции са се разбрали.
Hidden Treasures
> за плащане към уеб-сървиса на банк-уан. Те го обработват (също в
> транзакция) и ако всичко е точно ми пращат ОК СОАП отговор. Ако има
> грешка пращат отговор с грешката. Клиентския код commit-ва
> транзакцията само ако е получил ОК. Ако е получил грешка или не е
> получил никакъв отговор поради проблеми с връзката, ролбаква транзакцията.
Значи нещата са малко по-сложни. В сценария който описваш могат да се случат такива неща, че единия участник в разпределената транзакция да си мисли че тя е успяла, а връзката да се разпадне и другия да си мисли че се е провалила ... много неща могат да станат.
Хубавата новина е че хората са го измислили. Извън рамките на темата е, но единствения сигурен начин да правиш разпределени транзакции е т.нар. two-phase commit който се прави на две стъпки. Примерно при релационните БД за това отговаря XA протокола.
За да се реализира two-phase commit е необходимо всички участници в транзакцията да го поддържат. Примерно COM+ с ADO и подходяща БД (SQL Server, Oracle) и друга система на среща която може да работи с техния transaction coordinator го поддържат.
В сървърите за интеграция (WebMethods, BizTalk) има и понятието за long running transaction което може да е подходящия начин да се реализират транзакции в SOAP (нали може и по SMTP да се предава). Обаче пак трябва и двата участника да разбират за какъв механизъм за транзакции са се разбрали.
Hidden Treasures
Re: CORBA vs. Web Services
>> Стандарта СОАП" както ти го наричаш няма нищо общо със транзакции.
> Именно затова казвам, че web services (както са дефинирани в стандартите),
> не могат да се сравняват с CORBA. CORBA дефинира и stateful обекти,
> и транзакции и още много услуги. В стандарта.
Може би точно това в крайна сметка ще го направи успешен. Защото дефинира малка област, но просто и ясно и се реализира лесно. Примерно ако трябва да пишеш поддръжка на SOAP в Perl (TCL, Python, C++, Лого, EzikaKoitoSiIzmislihMinalotoLiatoZnaeshKoi --) ти отнема относително малко време - хем е текст (да, XML е текст ... то затова вече за парсване на RSS НЕ може да се ползва XML парсер ако искаш да прочетеш повече от половината източници. Ама аре, това е друга болна тема), хем малко функционалност (никакви транзакции бамзакции).
Виж какво стана с X11. Вярно че върши само половината работа, ама всички го приемат. Вярно, после се води спор какъв прозоречен мениджър е по-добър и на всички им е кофти че стандарт в крайна сметка няма, но X11 си е там. Или историята с единия Юникс който поради някаква си причина стана на много. Или историята с единия HTML който имаше различни DHTML-и. И т.н. музика без край.
Hidden Treasures
> Именно затова казвам, че web services (както са дефинирани в стандартите),
> не могат да се сравняват с CORBA. CORBA дефинира и stateful обекти,
> и транзакции и още много услуги. В стандарта.
Може би точно това в крайна сметка ще го направи успешен. Защото дефинира малка област, но просто и ясно и се реализира лесно. Примерно ако трябва да пишеш поддръжка на SOAP в Perl (TCL, Python, C++, Лого, EzikaKoitoSiIzmislihMinalotoLiatoZnaeshKoi --) ти отнема относително малко време - хем е текст (да, XML е текст ... то затова вече за парсване на RSS НЕ може да се ползва XML парсер ако искаш да прочетеш повече от половината източници. Ама аре, това е друга болна тема), хем малко функционалност (никакви транзакции бамзакции).
Виж какво стана с X11. Вярно че върши само половината работа, ама всички го приемат. Вярно, после се води спор какъв прозоречен мениджър е по-добър и на всички им е кофти че стандарт в крайна сметка няма, но X11 си е там. Или историята с единия Юникс който поради някаква си причина стана на много. Или историята с единия HTML който имаше различни DHTML-и. И т.н. музика без край.
Hidden Treasures
Re: CORBA vs. Web Services
А, хайде де приятелю, включи се в диалога :) Добрите идеи идват от комуникацията.
Очевидно щом съм го пропуснал този момент, значи определено имам нужда от идеи. Действително нямам представа как ефективно се commit-ва транзакция едновременно на клиента и сървъра, като банкови транзакции са чудесен пример. Хмм, даже не съм и сигурен, че транзакциите могат да бъдат едновременно двупосочни. Питах неуспешно Гуугъл един два пъти по темата, навярно не знам какви точно думички да търся.
Ако имаш идея, ще съм ти благодарен да я споделиш. Реторични въпроси от "какво става ако това", "какво става ако онова" не помагат!
Очевидно щом съм го пропуснал този момент, значи определено имам нужда от идеи. Действително нямам представа как ефективно се commit-ва транзакция едновременно на клиента и сървъра, като банкови транзакции са чудесен пример. Хмм, даже не съм и сигурен, че транзакциите могат да бъдат едновременно двупосочни. Питах неуспешно Гуугъл един два пъти по темата, навярно не знам какви точно думички да търся.
Ако имаш идея, ще съм ти благодарен да я споделиш. Реторични въпроси от "какво става ако това", "какво става ако онова" не помагат!
Re: CORBA vs. Web Services
С тебе си разменяме едни и същи писания. "Ти не разбираш от транзакции" не е обективен довод за налагане на теза.
Продължаваш да смесваш СОАП и Уеб Сървисес. СОАП е просто транспортния протокол на Уеб Сървисес. Оттам нататъка търси транзакциите. Има транзакции за Уеб Сървисес! Сега не знам какво разбираш под "стандарт" (имаше тема наскоро за стандартите и там си казах мнението), но примерно погледни този линк (нарочно се старах да не давам Майкрософтски линк, че на някои хора им се подуват хемороидите като чуят Майкрософт)
[линк]
Там има доста подробно описано как да се подхожда към транзакции през Уеб Сървиси без значение от фреймуърка на който са деплойнати, като иментата на компаниите които стоят зад този документ (стандарт ?) са АйБиЕм, Беа и Майкрософт. Сега може Пешо от Казичене да не е съгласен с този "документ" и това да не го прави световен признат от всички стандарт, но тука вече стигаме до субективния спор какво е "стандарт".
Продължаваш да смесваш СОАП и Уеб Сървисес. СОАП е просто транспортния протокол на Уеб Сървисес. Оттам нататъка търси транзакциите. Има транзакции за Уеб Сървисес! Сега не знам какво разбираш под "стандарт" (имаше тема наскоро за стандартите и там си казах мнението), но примерно погледни този линк (нарочно се старах да не давам Майкрософтски линк, че на някои хора им се подуват хемороидите като чуят Майкрософт)
[линк]
Там има доста подробно описано как да се подхожда към транзакции през Уеб Сървиси без значение от фреймуърка на който са деплойнати, като иментата на компаниите които стоят зад този документ (стандарт ?) са АйБиЕм, Беа и Майкрософт. Сега може Пешо от Казичене да не е съгласен с този "документ" и това да не го прави световен признат от всички стандарт, но тука вече стигаме до субективния спор какво е "стандарт".