 |
Технология Клиент-Сервер 1999'4
|
|
|
Component Object Model vs. Enterprise JavaBeans
Спор о превосходстве той или иной
технологии в компьютерном мире вечен.
Меняются технологии, меняются платформы,
спорщики тоже меняются, но спор не затихает.
Сейчас спорят о UNIX и NT, OpenGL и Direct3D, COM/DCOM и CORBA.
Интересно, что одной из сторон неизменно
служит Microsoft, тогда как оппоненты меняются.
Итак, Microsoft спорит практически со всем
остальным компьютерным миром, спорит давно
и очень успешно, судя хотя бы по
безвременной кончине большинства
вступавших в этот спор.
В той сфере, которая наиболее для
нас интересна, кроме очевидной конкуренции
SQL-серверов существует и противостояние
технологий, и, пожалуй, наиболее характерно
противопоставление Microsoft COM (Component Object Model) и
Enterprise JavaBeans от Sun. К счастью, в данном случае
оппоненты находятся в сходных весовых
категориях, и ни одному из них не удастся
решить спор нокаутом. В принципе, оба CORBA-совместимы,
так что можно считать, что речь идет о
борьбе религиозных течений внутри одной
конфессии. Хотя CORBA и дожила до третьей
версии, она не перестала быть тем, чем была с
самого начала - некой спецификацией,
соответствие с которой необходимо
декларировать, но трактовать ее можно по-разному.
Эта-то разница в трактовках и приводит к
появлению CORBA-реализаций, совместимых, как
гений и злодейство.
COM, как это говорит Microsoft, и как
вытекает из его названия, предназначен для
построения многократно используемых
компонентов. В сущности, речь идет о
платформно-независимом клиенте, общающемся
с сервером, также независимым от платформы,
через посредника типа MTS - Microsoft Transaction Server.
Разработчик оказывается свободен в выборе
платформы, языка, но зависим от Microsoft в
выборе middleware.
Enterprise JavaBeans [EJB] - архитектура
построения распределенных платформно-независимых
серверных приложений, которым, в целом,
безразлично, где и с кем работать - по
заверениям Sun. Однако слово Java в названии
технологии достаточно прозрачно указывает
на Sun. Sun именует себя "the steward of the Java platform",
где слово steward означает отнюдь не "стюард",
как можно преположить по созвучию, но "управляющий"
или "распорядитель". Таким образом,
зависимость от фирмы-разработчика остается,
хотя и в другом контексте. Sun считает, что
разработчиков, использующих Enterprise JavaBeans, на
30% больше, чем приверженцев других
технологий.
На конференции SIGS в San Jose журналу
Infoworld удалось свести лицом к лицу Майкла
Гросса (Michael Gross), отвечающего в Microsoft за
направление COM, и Билла Рота (Bill Roth),
отвечающего в Sun за Enterprise Java. Несмотря на то,
что случилось это довольно давно, их спор по-прежнему
интересен, так как позволяет оценить
позиции сторон. Большинство высказанных
идей и положений не утратили актуальности и
сейчас.
InfoWorld: Вспоминая, что это Java-конференция,
дадим слово Microsoft - почему Java-разработчики
могут быть заинтересованы в COM?
Gross: Мы предполагаем, что COM будут
использовать для построения многократно используемых и встраиваемых в приложения
компонентов. Чтобы упростить повторное использование, Microsoft создал
технологию под названием MTS - Microsoft Transaction Server. MTS предоставляет
COM-компонентам сервисы для построения масштабируемых распределенных приложений.
MTS предоставляет этим компонентам всевозможные сервисы, вещи, о которых
разработчики обычно должны заботиться сами - например, объединение подключений к
базам данных. Известно, что когда вы стоите масштабируемое приложение,
подключения к БД создают массу проблем для масштабируемости и
производительности. Поэтому мы и ввели в MTS средства, упрощающие объединение
подключений к БД. Как следует из названия, MTS имеет транзакционную семантику,
поскольку стоит начать всерьез работать с приложениями класса предприятия, как
транзакции приобретают поистине очень большое значение. Поэтому в MTS
предусмотрены автоматические службы транзакций, дающие возможность производить
транзакции на различных платформах с компонентами, работающими в разных местах.
Если компонентная часть транзакции закончится неудачей, имеется возможность
откатить все назад. MTS – это микрософтовский контейнер для этих
компонентов.
InfoWorld: Билл, как вы опишете
Enterprise JavaBeans?
Roth: Модель Enterprise JavaBeans
[EJB] - это архитектура построения распределенных серверных приложений,
исполняемых где угодно, на любом сервере или middleware.Это архитектура,
привносящая в серверные приложения вычисления на базе компонентов. Это позволяет
разработчикам сосредоточиться на создании бизнес-логики, не вдаваясь в детали,
обычно ассоциирующиеся с построением приложений масштаба предприятия. По
расчетам, производительность разработчиков, использующих Enterprise JavaBeans,
на 30% выше, чем при использовании других технологий. Более 30 компаний объявили
о поддержке этой архитектуры, и по крайней мере 4 продукта класса предприятия
уже готовы, а еще 15 выходят вскоре. Я верю, что к концу года на рынке будет не
менее 10 таких продуктов.
Одна из причин успеха состоит в
том, что EJB был создан, чтобы охватить
существующие корпоративные системы. Другая
причина состоит в том, что EJB дают огромное
количество декларативных опций и
предоставляют возможности обеспечения
безопасности транзакций, что упрощает
разработку EJB-компонентов. Еще - она
предлагает богатую объектную модель,
содержащую не только statefull и изменяемые
stateless-объекты, но и интересную модель
персистентных объектов. И еще одна причина
успеха - мы получили поддержку от широкой
общественности. Sun, как распорядитель
платформы Java, разрабатывала эту технологию
с участием своих партнеров.
Так что я бы провел различие
между двумя технологиями следующим образом.
Компонентная модель Enterprise JavaBeans - это
архитектура построения распределенных
серверных приложений, исполняемых где
угодно. Технология Microsoft- это продукт.
Технология Enterprise JavaBeans фокусируется на
работе с существующими корпоративными
системами и предоставлении преимуществ
платформы Java на сервере. Так что, я считаю,
что продукт моего коллеги будет прекрасной
платформой для использования в качестве
сервера Enterprise JavaBeans. И, хотите-верьте, хотите
- нет, я бы приветствовал его вступление на
рынок серверов Enterprise JavaBeans.
InfoWorld: Что ж, это похоже на
оливковую ветвь мира. Как насчет мировой, Майкл, может, имеется некая стратегия,
которая позволит идти дальше вместе?
Gross: Что ж, я скажу, что он
абсолютно прав в том смысле, что у нас
действительно есть продукт, поставляемый
уже несколько лет. И здесь есть то, о чем
нельзя не упомянуть. Говоря о EJB, вы говорите
об архитектуре и о спецификации. Как люди
собираются воплощать эту спецификацию - все
еще предмет для споров. С нашей точки зрения,
со всем уважением к данной спецификации, но
при условии отсутствия эталонной
реализации (сейчас уже имеется эталонная
реализация –прим.ред.)
и отсутствия каких-либо тестов, трудно точно сказать, что же означает
EJB-совместимость. Сейчас существуют EJB-совместимые продукты, но они
поставлялись до выхода окончательной спецификации. Действительно ли они
EJB-совместимы? Трудно ответить.
Я говорю ‘то в том смыслt, что все
это очень напоминает CORBA, где существует
масса CORBA-совместимых продуктов. Но не все
из них равны по функциональности. Они не
могут работать вместе. Нам кажется, что это
же может случиться и с EJB. Microsoft очень хотел,
говоря о CORBA, взаимодействовать и
обеспечивать взаимодействие с CORBA, но при
более подробном рассмотрении оказалось,
что существует масса разных разновидностей,
и какую из них мы должны выбрать для
обеспечения взаимодействия - понять
невозможно. Я предчувствую, что так же будет
и с EJB. И еще есть много служб, типа
безопасности и прочих вещей, которые по-прежнему
не специфицированы и могут по-разному
реализовываться на местах. Мы же поставляем
нечто, на чем можно построить решение прямо
сейчас. А EJB - просто красивая спецификация.
InfoWorld: Итак, Билл, давайте
убедимся, что я верно понял Майкла. В общем, у вас имеется неполная спецификация
EJB, совместная работа сомнительна, и вообще, в этом всем есть что-то от
vaporware?
Roth: Ну, во-первых, я считаю, что
спецификация достаточно полна, чтобы позволить 4 поставщикам сегодня и множеству
других - в будущем, создавать продукты. Мы ежедневно работаем над выяснением
пожеланий пользователей в аспектах совместимости и взаимодействия. Разумеется,
мы еще на пути к совершенству. Это часть эволюционного процесса. Я думаю, что
если оглянуться, то нашей технологии всего-то семь месяцев. У нас есть 4
реализации масштаба предприятия и по крайней мере 30 компаний, обязавшихся
создать весьма значимые продукты в этой технологии.
Теперь, к вопросу о том, что мы
идем в ту же яму, что и CORBA, должен сказать
следующее. Мы, безусловно, уважаем работу OMG
[Object Management Group]. Это прекрасные партнеры и мы
весьма обязаны CORBA. Но мы очень серьезно
относимся к нашей роли хозяев Java-платформы.
Мы владеем платформой, мы направляем
процесс. И в будущем, в отличие от OMG,
прекрасной демократической организации,
собираемся направлять эту технологию и
отвечать за окончательные решения.
InfoWorld: Вы можете возразить,
что Microsoft так же направляет свою компонентную модель и так же отвечает за ее
реализацию. Но множество людей чувствует дискомфорт оттого, что Microsoft
контролирует интерфейсы и явлется главным игроком, почему же COM должен быть
настолько NT-центричной моделью в современном многоплатформном мире?
Gross: COM вовсе не NT-центричная
модель. Взаимодействие - одна из ключевых идей, стоящих за COM и MTS. При
запуске компонента MTS, вы получаете возможность работы с любой внешней базой
данных. В дополнение, имеется транзакционное взаимодействие, где вы можете
использовать координатор транзакций совместно с другими координаторами на других
платформах, такими, как CICS или Encina. Имеется и COM-for-Unix, достаточно
большой и сильный уже сейчас. Мы поставляем и COM для Solaris. COM для OpenVMS и
COM для Digital Unix сейчас поставляются Digital. О поставке COM для своих
платформ объявили SGI и Siemens.
Есть возможность взаимодействия
MTS и IBM Message Queuing, с использованием так
называемого Level-8 Bridge, моста MQSeries от Microsoft.
Так что с нашей стороны, то, что мы делаем с
COM и MTS вовсе не выглядит NT-центрично. Мы как
раз работаем с самыми различными
платформами благодаря выдающимся
возможностям взаимодействия, и строим
распределенные приложения в очень
разнородных средах. Попробуйте найти
систему с большими, чем у NT, возможностями
взаимодействия с другими. Мы, в той или иной
форме, работаем почти слюбой платформой.
InfoWorld: Просто для ясности,
сейчас есть COM, а в NT 5.0 будет COM+. Покажет ли COM+ тот же уровень
производительности на других платформах?
Gross: Сегодня COM+ специфицирован и
создается для NT. Мы рассматриваем различные возможности, но пока не делали
каких-либо заявлений.
InfoWorld: Так что не будет
невероятным увидеть функциональность MTS на сервере Siemens Unix?
Gross: Нет ничего невероятного. Но уже
сейчас, даже если мы не пойдем этим путем, доступная функциональность - в смысле
взаимодействия для построения истинно распределенных приложений - поистине
грандиозна.
InfoWorld: Возвращаясь к EJB, в
сообществе разработчиков есть масса нареканий на производительность Java. На что
можно рассчитывать?
Roth: Недавно я видел приложения,
работающие на одной системе с 2,500 пользователей. Но на самом деле преимущество
Enterprise JavaBeans, в отношении масштабируемости и производительности, в
возможности взять ваше приложение и перенести его на более производительный
сервер. Это относится к масштабируемости промежуточного сервера, который
представляется весьма мощным. Вы хорошо знаете о тех усилиях, что мы
прикладываем для повышения производительности платформы Java. Работа над
оптимизацией, как и наша новая технология компиляции HotSpot.Повышение
производительности – одна из важнейших задач, которой мы будем и дальше
заниматься на платформе Java.
InfoWorld: В корпоративной среде
поставщики ERP-решений [enterprise resource planning, планирование ресурсов
предприятия] направляют очень многие решения. Но оставляя в стороне Oracle, мы
не видим заявлений о поддержке EJB со стороны PeopleSoft, Baan или SAP. Но все
они издают правильные звуки насчет COM. Каковы причины этого, и рассчитываете ли
вы на какие-то изменения в ближайшем будущем?
Roth: У нас есть несколько целей. Мы
рассчитываем на клиентуру среди поставщиков корпоративных систем. Мы должны
привлечь поставщиков средств разработки. Мы должны привлечь разработчиков
компонентов и системных интеграторов. Этот рынок будет расти. Насколько мне
известно, MTS существует уже два с половиной года. Я думаю, что мы достигнем
такого же положения за половину этого срока. Мы работаем над популяризацией
наших усилий, и уже начинаем видеть плоды этого.
InfoWorld: Что вы думаете об этом,
Майкл?
Gross: Несколько замечаний. Вы
говорили о переносе приложений с одной платформы на другую, и о том, что все
станет очень масштабируемым. Это все очень хорошо, но основано на предположении,
что люди не станут использовать специализированных контейнеров. Из того, что мы
слышали, следует, что специализированные контейнеры очень интересны людям как
средство использования достоинств той или иной платформы. Но один набор сервисов
на любой платформе - основа основ Java. Мой опыт подсказывает, что люди будут
использовать специализированные контейнеры на любой платформе, чтобы
воспользоваться возможностями этой платформы.
Возможность переносить
приложения с одной платформы на другую - это
то, о чем стоит задуматься. Но в случае
приложений, масштабируемых до 2500
пользователей, реальность вовсе не похожа
на лабораторные испытания. Одна из вещей,
которую стоит осознать, это то, что с Microsoft
Transaction Server вы получаете очень тесно
интегрированное окружение служб и средств,
которыми могут воспользоваться
разработчики. И опять же, это то, что
доступно сегодня и будет только
расширяться в будущем.
Эти средства и службы упрощают
построение распределенных приложений. Для
EJB такого набора сейчас нет, и должно пройти
некое время до момента его появления. И, в
действительности, стоит задаться вопросом
о мотивации разработчиков средств
программирования. Какой спрос они
рассчитывают получить на отдельно взятой
платформе, чтобы взяться за разработку
средств создания EJB для этой платформы?
Честно говоря, я не вижу большого выбора
средств разработки -- нет ничего масштаба
средств для нашей платформы. И в смысле
компонентов, должен сказать, уже сейчас
есть огромный рынок COM-компонентов. Giga
вычислила, что только в этом году объем
продаж составит около 640 миллионов долларов.
InfoWorld: Почему это звучит так,
будто если Microsoft сказала: «танцуй, разработчик», разработчику придется
танцевать?
Gross: Это уж ваше дело,
разработчиков. Microsoft дает выбор – это один из наших продуктов. Для нас выбор
– это важно. Мы даем выбрать любой язык для создания компонентов MTS. Мы не
заставляем вас писать на каком-то одном языке. Есть люди, которые долгие годы
использовали Cobol, и хотят писать на нем COM-компоненты - и именно этим и
занимаются. Это вам не "Java world". Одно из больших преимуществ MTS -
возможность работы на любом языке. Вы могли слышать, что это возможно и с EJB,
если вы упакуете это как EJB. Однако я не думаю, что кто-то этим всерьез
занимается. Подумайте о производительности, вы собираетесь взять работающий
компонент, запихнуть в EJB, и ожидаете, что это будет работать и
масштабироваться хотя бы отдаленно похоже на работу просто компонента MTS?
InfoWorld: Билл, вы
ответите?
Roth: Мне есть что сказать о
специализированных контейнерах. Enterprise JavaBeans действительно позволяют
использовать специализированные контейнеры. И это действительно хорошая вещь.
Это позволяет людям использовать преимущества особенностей системы. Если вы
работаете с S/390 с векторным процессором, вы наверняка захотите использовать
этот векторный процессор.
Gross: Верно. Но тогда не говорите
"write once, run anywhere" в том же предложении, что и "специализированные
контейнеры".
Roth: Хорошо. Я сейчас скажу, что
позволяет нам сфокусироваться на гибкости. Вы теряете переносимость? Наверняка.
Вы получаете все преимущества используемой платформы? Обязательно. Говоряоб
интегрированных средствах разработки, есть вещи, которые Microsoft делает
хорошо. Было бы лицемерием сказать, что это не так. Но наша технология - это не
один поставщик с хорошим набором средств. Я гарантирую, что у вас будут наборы
средств разработки от различных поставщиков, так что разработчик получит
реальный выбор.
Gross: Некоторые из этих разработчиков
уже поставляют средства и для платформы Microsoft. Так что, говоря о выборе, не
только Microsoft поставляет средства разработки для нашей платформы. Существует
широчайший выбор средств самых разных поставщиков.
Roth: Но тем не менее, MTS - это один
продукт на одной платформе. С Enterprise Java Beans, у вас есть выбор из 4
платформ сейчас, будет 10 в декабре и около 30 через год. Этим все сказано о
выборе и о единой модели компонентов. И, кстати, о выборе средств разработки,
серверов, и планов на будущее.
InfoWorld: Обычно было так: вы
создаете приложение, зная, сколько пользователей будут его использовать. Но
теперь, с Internet и Web, у вас нет никакого представления об этом. Так, имеется
определенный скепсис по поводу архитектуры COM, ориентированной на подключение и
потому не масштабируемой. Так есть ли фундаментальная разница между
архитектурами COM и EJB в смысле масштабируемости?
Gross: Я могу сказать, что MTS
определенно создавался с расчетом на масштабируемость. Мы предоставляем самые
разные сервисы для масштабируемости. Один из наиболее важных сервисов, имеющихся
в MTS - это то, что мы называем активацией Just-In-Time. Это все к тому, что у
нас есть компоненты - когда они реально не используются, хотя и могут быть
вызваны клиентом - они удалены из памяти и лежат в сторонке. А когда они
понадобятся, мы их снова загрузим в память. Что это дает - если у вас тысячи
одновременно работающих с вашей системой пользователей, вам не потребуются тонны
системной памяти.
Есть и другие службы, которые
поддерживают масштабируемость. Мы даем
возможность объединения и совместного
использования потоков. Мы знаем, что это
очень дорогостоящий процесс, создание и
уничтожение потоков. MTS позволяет
использовать потоки совместно. Объединение
подключений к БД - это еще один аспект. Мы
знаем, что очень, очень часто в приложениях
узким местом является подключение к БД. Так
что мы прошли сквозь очень болезненный
процесс оптимизации объединения
подключений к БД. У нас есть огромный набор
драйверов для подключения практически к
любой БД. Так что MTS построен с расчетом на
масштабирование.
Roth: И это прекрасно, потому что с
Enterprise JavaBeans и этой технологией вы сможете воспользоваться
преимуществами их технологии Just-In-Time. Это замечательный способ реализации
активации и "отключения" объектов.
InfoWorld: Сейчас я бы предложил
ответить на вопросы слушателей
Первый вопрос: Одна из вещей,
отсутствующих в MTS - statefull objects, но они есть сейчас в EJB, так что я не
теряю подключения.
Gross: Сейчас у нас нет поддержки
statefull-объекты, но мы находим stateless-объекты
правильным путем для масштабирования на
нашей платформе. На самом деле мы
обнаружили, что можно замечательно
масштабироваться таким образом. А если
нужно сохранить состояние, есть способы
сделать это. Так что есть способы сделать
это, но это не составная часть платформы в
смысле поддержки объектов, хранящих
состояние. Нам кажется, что гораздо проще
иметь stateless objects, и это причина того, что мы
идем этим путем. (полный бред - МК)
Продолжение первого вопроса: И все же
если я строю любимый компонент Internet-приложения, shopping cart сохраняет
состояние пока я что-нибудь не куплю. А Microsoft в статье EJB vs. MTS заявляет,
что разрабатывать для MTS проще, чем для EJB. Но куда проще сделать карточку
покупателя для EJB, чем для MTS.
Gross: Очень просто создать карточку
покупателя. Мы сейчас поставляем такую карточку с Site Server, построенным на
MTS. Так что она есть, уже сегодня.
Продолжение первого вопроса: Но если
сравнить код, количество строк в обоих случаях, EJB проще.
Roth: Но он [Gross] прав.
Stateless-объекты - путь к построению масштабируемых систем. Вот чего я не могу
понять, хотя и знаю несколько человек из команды MTS в Microsoft, а Microsoft
гордится простыми в использовании средствами. Entity Beans - четкий путь
обеспечения хорошего качества компонентов, и мне непонятно, почему они не
поддерживаются в MTS. Мои мозги не могут этого воспринять.
Второй вопрос: Так насколько может
масштабироваться MTS?
Gross: Microsoft может привести
примеры приложений, где более 2500 пользователей используют MTS. Но чего MTS
делать не умеет, он не делает плохой код хорошим. Если в вашей среде кто-то
написал приложение плохо, то оно может и не масштабироваться, независимо, под
MTS или EJB его делали. А если его потом развернули под MTS, оказывается, что
виноват MTS. Это нечестно. MTS масштабируется, и мы это неоднократно
доказывали.
Третий вопрос: А что насчет потерь
памяти и Java?
Roth: В смысле основ архитектуры
серверов Enterprise JavaBeans, любой контейнер может запустить группу JavaBean
Machines. Были ли упомянутые вами проблемы в прошлом? Я был бы лицемерен, если
бы сказал "нет". Но мы работаем над этим.
Четвертый вопрос: Могу ли я поменять
MTS на продукт другого поставщика?
Gross: Ответ - нет. MTS - это огромное
количество системного ПО. У нас сидит прорва народу, разрабатывая этот продукт.
Это основополагающая технология.
Пятый вопрос: Станет ли MTS частью
операционной системы в следующей версии NT?
Gross: Ответ будет "да". Мы объявили о
выходе COM+, являющегося развитием Microsoft Transaction Server. В случае COM+
мы берем COM и MTS и сдвигаем их ближе. Мы также теснее интегрируем их с
операционной системой и добавляем к ней дополнительные службы, в то же время еще
и упрощая ее использование разработчиками <...>. Так что в будущей W2K,
COM+ станет составной частью ОС. Вы получите его с каждой коробкой NT. Мы
собираемся также ввести в COM+ дополнительные службы типа баланса загрузки
(load-balancing) для компонентов. Мы планируем ввести queued component в
технологию как составную часть. Мы собираемся ввести in-memory-БД, что означает
возможность хранения данных на машине, исполняющей бизнес-логику <…>.
Будет множество различных
сервисов, улучшающих и продвигающих вперед
архитектуру. В COM+ мы движемся к модели
программирования, основанной на атрибутах.
Если сейчас вам нужно написать какой-то код
для прерывания или отката транзакции, то в
будущем это будет вопрос щелчка мышью.
Каждый объект будет иметь ассоциированные
с ним свойства. Это уже появилось в MTS и
будет расширено в COM+. Вы сможете кликнуть
мышью и сказать – пусть этот компонент
будет транзакционным, или, пусть этот
компонент будет queued-компонентом.
InfoWorld: Билл, что мы можем
ожидать от Sun в будущем на эту тему?
Roth: Нам следует сосредоточиться на
"write once, run anywhere". Мы должны сфокусироваться на разъяснении факта, что
с EJB-совместимым сервером любое приложение будет выполняться где угодно. Мы
также слышим от наших потребителей, чтот им требуется middleware для
распределенных объектов. Существует 6 различных категорий middleware, и решения
нужны для всех. Прямо сейчас решения приобретаются по частям. Как же может
выглядеть большее решение, возможно, включающее сервис сообщений? А может быть,
почту? Оно может включать массу разных служб? Это то, над чем мы сейчас
работаем. Но, когда я слушал Майкла, я был поистине напуган. И я скажу, почему.
Может ли IT-специалист захотеть доверить свое будущее одному продукту на одной
платформе от единственного производителя? Я не могу – я знаю, что когда я был в
IT, это было очень пугающей вещью. Даже, в то время, в случае IBM.
Gross: Мы не единственный продукт от
единственного разработчика. За нами величайший опыт взаимодействия. Мы можем
работать с почти любой из существующих платформ. Когда вы строите распределенное
приложение, вы не строите его на одной только платформе. Вы собираетесь
использовать различные платформы для разных частей, чтобы получить преимущества,
предоставляемые этими платформами. И эти ребята [Sun] делают это - с одной
стороны, они делают специализированные контейнеры, позволяющие использовать
такие преимущества. С другой стороны, они говорят, что вы можете взять ваше
приложение и перенести куда угодно. Остается только один вопрос, что происходит
с EJB и специализированными контейнерами: В самом деле, write once, run
anywhere? Насколько это честно? Вам следует подумать над этим.
Roth: Конечно, и вы знаете,
<...> возможно, должен быть стандартный путь расширений модели Enterprise
JavaBeans. Это то, над чем мы работаем, и вы это вскоре увидите.
Шестой вопрос: Будет ли MTS
когда-нибудь работать на AS/400?
Gross: Я не могу делать никаких
заявлений на этот счет. Я не могу делать никаких заявлений на этот счет в данный
момент.
<...>
Copyright © 1994-2016 ООО "К-Пресс"
Home
Поиск
Издания
Контакты
