Имеем:
1. Супер-мега учетная система работающая на СУБД Oracle в центральном офисе.
2. Около 30 удаленных точек, которым необходимо предоставлять доступ
(как запрос информации, так и произведение определенных изменений) в БД этой системы.
3. Связь удаленных точек через "интернет", т.е. идеальной связи не подразумевается.

Необходимо определиться с технологией реализации ПО удаленных точкек которое будет
в режиме реального времени проводить операции с использованием БД центрального офиса.

Пожелания:
1. Исключить использование распределенных БД с репликациями.
2. Максимально разделить логику работы с БД Центрального офиса и интерфейсную часть.
3. Реализовать логику обработки информации в БД Центрального офиса.
4. Максимально использовать промышленные решения и сосредоточить усилия на реализации серверной логики и интерфейсной части.


Предпологается:
1. Всю логику реализовать на сервере БД и предоставить доступ к ней с помощью WS.
2. Использовать протокол SOAP несмотря на его относительную громоздкость и сложность (по сравнению с тем же XML-RPC), т.к. она представляется наиболее законченным решением.
3. На серверной части использовать контейнер OC4J (подкупает его умение самостоятельно генерировать код java модулей для вызова необходимых PL/SQL пакетов).
4. Java будет использоваться исключительно для вызова PL/SQL пакетов.
5. Логика обработки информации реализуется исплючительно на PL/SQL в виде пакетов.
6. Клиентская часть реализуется на VFP с использованием компонент MS SOAP ToolKit 3.0 и MSXML4.0


Вопросы:
1. В случае потребности смены контейнера OC4J на фриварный аналог, допустим TomCat, насколько я понимаю, проблем должно быть минимум, максимум пересборка исходников сгенерированных OC4J. Т.е. переехать на другой контейнер проблем не составит. Так ли это ?

2. Насколько я знаю официальная поддержка компоненты MS SOAP ToolKit 3.0 законченна в марте месяце этого года. А что предлагается взамен не понятно. Где брать свежие библиотеки?

3. Т.к. связь не предпологается идеальной существуют ли в реализации MS или в какой-либо другой, контроль целостности информации в пакетах запросов/ответов SOAP ?

МихаилРВы задали столько вопросов, боюсь на все сразу здесь не ответят, раскидайте по профильным форумам.

ig74852. Насколько я знаю официальная поддержка компоненты MS SOAP ToolKit 3.0 законченна в марте месяце этого года. А что предлагается взамен не понятно. Где брать свежие библиотеки?
Взамен предлагается переходить на .Net, причем конкретно на настоящий момент - на WCF. Никаких иных решений Microsoft, скорее всего, поддерживать не будет.

Если вас не устраивает MS Soap, то у вас два варианта:
- найти сторонние COM SOAP библиотеки (правда нам это в свое время не удалось сделать)
- изолировать часть, связанную с общением по SOAP, так чтобы это стало выглядеть как общение с библиотекой с ограниченным набором методов и уже эту библиотеку реализовать в другой среде, в виде COM-класса, к которому будет обращаться ваша VPF-программа. На чем реализовывать это уже как вам будет удобнее: можно на .Net, можно в Delphi, ...

Ясно. Спасибо.
А правильно ли я понимаю, что структура объектов MSSOAP.??????? существует только в MS SOAP Toolkit 3.0, а в WCF объекты имеют другие названия/структуру? Это я к тому, что мало ли сторонних программ требующих/использующих WCF и которые придется использовать совместно с нашим ПО (использующее MSSOAP). MS SOAP и WCF не будут замещать объектов друг друга (уживутся вместе) если их установить на одном компе?

МихаилР ig7485Ясно. Спасибо.
А правильно ли я понимаю, что структура объектов MSSOAP.??????? существует только в MS SOAP Toolkit 3.0, а в WCF объекты имеют другие названия/структуру? Это я к тому, что мало ли сторонних программ требующих/использующих WCF и которые придется использовать совместно с нашим ПО (использующее MSSOAP). MS SOAP и WCF не будут замещать объектов друг друга (уживутся вместе) если их установить на одном компе?

За это не беспокойтесь. WCF-это полностью .Net компоненты, они никак не связаны с MSSOAP, который является чистой COM-библиотекой.

Только еще раз обратите внимание, что использовать из VFP, напрямую .Net, вы не сможете (хотя, возможно, в VFP 9.0 что-то в этом плане существенно изменилось - я не работаю с VFP). Поэтому, чтобы работать через WCF, вам придется написать свою обертку и экспортировать ее как COM - это не слишком сложно, но поразбираться придется.

Еще один нюанс: WCF - это .Net 3.0 и выше, а значит требования к ОС: XP SP2 или W2003 SP1 и выше. Если это не устраивает, то можно работать с библиотеками поддержки Web-сервисов из .Net 2.0 (не WCF) - там требования к ОС на много ниже.

Честно признаться я ожидал, что WCF это COM компоненты MS SOAP только с индексом 40, и предпологал легкий переход с MSSOAP на WCF :-).

Предварительное тестирование показывает, что MSSOAP достаточно для поставленных задач да и, как я понял, простая и безпроблемная в использовании библиотека, поэтому WCF оставим на будущее, а там может еще какой фраймверк от MS подойдет :-).

Насчет обертки к WCF в виде COM объекта, тут пришла бузумная мысль: OC4J автоматически генерирует в том числе и клиента (java классы), вот если бы их обернуть и выставить в виде COM. Но это так, полет фантазии.

MasterZiv
ig7485 wrote:

> Предпологается:

Кааак всё сложно ...
может просто VPN ?


Уточню, что на удаленных точках подключение с гарантированной полосой пропускания не предполагается.

Если имеется ввиду, что через VPN предполагается работа аналогичная работе в локальной сети, то пробовали, но не рассматриваем это как рабочий вариант.
Туннелинг организовывался через SSH (PuTTY), делали форвардинг порта 1521.
Путь прохождения пакетов: Удаленная точка <--> DSL <--> Провайдер1 <--> Провайдер2 <--> DSL <--> Центральный офис. Все в пределах одного города, провайдеры 1 и 2 соединены между собой через точку пиринга (мощный маршрутизатор).
В качестве приложения запускался PLSQL Developer (согласен, приложение в части трафика достаточно тяжелое, но в качестве наргузочного тестирования само то). Тормоза в работе реально мешают, потеря связи по тайм ауту - обычное дело. "Головная боль" с зависшими сессиями и откатывающиммся транзакциями. Конечно, можно и таймауты увеличить в насторйках и приложение оптимизировать (это как раз самое сложное !), но эти меры затратны и никаких гарантий не дают. А что будет если удаленная точка располагается в другом регионе (качество соединения и стабильность значительно снижается) ? Да и поиск на форуме отзывов об опыте положительного использования VPN решения не дает.

MasterZiv
ig7485 wrote:
> 3. Т.к. связь не предпологается идеальной существуют ли в реализации MS
> или в какой-либо другой, контроль целостности информации в пакетах
> запросов/ответов SOAP ?

SOAP обычно работает по протоколу HTTP, который работает по протоколу TCP/IP,
который гарантирует доставку пакетов. То, что они НЕ ПОВРЕЖДЕНЫ по дороге
(наприер, подмена пакета) - это оно не гарантирует. Но можно использовать SSL,
там уже кажется искажения будут замечены (вообще-то SSL осуществляет шифрование,
но контроль целостности при этом думаю также гарантируется, хотя точно
надо посмотреть).


Насчет того, что SSL предотвращает искажения: хорошая мысль надо подумать, но в любом случае SSL + сгенерированные сертификаты - для нас это следующий шаг.

Насколько я понял в SOAP (или в реализации OC4J) существует понятие "Надежный обмен сообщениями" которое выражается в появлении в заголовке SOAP сообщения новых тегов/атрибутов, типа:

SOAP:mustUnderstand="1">
<wsrm:MessageId groupId="20081012-054548-578.2@unknown-0aee036.mshome.net"/>
<wsrm:ExpiryTime>2008-10-12T05:45:58</wsrm:ExpiryTime>
<wsrm:ReplyPattern><wsrm:Value>Poll</wsrm:Value></wsrm:ReplyPattern>
<wsrm:AckRequested/>
<wsrm:DuplicateElimination/>

пока непонятно как это работает и возможно-ли этим воспользоваться, пока разбираемся.

maytonТема довольно интересна. Но может быть её лучше перенести в "Проектирование БД" ?
Возможно, но как это сделать я не знаю.

maytonMasterZiv
ig7485 wrote:

> Насколько я понял в SOAP (или в реализации OC4J) существует понятие
> "Надежный обмен сообщениями" которое выражается в появлении в заголовке
> SOAP сообщения новых тегов/атрибутов, типа:

Я не знаю, как там в SOAP, TCP/IP гарантирует доставку пакетов.
Posted via ActualForum NNTP Server 1.4

Наверное автор хотел провести черту между доставкой пакетов и доставкой "сообщений".

Именно так. Я ж написал "...в заголовке SOAP сообщения".
Целиком SOAP сообщение выглядит так:
Для чего этот надежный обмен сообщениями, если TCP (не UDP) гарантирует доставку (и целостность?) пакетов ?

MasterZiv
ig7485 wrote:

> Для чего этот надежный обмен сообщениями, если TCP (не UDP) гарантирует
> доставку (и целостность?) пакетов ?


Насколько я знаю, в спецификации SOAP не регламентируется способ доставки
сообщений от клиента серверу (и обратно), не регламентируется используемый
сетевой протокол низшего уровня. В принципе, подразумевается чаще всего,
что это - HTTP или HTTPS, который базируется на TCP. Но по идее, SOAP-у
это по барабану. Также напр. SOAP-у по барабану шифрование, аутентификация
и пр. - это осуществляется средствами более низкого уровня ( HTTPS, например).

Возможно, в SOAP есть ещё и какие-то свои средства квитирования, я не знаю.
Вам надо - ну поищите. Но на уровне TCP доставка всего потока данных, идущего
в двух направлениях, гарантируется. Не гарантируется только целостность
содержимого пакетов.
Posted via ActualForum NNTP Server 1.4
Ясно. Тема гарантированной и целостной доставки SOAP сообщений закрыта.