Здравствуйте, glh, Вы писали:
glh>Многие неофиты не знают элементарных вещей!
Ну да, конечно, опять все дураки а вы мнее всех...
glh>Проблемы использования и не использования чего-либо лежат совсем не в области программирования и проектирования и не имеют ничего общего с мощью или недостатками отдельных продуктов.
А кто говорил про недостатки Корбы, я просто утверждаю что она — умерла как технология и все. Это не значит что она была плоха.
Вячеслав Педак
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Взаимодействие Ява-сервера с не-ява-клиентами
Здравствуйте, glh, Вы писали:
glh>Ну Вы наверное просто в том числе и на С# пишете, потому так и говорите — своя рубашка ближе к телу.
glh>Я, напротив, примерно уже с год как наблюдаю некоторое отврезвление. glh>Зарплаты на NET просели, проекты в основной массе однотипные.
На job.ru сходите и сравните количество предложений работы на C# и Delphi, все вопросы отпадут
glh>Плюс, не забывайте о факторе массовости и/или моды. glh>Там где массовость — там низкая квалификация, студенты и прочие "индусы".
И что? В джаве тоже массовость... Да и вообще миф о тупизне индусов — сильно преувеличен. Не стоит покупаться на массовое мнение...
V>>ну дак научите как сделать лучше? Раскажите какой брокер лучше использовать в коммерческой системе которая пересылает 1000 сообщений в минуту (хотя бы), как на C# работать с ним и т.д.
glh>Ну вот посмотрите, вендор сознательно исключает поддержку конкурента. Ведь для MS родные (d)COM(+) и SOAP. glh>Потому как у CORBA есть "фатальный недостаток — его придумали не они" и XML-RPC кстати тоже.
glh>Естественно возникают трудности при работе с технологией, которые вынужденны решать разработчики. glh>Либо сами, либо с помошью третьих вендоров. В частности у Borland было решение CORBA для NET, Ethera кажеться.
glh>Может быть он его уже интегрировали в VisiBroker — "Fully compliant with the CORBA 2.6 specification and beyond, VisiBroker supports development in Java, C++ and .NET languages, including Microsoft C++ and C#".
glh>PS. У нас в организации есть проекты и на NET(Сs) и на Java и на Win32(CB&Delphi).
Ну т.е. научить не можете? Дак тогда сидите и не учите других стоит им писать свой велосидеп или нет.
Итак на суд общественности предлагается 2 варианта технического решения.
Вариант первый (для натоящих крутых программистов)
1. Команда прграммистов из города Кременчуг которая раньше разрабатывала на Deplhi, берет где то сервер приложений (я согласен, что Борланд так себе серверок, надо брать круче, они и стоят под $50 000, есть где развернуться настоящему программисту).
2. Они изучают J2EE (им же надо будет свою логику закинуть в этот сервер)
3. Они изучают CORBA и понимают как из нее соединиться с J2EE сервером (по ходу дела еще покупают Борландовский визиброкер для этого, который тоже несколько штук баксов стоит).
4. И потом если это все-таки смогут соединиться с этим сервером и пройти все технические сложности они смогут начать разрабатывать свою систему на java.
Мы не будем сюда добавлять что так как у них коммерческая система, то они должны ее разварачивать у заказчика, т.е. им надо будет еще на заказчика лицензии на весь этот софт покупать, конфигурить его и т.д. Это же фигня, для настоящих мужчин.
Вариант второй (изобретение велосипеда).
1. Они дают задание одному программисту прояитать книжку из серии "Java за 21 день", потом пару статей как надо из джавы работать с неблокирующимися сокетами и он за месяц — полтора пишет програмку на Deplhi, которая из некоторого описания ремотного интерфейса генерит серверный и клиентские стабы на нужном языке программирования, которые по TCP/IP будут байтики гонять по некоторому своему протоколу.
2. Садятся и пишут свой серверок на серверном стабе.
Ну и теперь если выключить "пальцы" доказывая друг другу какие мы тут крутые и включить здравый смыл, ответьте на вопрос какой путь для них правильный?
P.S. Я даже не хочу комментировать весь тот бред что Борландовский офис в России не занимался поддержкой их сервера приложений и то, что JBoss лучше BEA и Oracle.
Вячеслав Педак
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Взаимодействие Ява-сервера с не-ява-клиентами
Здравствуйте, tischenkoalex, Вы писали:
KD>>Spring и Hibernate прямого отношения с интеграцией с не Java клиентами точно не имеют. KD>>Первое — это IOC + навороты, а второе — ORM.
T>Собственно почему я и задаю вопросы. Все эти технологии оперируют объектами и их коллекциями, как происходит визуализация всего этого добра на клиенте? Как коллекция объектов может быть отображена и отредактирована в гриде?
Ну это достаточно просто решается и сейчас на Delphi, если использовать совмесно RemObject и DevExpress Quantum Grid.
У этого грида есть так называемый provider mode, когда он подключается не к обычным датасетам в Delphi,
а к любым произвольным пользовательским данным, через класс-адаптер (кстати, продукты devExpress определённо написаны под влиянием java)
То есть, это получается этакий MVC.
А класс TROArray в RemObject содержит методы для обращения к любому полю в струкртуре
по имени или индексу, (эти методы используются RemObject'ом для сериализации\десереализации, и используют внутри RTTI
— куций аналог java reflection).
Ну а дальше все просто — пишется адаптер котрый подключатеся к RemObject, и в гриде у нас появляются данные из коллекций.
В адаптере есть события на редактирование данных, можно их отловить что-либо сделать.
То есть, все как написал ниже Blazkowicz.
Можено пойти еще дальше — для Quantum Grid написать свой view (наследник для TCustomTableView),
которое содержит в себе этот адаптер.
Тогда в design-time настраиваем столбцы грида и маппинг полей на структуры, в коде присваеваем ссылку на массив,
и можно работать с данными.
Поэтому мы использум RemObject, а DataAbstract как то не прижился.
Правда, это на классический подход Delphi к работе с данными совсем-совсем не похоже.
>Каждое изменение свойства объекта провоцирует вызов на сервер или изменения состояний объектов коллекции может кешироваться на клиенте?
А свойство объекта и не должно провоцировать вызов. Объект это Модель, котрая сама по себе не меняется, ее меняет Контроллер.
Вот у него и нужно искать события срабатывающие при изменении данных.
Re[5]: Взаимодействие Ява-сервера с не-ява-клиентами
Здравствуйте, glh, Вы писали:
glh>Ну вот посмотрите, вендор сознательно исключает поддержку конкурента. Ведь для MS родные (d)COM(+) и SOAP. glh>Потому как у CORBA есть "фатальный недостаток — его придумали не они" и XML-RPC кстати тоже.
Верно, но они уже реабилитировались в этом отношении — .NET Remoting.
Re[5]: Взаимодействие Ява-сервера с не-ява-клиентами
Здравствуйте, 6lackbird, Вы писали:
6>Здравствуйте, Blazkowicz, Вы писали:
B>> В Delphi нет рефликсии? Не верю. 6>Ну если только так WriteProcessMemory Function для не .net
Ну это вы совсе Delphi опускаете , зачем такие ужасы как WriteProcessMemory , все там есть.
Описание форм Delphi хранит в ресурсах, значит должна быть возможность установить значение свойства по имени,
и создать класс по назанию типа. Да и дизайнер форм без рефлексии никак не сделать.
А начиная с 7 версии, рефлексия позволяет получить список параметров у метода, и динамически вызвать метод.
Правда, не любой метод, а только описанный в секции published, но это не страшное ограничение.
Здравствуйте, vpedak, Вы писали:
V>Давайте попробуем свести все?
V>Итак на суд общественности предлагается 2 варианта технического решения.
V>Вариант первый (для натоящих крутых программистов) V>Вариант второй (изобретение велосипеда). V>Ну и теперь если выключить "пальцы" доказывая друг другу какие мы тут крутые и включить здравый смыл, ответьте на вопрос какой путь для них правильный?
Вячеслав, но ведь пальцы-то никто вроде и "включал".
И C0s и я говорили, что свое решение будет и дешевле и проще. По крайней мере первое время.
Но ведь данная ветка получилась такой не потому что надо решить задачу "вообще".
Вообще она решается элементарнейшим образом — транспорт на сокетах со своим прикладным протоколом, бинарным(BER, ASN, custom) или текстовым(XML или JSON), или сервлеты в контейнере и гонять тотже протокол по HTTP.
И где на чем там клиент и сервер становится глубоко фиолетово.
В определенный момент времени зашла речь о стандартизированных решениях не привязанных ни к платформе ни к языку. Вот тут-то и появилась и CORBA.
Если можно переписать все это одно.
Не многие могут это себе позволить.
Есть такие штуки как совместимость, преемственность.
Одно дело внутренний(например) продукт и совсем другое разработка, на которую потрачемы миллионы.
Инсталляции у тысяч клиентов и тд и тп
В этом случае чтобы все переписать нужно сказать — стоп — замораживаем ветку — ждите через год-два новую версию.
Я уже говорил, что это вопрос не технический, лежит совсем в другой плоскости.
Успехов!
C уважением, Алексей.
------------------------------------------------
Хороших %s не бывает — бывает не худший вариант.
Re[6]: Взаимодействие Ява-сервера с не-ява-клиентами
Здравствуйте, rsn81, Вы писали:
glh>>Ну вот посмотрите, вендор сознательно исключает поддержку конкурента. Ведь для MS родные (d)COM(+) и SOAP. glh>>Потому как у CORBA есть "фатальный недостаток — его придумали не они" и XML-RPC кстати тоже. R>Верно, но они уже реабилитировались в этом отношении — .NET Remoting.
да забыл просто написать
Успехов!
C уважением, Алексей.
------------------------------------------------
Хороших %s не бывает — бывает не худший вариант.
Здравствуйте, glh, Вы писали:
glh>В определенный момент времени зашла речь о стандартизированных решениях не привязанных ни к платформе ни к языку. Вот тут-то и появилась и CORBA.
Ok, значит я пропустил этот определенный момент. На мой взгляд человек спросил как ему в его условиях что-то сделать, а ему CORBA советуют использовать...
Но уж если мы переключились на эту тему, то почему тогда не SOA?
Здравствуйте, vpedak, Вы писали:
V>Но уж если мы переключились на эту тему, то почему тогда не SOA?
тем, что это не стандарт, а некие общие характеристики некоторого подхода, подкреплённые безудержным маркетинговым buzz
в конкретных приложениях на конкретных реализациях SOA видно, что за всем стоят обычные технологии, которые, вдобавок, применяются неправильно
Здравствуйте, vpedak, Вы писали:
V>Итак на суд общественности предлагается 2 варианта технического решения.
это два полярных варианта, а истина где-то посередине.
V>Ну и теперь если выключить "пальцы" доказывая друг другу какие мы тут крутые и включить здравый смыл, ответьте на вопрос какой путь для них правильный?
с моей точки зрения, она заключается в движении в сторону стандартизованных (де-юре или де-факто) средств с преимущественно открытым кодом, что позволит сократить велосипедостроение и добавить смысла. возможное наличие инвестирования в платные вещи просто как плюс, которым можно при удаче с умом воспользоваться
потом, понятно же, что надо будет искать итеративные пути развития. если технологии позволят меньше потратить времени на освоение за счёт повторного использования уже имеющегося опыта, то за них можно даже и платить.
Здравствуйте, vpedak, Вы писали:
V>P.S. Я даже не хочу комментировать весь тот бред что Борландовский офис в России не занимался поддержкой их сервера приложений и то, что JBoss лучше BEA и Oracle.
а на чём основывается твоё резкое высказывание?
я, например, какой-то период был в обойме людей, тесно с ними сотрудничавших. сидел там в 15 метрах, можно сказать, и кое что про их кухню того времени представляю. нельзя сказать, что суппорта вообще не было, но техническими вещами они не занимались.
Здравствуйте, C0s, Вы писали:
C0s>а на чём основывается твоё резкое высказывание? C0s>я, например, какой-то период был в обойме людей, тесно с ними сотрудничавших. сидел там в 15 метрах, можно сказать, и кое что про их кухню того времени представляю. нельзя сказать, что суппорта вообще не было, но техническими вещами они не занимались.
Да просто я знаком с человеком кто это support осуществлял, т.е. решал реальные архитектурные и технические задачи.
Здравствуйте, C0s, Вы писали:
C0s>это два полярных варианта, а истина где-то посередине.
Но людям то сейчас решение надо, сегодня... Вот они и пришли умных советов послушать. Истина — она понятно всегда посередине, только им все равно надо из Delphi соединяться к java
C0s>с моей точки зрения, она заключается в движении в сторону стандартизованных (де-юре или де-факто) средств с преимущественно открытым кодом, что позволит сократить велосипедостроение и добавить смысла. возможное наличие инвестирования в платные вещи просто как плюс, которым можно при удаче с умом воспользоваться
Да кто же с этим спорит что стандартизированные средства лучше? Только вот где их взять в этой конкретной задаче?
Да и лично я не читаю открытый код преимуществом, слишком мало продуктов с открытым кодом, которые приличные. В основном фигня какая-то неработающаяся попадается...
Здравствуйте, C0s, Вы писали:
V>>Но уж если мы переключились на эту тему, то почему тогда не SOA?
C0s>тем, что это не стандарт, а некие общие характеристики некоторого подхода, подкреплённые безудержным маркетинговым buzz C0s>в конкретных приложениях на конкретных реализациях SOA видно, что за всем стоят обычные технологии, которые, вдобавок, применяются неправильно
Ну я наверное соглашусь что четкого стандарта на всю SOA нет, но ведь SOAP, WSDL, UDDI — это стандарты. WS-security и WS-Transactions насколько я помню уже тоже стандартизированы. Что разве этих стандартов не хватит для начала?
Здравствуйте, vpedak, Вы писали:
V>Ну я наверное соглашусь что четкого стандарта на всю SOA нет, но ведь SOAP, WSDL, UDDI — это стандарты. WS-security и WS-Transactions насколько я помню уже тоже стандартизированы. Что разве этих стандартов не хватит для начала?
для меня SOA — это архитектурный подход, SOAP — лишь его созвучие, а стандарты из мира WebServices напяливаются на аббревиатуру SOA только маркетологами
т.е. проблема не в аббревиатуре, проблема в её каком-то особом толковании и мнении о ней как об очередной серебряной пуле
Можно смотреть на Axis. С его помощью довольно легко делаются SOAP сервисы на Яве. А по соответствующим WSDL-кам Дельфи сгенерирует стабы. В результате есть канал общения. Клиента, ИМХО, можно разом не перекраивать — временно оставить клиентские датасеты и обновлять их сгенерёнными по WSDL-кам классами. А потом по-маленьку перекидывать контролы с датасетов на что-то более удобное и прямое.
Здравствуйте, C0s, Вы писали:
C0s>для меня SOA — это архитектурный подход, SOAP — лишь его созвучие, а стандарты из мира WebServices напяливаются на аббревиатуру SOA только маркетологами
то, что SOA это архитектурный подход — это понятно, только кроме веб сервисов на данный момент никто не сможет обеспечить этот подход (про корбу только давайте сначала не начинать ) когда требуется независимость от языка разработки.
C0s>т.е. проблема не в аббревиатуре, проблема в её каком-то особом толковании и мнении о ней как об очередной серебряной пуле
Я в этом проблемы не вижу (то кто и как все это толкует). Технически то возможно обеспечить работу с разных платфорт на веб сервисах, так что все-таки есть альтернатива корбе. Я именно об этом.
, все там есть.
