к которому получен доступ — URL, файл, сетевой канал, дейтаграмма и так далее. Модель J2SE не извлекает этих подробностей из приложения.
В модели MIDP потоки ведут себя так же, как и в модели J2SE, они все еще не знают ничего о текущем физическом сетевом ресурсе. Они просто знают, как управлять содержимым, предоставленным им, при создании их экземпляра. Блок соединения, однако, скрывает от приложения подробности установления связывания потока с текущим сетевым ресурсом.
Существует два основных преимущества модели структуры общих соединений. Во-первых, она извлекает из приложения подробную информацию об установлении соединений. Во-вторых, это извлечение делает структуру наращиваемой. С помощью стандартного расширяемого механизма обращения к сетевым ресурсам реализации платформы MIDP могут быть расширены для поддержки дополнительных протоколов, в то же время для получения приложениями доступа ко всем видам ресурсов будет поддерживаться один механизм. Кроме того, логика приложения остается независимой от сетевых механизмов.
Чтобы использовать структуру общих соединений, приложения MIDP указывают сетевой ресурс, к которому они хотят получить доступ, используя универсальный идентификатор ресурса (universal resource identifier (URI)), за которым следует синтаксис стандартного URI Интернета, определяемого RFC 2396. URI поддерживает классический синтаксис для идентификации ресурсов в Интернете. Общая форма URI следующая
<схема>://<адрес;<параметры>
Частью URI является его поле схемы, которое представляет собой протокол, используемый для соединения. RFC 2396 поддерживает множество действующих схем, таких, как as file, datagram, socket, serversocket, http, ftp и так далее.
CLDC не определяет поддержку каких-либо из них. Причина этого заключается в том, что спецификация CLDC не позволяет ручной настройки. Поэтому все реализации CLDC должны поддерживать одни и те же свойства. Реализации MIDP, однако, могут реализовать так много настроек, сколько пожелаете. Однако спецификация MIDP требует, чтобы реализации поддерживали, по крайней мере, протокол HTTP 1.1. Несколько факторов влияют на доступность поддержки протоколов в реализациях MIDP:
— Ограниченность производительности в беспроводных сетях, времени установления соединения, полосы пропускания и времени ожидания накладывает ограничения на типы сетевых коммуникаций по сравнению с проволочными сетями.
— Программное обеспечение клиента (на мобильном устройстве) устанавливает поддерживаемые виды схем соединений. Мобильные устройства в настоящее время не имеют ресурсов, поддерживающих обработку общих типов сетевых соединений или протоколов уровня приложений.
— Порталы беспроводного Интернета делают использование HTTP своим основным механизмом взаимодействий на уровне приложений.
Реализация платформы MIDP предоставляет действующую реализацию поддержки протоколов. Эти реализации протоколов не являются частью определений MIDP или CLDC. Они представляют собой зависящие от реализации компоненты, указанные в главе 1.
На рисунке 8.1 представлено схематичное изображение этапов, входящих в процесс создания и использования соединения. Эти этапы, которые мы перечислим позже, соотносятся с условным обозначением, показанным на рисунке 8.1.
Объект соединения содержит входной и выходной потоки для считывания и записи данных для ресурса, соответственно. На рисунке 8.1 схематично представлены взаимосвязи между соединением и его двумя потоками.
— Приложение запрашивает класс Connector для открытия соединения с сетевым ресурсом.
— Фабричный метод Connector.open() анализирует URI и возвращает объект Connection. Полученный объект Connection содержит ссылки на входной и выходной потоки к сетевому ресурсу.
— Приложение получает объект InputStream или OutputStream из объекта Connection.
— Приложение считывает данные из InputStream или записывает их в OutputStream в процессе своей обработки.
— Приложение закрывает Connection при завершении работы
Когда у вас установлено соединение, вы используете два потока для взаимодействия с сетевым ресурсом. Существует два аспекта при коммуникации с сетевым ресурсом
— анализ сообщения протокола;
— анализ
Например, если клиент устанавливает HTTP-соединение, он должен проанализировать синтаксис и семантику ответного сообщения протокола HTTP, возвращенного сервером. Сообщение HTTP передает некоторого рода содержимое, и клиент должен быть способен проанализировать содержимое соответствующим образом. Если, например, содержимое сообщения является данными HTML, клиент должен соответственно анализировать HTML содержимое. Если приложение не знает формата данных, переданных входящим потоком, оно не сможет правильно интерпретировать либо синтаксис, либо семантику содержимого потока.
Структура общих соединений MIDP определяет иерархию типов соединений, объединяющую природу различных видов потоковых соединений. То есть различные типы представляют различные протоколы, используемые соединениями. При использовании соответствующего типа соединения анализ и управление различными типами содержимого соединений становится проще. Например, HTTP-соединения являются основой сетевых коммуникаций в MIDP. Структура общих соединений определяет тип соединения, чей интерфейс поддерживает создание HTTP-запросов и анализ HTTP-откликов.
Пакет javax.microedition.io определяет один класс и набор интерфейсов, которые представляют различные типы содержимого соединений. Класс Connector является единственным конкретным элементом в структуре общих соединений. Вы должны использовать его для получения текущих соединений с ресурсами. Он действительно содержит фабричный метод, который создает различные типы структур соединений для поддержки различных протоколов.
Иерархия интерфейсов в структуре общих соединений определяет абстракции, которые характеризуют различные типы соединений, поддерживаемых блоком создания соединений. Эти интерфейсы предоставляют методы, которые облегчают приложениям управление общими типами соединений.
На рисунке 8.2 показана иерархия наследования интерфейсов MIDP, которые являются частью общей структуры соединений.
