Автор неизвестен - Платформа J2Me
private StreamConnection conn;
/**
Конструктор.
@param с Объект соединения, который представляет
соединение с клиентом. Класс ServerSocket создает и пересылает
его в данный конструктор.
*/
public ServerAgent(StreamConnection c)
super (); conn = с;
}
/**
Выполняется агент данного сервера. Начинается диалог с клиентом. Этот метод должен быть вызван явно после того, как создан данный объект.
public void run()
}
// Взаимодействует с клиентом. Реализует поведение,
// которое определяет данную службу.
}
}
Листинг 8.8. Клиент имеет отдельно соединение с агентом сервера. Модель состояния взаимодействий, а также синтаксис и семантика взаимодействий определяются сервером, но клиенты должны им подчиняться
import javax.microedition.midlet.MI Diet;
import javax.microedition.io.StreamConnection;
import javax.microedition.io.Connector;
import Java.io.lOException;
/**
Данный класс реализует клиента, который соединяется с сервером.
Для создания экземпляра данного класса вы должны указать сервер (имя сервера DNS) и известный порт службы, с которой вы хотите установить соединение.
*/
public class ClientSocket implements Runnable
{
public static final String P.ROTOCOL = «socket»;
// Порт известного сокета сервера, private String serverPort;
// Имя сервера, с которым соединяемся, private String serverHostName;
// URI известного серверного сокета. private String serverURI;
// Соединение с. сервером.
private StreamConnection streamConn;
protected ClientSocket()
}
super();
}
/**
Открытый конструктор. Вы должны указать имя сервера DNS и номер порта службы. @param server — имя DNS машины, с которой вы хотите соединиться.
@param port — Номер порта сервера, с которым вы хотите соединиться.
*/
public ClientSocket(String server, String port)
throws TOException
(
this();serverHostName = server; serverPort = port;
serverURI = buildServerURI (); open ();
}
/**
Конструктор.
@param uri — полностью сформированный URI службы, запрос на соединение с которой вы хотите создать.
@сбрасывает InvalidArgumentException при несформированном URI.
*/
public ClientSocket(String uri) throws lOException
{
this (); serverURI = uri;
}
Открывает соединение. После того как создан данный объект, соединение с сервером еще не открыто. Вы должны открыть его явно.
Это делает модель использования более гибкой для клиентов.
@ сбрасывает lOException, если соединение не может быть открыто по некоторым причинам.
*/
public void open() throws lOException
streamConn = (StreamConnection) Connector.open(serverURI);
/**
Закрывает соединение с сервером.
*/
public void closed try streamConn. closed; }
catch (lOException ioe)
}
ioe.printStackTraced;
{
{
/**
Выполняет клиентское взаимодействие.
Запускает посылку клиентом запросов на сервер.
Этот метод должен быть вызван после того, как метод opend установит соединение.
*/
public void run ()
{
// Начинаем взаимодействие с сервером.
// Посылаем запросы, читаем ответы
….
private String buildServerURI ()
}
StringBuffex uri = new StringBuffer(PROTOCOL);
uri.append ("://"); uri.append(serverHostName);
uri.append(":"); uri.append(serverPort); return uri.toString ();
}
}
Использование соединений сокета в приложениях MIDP. Естественно, тот факт, что интерфейс StreamConnectionNotif ier определен как часть пакета IOMIDP, предполагает, что он должен использоваться приложениями, запускаемыми на устройствах MIDP. Это означает, что MID-лет может поддерживать открытое соединение с известным соке-том для использования клиентами. Клиенты, однако, могут находиться в другом месте.
На самом деле клиенты должны быть удалены от сервера. Назначение сокета сервера на мобильном устройстве заключается в том, чтобы обрабатывать входящие запросы соединения от удаленных клиентов. Использование сокетов для взаимодействий на одном и том же устройстве определенно неэффективно. Хотя это возможно, существуют более удобные модели.
Удаленный клиент может работать на другом мобильном устройстве или на удаленном узле. Потенциально любой из этих типов клиентов может находиться в одной и той же сети как устройство, которое поддерживает сокет сервера, или они могут находиться отдельно от сети транспортировщика. Характеристики сети транспортировщика, в которой ваше приложение работает, определяют набор клиентов, которые могут соединиться с вашим мобильным устройством.
Сети транспортировщика используют протокол сетевого уровня как часть набора протоколов своей сети. Каждое устройство получает уникальный сетевой адрес, в то время как оно соединяется с сетью. Для того чтобы клиенты соединялись с вашим устройством — и вашим серверным сокетом, — они должны быть способны определять сетевой адрес вашего устройства. Конфигурация и реализация сети транспортировщика могут не раскрывать адресов соединенных с ней мобильных устройств внутренне или внешне, таким образом делая соединение клиентов с желаемым мобильным устройством невозможным.
Многие сети транспортировщиков используют некоторого рода динамические сетевые адреса, присваиваемые мобильным устройствам. Если это так, клиентам, желающим соединиться, придется определять адрес мобильного устройства динамично. Если не предоставляется никакого поискового механизма, клиенты не смогут запросить соединение с устройством.
Независимо от того, являются ли адреса мобильного устройства статическими или динамическими, сеть транспортировщика может задействовать какую-либо схему трансляции сетевого адреса (network address translation (NAT)) для изменения или преобразования адреса мобильного устройства. Мотив использования схемы NAT может быть связан с ограничениями места или безопасности. Определенные сетевые протоколы могут не иметь достаточного адресного места для обработки всех цифр сетевых устройств. Если это так, и если транспортировщик желает узнать адреса своих устройств, ему придется предоставить какой-либо реестр для отображения динамических адресов и механизм поиска. В противном случае ваше серверное приложение не будет доступно.
По причинам безопасности транспортировщики могут не захотеть выставлять адреса мобильных устройств своих пользователей на всеобщее обозрение. Если это так, ваше приложение может быть доступно только приложениям, работающим на системах транспортировщика. Более того, доступ может быть ограничен до привилегированных приложений, даже в сети транспортировщика. И даже в сети каждому устройству придется иметь способ объявления своего сетевого адреса другим устройствам для соединения с ним. В большинстве современных поколений беспроводных сетей мобильные устройства не осведомлены о наличии или адресе друг друга. Это может измениться в сетях поколения 3G, которые должны распространиться более широко в ближайшие несколько лет.
Беспроводные сети 3G двигаются в сторону принятия IPv6 как своих протоколов сетевого уровня. В IPv6 существует множество адресов, что делает возможным назначение уникального IP-адреса каждому мобильному устройству в мире. Если каждое устройство имеет уникальный статический IP-адрес, любое приложение, которое знает адрес вашего устройства, может соединиться с известным портом вашего устройства.
Опять же, однако, политики безопасности и конфигурации, применяющиеся транспортировщиком, могут повлиять на возможности, в действительности доступные приложениям.
Различия между организацией сетей В J2ME и J2SE
В предыдущих разделах данной главы описывался полный набор сетевых свойств I MIDP. Пакет java.io MIDP определяет все эти свойства. В MIDP нет пакета java.net, как в J2SE.
Вы также должны знать, что пакет java.io MIDP поддерживает подмножество при- 1 вычных байтовых и символьных классов входных и выходных потоков, представленных в J2SE. В частности, классы BufferedReader, LineNumberReader и StringReader пакета java.io J2SE отсутствуют в пакете java.io MIDP.
Хотя базовая инфраструктура, связанная с сокетными соединениями, существует в реализациях MIDP, в MIDP все еще отсутствует поддержка нескольких механизмов распределенных коммуникаций, которые доступны в платформе J2SE. В MIDP отсутствуют следующие объекты уровня приложений:
— RMI требует слишком большой мощности для поддержки в мобильных устройствах на настоящий момент;
— Jini требует RMI, поэтому не присутствует;
— JavaSpaces не существует в J2ME;
— Связующее программное обеспечение CORBA не существует в J2ME.
Вы увидите в главе 11, что отсутствие этих механизмов необязательно является препятствием. Основная причина их отсутствия заключена в производительности персональных мобильных устройств, однако технология, которую используют порталы беспроводного Интернета для создания внешних интерфейсов своих служб, дает устройствам MIDP соответствующие возможности связи для современных приложений.
