От: | mihailik | ||
Дата: | 06.10.04 12:27 | ||
Оценка: |
Indigo connects software together using structural contracts (a.k.a. schemas) and behavioral contracts (a.k.a. message exchange patterns).
We integrate with the CLR and COM and eviscerate your local types into either data contracts or service contracts, but never both. An especially cool feature of Indigo is that the sender and receiver don't need to share the same CLR types (nor do both sides even need to be Indigo or CLR or COM).
The messages we use in Indigo are based on the SOAP processing/data model but don't use angle brackets unless we are forced to, and when forced to, we do it happily and pretty damn fast.
Oh yeah, and we integrate tightly with System.Transactions and a queueing system.We support a variety of message transports and support both transport-level and SOAP-level security and reliability.
[q]
Для безопасности и надёжности поддерживаются и сервисы транспортного уровня и средства SOAP.
От: | Курилка | http://kirya.narod.ru/ | |
Дата: | 06.10.04 12:32 | ||
Оценка: | 30 (1) |
M>The messages we use in Indigo are based on the SOAP processing/data model but don't use angle brackets unless we are forced to, and when forced to, we do it happily and pretty damn fast.
От: | mihailik | ||
Дата: | 06.10.04 16:06 | ||
Оценка: |
От: | VladD2 | www.nemerle.org | |
Дата: | 06.10.04 19:57 | ||
Оценка: |
Ххх — это все, все, все, ...
От: | Sinclair | https://github.com/evilguest/ | |
Дата: | 07.10.04 03:09 | ||
Оценка: | 53 (3) |
M>Индиго основывается на сообщениях SOAP и на модели SOAP, но навязывает разработчку угловые скобки (то есть, знание XML). Впрочем, доступ к XML не закрыт и несложен.M>The messages we use in Indigo are based on the SOAP processing/data model but don't use angle brackets unless we are forced to, and when forced to, we do it happily and pretty damn fast.
Сообщения, которые мы используем в Индиго, основаны на модели данных и обработки SOAP, но мы не пользуемся угловыми скобками, пока нас не вынудят, и если уж вынудят, то мы делаем это охотно и чертовски быстро.
От: | mihailik | ||
Дата: | 12.10.04 10:09 | ||
Оценка: |
От: | Sinclair | https://github.com/evilguest/ | |
Дата: | 12.10.04 10:46 | ||
Оценка: | 69 (7) +1 |
Сегодня некто озадачил меня объяснить Индиго в пять минут.
Приступим.
Индиго соединяет приложения при помощи структурных контрактов (схем) и поведенческих контрактов (сценаривев обмена сообщениями).
Мы интегрируемся с CLR и COM, и разделываем ваши локальные типы на контракты либо данных либо сервисов. Особенно крутая фишка Индиго в том, что получатель и отправитель не обязаны использовать одинаковые CLR типы (и даже использовать на обоих концах Индиго или CLR или COM).
Сообщения, которые мы используем в Индиго, основаны на модели данных и обработки SOAP, но мы не пользуемся угловыми скобками, пока нас не вынудят, и если уж вынудят, то мы делаем это охотно и чертовски быстро.
Mы поддерживаем множество транспортов сообщений и поддерживаем безопасность и надежность как на транспортном уровне, так и на уровне SOAP.
Aх да, и еще мы тесно интегрируемся с System.Transactions и очередями сообщений.
Вот. Это заняло у меня меньше пяти минут, а печатаю я намного медленнее, чем говорю.
Возможно я избалован, но я скептически отношусь к технологиям, основные концепции которых невозможно четко выразить быстрее чем за пять минут.
От: | VladD2 | www.nemerle.org | |
Дата: | 12.10.04 22:53 | ||
Оценка: | 79 (5) +1 |
История программных революций от Microsoft, вкратце: Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!
Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через браузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java — её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.
Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс- релизов. Главное, что нужно очень четко понимать — .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.