уточняю:
узел - конечные реализации группируемые по по типу их сервиса.
сервер - координатор узлов.
сервис - функционал предоставляемый сервером, а значит группой узлов.

в почтовой задаче вижу такое: узлы, сгруппированные по типу сервиса, шлют письма другим узлам в этой группе. (нужна идентификация узлов)
в математической модели: узлы, сгруппированные по типу сервиса, вызывают функции предоставляемые другими узлами этой же группы. (сами же предоставляют по одной функции к этому сервису)

так?

Добавлено @ 01:16

добавить _сервис_адартер_ - требующий сервис исходных данных, и сервис результирующих. тоже не плохо бы продумать.


Up.


Это сообщение отредактировал(а) boostcoder - 31.3.2011, 01:21

это с точки зрения сервера
(меня вообще-то клиент пока гораздо больше интересует)
с точки зрения клиента это опциональные функции/методы, поддерживаемые сервером

Добавлено через 1 минуту и 30 секунд

не совсем понятно. ну, шлют письма... это еще не почта
может, чат? подсоединиться, выбрать комнату, слать сообщения, видеть сообщения других

  

не понял...
сервер - выполняет только координацию узлов по сервисам. ничего более. пока 


чьи методы?
к примеру:
есть узел входящий в группу math, предоставляющий функцию add суммирующую два значения. есть необходимость суммировать два массива значений. что для этого нужно(как вариант): чтоб каждый сервис имел группу подсервисов. тогда, при обращении к узлу add, узел, "поймет" что к нему пришли массивы и "поймет" какого типа элементы массива. из этого, он сможет "понять" какой подсервис-конвертер ему нужен, и обратиться к нему.

вроде так...

Up.


Это сообщение отредактировал(а) boostcoder - 31.3.2011, 01:37

это вообще отдельная тема, интересная. связанный вопрос: где хранятся данные? в CORBA 3.0 например данные могут храниться (и частично обрабатываться) локально.
но это вопросы реализации, нам бы пока с задачей определиться

к примеру, в данный момент, отсутствует получатель - храним письмо, раз уж это почтовый сервис.

mes, пример чего именно?

Добавлено через 1 минуту и 58 секунд

почему?!
если у нас есть сервисы, почему у них не может быть подсервисов? по моему, очень даже логично...


чьи данные? узла? - там где узел располагается.

кто там узлы, а кто нет.. 
допустим что сейчас сервис один и работает только внутри сети.. (т.е. почта наружу не уходит)

узлы, при отправке письма, являются клиентами-отправителями. в остальных случаях, они получатели. все в группе mail.

это он так думает. а с точки зрения клиента вся работа на нем. или Вы сразу думаете как распределить это в среде? имхо преждевременно.
хотя мысль у меня на этот счет была: есть серверы трех типов 
1. сервер информации, который дает справку о серверах и предоставляемых ими сервисах. это каталог
2. сервер-поставщик и координатор, именно он общается с клиентом, но не сам вычисляет, а распределяет задания к подключенным к нему сервисам, для которых он клиент
3. сервер-сервис, непосредственно производящий вычисления

первый тип - вопрос будущего (а с учетом ограничения С++ я вообще не уверен что такая степень масштабирования понадобится)
второй и третий в простом случае объединены в один. т.е. каждый сервис может выступать в роли единичного поставщика

для начала надо с клиентом и типом 3 разобраться


синтаксис надо продумать

в данном случае это неважно. т.к. узел - это вычислительная единица. и его расположение - всего лишь один из факторов.

может быть и может. я пока не вижу как это в концепции С++ укладывается 

Добавлено через 4 минуты и 12 секунд

это наводит на мысль отсоединенных вычислений, т.е. дать возможность клиенту дать задание, отсоединиться, подсоединиться позже и получить результат.
но это опять же уводит нас вширь, давайте пока на простом сосредоточимся

да. а почему нет?


слишком много разделений. имхо.


узел, в любом случае должен получать информации о сервере(координаторе). так почему бы ему не передать _список_этих_информаций_ ? тогда, при подключении к первому серверу(координатору), сервер, исходя из того, что он знает какие он координирует сервисы, может решить, оставить узел у себя(если узел попал по назначению), или отключить. при отключении, узел будет подключаться к каждому серверу(координатору) из списка, пока не найдет свой.


до языковых конструкций еще ой как далеко 


Это сообщение отредактировал(а) boostcoder - 31.3.2011, 01:56

я - спать...

в голове укладывается...как бы это изложить....


никуда не уводит. если Вы, к примеру, реализуете узел принимающий участие в сервисе mail, то его особенности реализации остаются известными только ему, и узлам подобным Вам. т.к. все узлы сервиса mail обязаны иметь одинаковый интерфейс.

Добавлено @ 01:54

Цитата(baldina @  31.3.2011,  01:51 )

я - спать...

спокойной.

Это сообщение отредактировал(а) boostcoder - 31.3.2011, 01:57

потому что это можно реализовать не затрагивая клиента, т.е. подумать об этом когда будет работающая модель простого типа


ну так мне было быстрее проиллюстрировать. хотя про конструкции (хотя бы желательные, максимально естественные) думать можно, ибо именно они залог успеха - мощной, но простой в использовании системы

уже сплю