Межпроцессная коммуникация

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

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

Сложность проблемы межпроцессной коммуникации усугубляется еще и тем, что в распределенных системах процессы могут исполняться на различных узлах (о моделировании местоположения см. главу 23). Существует два классических подхода к межпроцессной коммуникации: передача сообщений и вызовы удален­ных процедур. В UML эти механизмы моделируются как асинхронные и синхрон­ные события соответственно. Но поскольку это уже не простые вызовы внутри одного процесса, то проект необходимо обогатить дополнительной информацией.

Моделирование межпроцессной коммуникации производится следующим об­разом:

1. Смоделируйте несколько потоков управления.

2. Рассмотрите, какие из этих активных объектов могут быть представлены процессами, а какие - нитями. Чтобы их различить, воспользуйтесь подхо­дящими стереотипами (см. главу 6).

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

4. Неформально опишите используемый механизм с помощью примечаний (см. главу 6) или - более строго - с помощью коопераций (см. главу 27).

На рис. 22.5 показана распределенная система бронирования билетов, в ко­торой процессы исполняются на четырех узлах (см. главу 26). Каждый объект маркирован стереотипом process, а также помеченным значением location, ко­торое определяет его физическое положение. Коммуникации между объектами ReservationAgent (АгентБронирования), Ticket ingManager (ДиспетчерВы-ДачиБилетов) и HotelAgent (ГостиничныйАгент) асинхронны. В примечании яаписано, что коммуникации построены на основе службы сообщений, реализованной HaJavaBeans. Коммуникация между объектами TripPlanner (ПланировщикМаршрута) и ReservationSystem (СистемаРезервирования) синхронная.

Семантика их взаимодействия показана в кооперации, названной CORBA ORB. TripPlanner выступает в роли клиента, a ReservationAgent - сервера. Рас­крыв эту кооперацию, вы увидите детали совместной работы сервера и клиента.

Советы

Хорошо структурированный активный класс и активный объект обладают сле­дующими свойствами:

• представляют независимый поток управления, который максимально ис­пользует потенциальные возможности истинного параллелизма в системе;

• не настолько мелки, чтобы требовать наличия множества других активных элементов, которое может привести к переусложненной и нестабильной ар­хитектуре процессов;

• аккуратно управляют коммуникацией между активными элементами, вы­бирая наиболее подходящий случаю механизм - синхронный или асин­хронный;

• исходят из трактовки каждого объекта как критической области, используя подходящие синхронизирующие свойства для сохранения его семантики в присутствии нескольких потоков управления;

• явно разграничивают семантику процесса и нити.

Рисуя в UML активный класс или активный объект:

• показывайте только те атрибуты, операции и сигналы, которые важны для понимания абстракции в соответствующем контексте;

• явно показывайте все синхронизирующие свойства операции.