Distributed Architecture
OpenGate has been designed on a distributed point to point architecture that helps to simplify the development of wireless solutions based on GPRS/UMTS. In this distributed architecture the following components come into play.

Cliente
On this side you’ll find not only the M2M devices for telemetrys, remote control and monitoring, but also PDA type that allow the mobilization of corporate applications.
Different types from devices will be applied according to the scenario in question:

M2M Devices: Hardware elements wich process capacity,
storage resources and wireless modules of communication.

Mobile devices: Where included are devices that incorporate wireless communication capacities like GSM/GPRS/UMTS, Wi-fi, BlueTooth, etc.:

The name of the organization that they belong to.

The name of the channel that they wish to communicate under.

You have to bear in mind that to have remote agents in devices, these should meet a minimun features of hardware as well as software requirments that allow the incorporation of different OpenGate componants.
To a great extent the devices which have greater capacity (storing and processing) will enjoy the possibility of incorporating components of a greater level to implement solutions much more faster and reliable.

OpenGate Platsform
In this side we find the OpenGate communications. At this OpenGate level one is in charge
mainly to manage safe and trustworthy handle the messages interchanged between clients and applications..

Aplication
In this side are the applications that are in charge to manage the information received from devices. The interaction of these components within the OpenGate architecture is schematically represented by means of the following diagram:

Organización de Usuarios

Organizations
In OpenGate the organizations group to users and channels according to the
following scheme:

In the previous figure the following relations can be observed :

The relation between organization and users is of one organization for

many users.

The relation between organization and channels is of one organization for

many channels.

The relation between users and channels is of many to many therefore:

A user can be in many channels simultaneously

A channel can be associated to many users

Users
Both the applications and the remote devices are 'users' of the platform. OpenGate distinguishes them on the basis of the 'role' assigned to the user


Channels OpenGate implements the channel of users concept. A channel is logical grouping of users (movable clients and applications) in OpenGate. In addition to the logical grouping, this characteristic elevates the level of security as much at level of connectivity as at level of interchange of messages since:

All the users of OpenGate must belong to a channel to be able to connect

themselves and to interchange messages.

Messages between users cannot interchange with who do not belong to his

channel in the same one organization.

Another characteristic that contributes the property of a channel is the capacity to be able to send broadcasting messages to the channel. This broadcasting can be of three different forms based on different needs:

Broadcast to all the users of the channel:

The message generated by a user will arrive to all

users of the channel.

Broadcast to all the applications of the channel:

The message generated by a user will arrive

to all users connected with the application role.

Broadcast to all the clients of the channel:

The message generated by a user will arrive to all

users connected with the client role.

OpenGate is in charge of handling broadcasting messages to the corresponding users within the channel.

Messages
The communication with OpenGate is made by means of the interchange of messages. The objective of this interchange of messages is made optimal and transparent. OpenGate takes care of:

Receive and to direct the messages interchanged between

clients and applications.

Adapt the flow of messages in case of message flood.

Persist with the messages in case the adressee is not connected.

Notify the situation of the journey of the messages through the Platform with

the objective to offer the information necessary to implement

transactional mechanisms.

OpenGate distinguishes among four types of messages:

Synchronous Command/Answer: This type of message waits for the answer

of the adressee and is blocked.

Asynchronous Command/Answer: This type of message waits for answer of

the adressee and it is not blocked.

Event: This type of message does not wait for any answer on the part

of the adressee.

Notification: Is the messages sent by the platform to the originators of the

messages in order to notify the situation of the journey of the messages.

Three types of notifications exist:

1. Notification of arrival to the Platform.

2. Notification of exit of the Platform.

3. Notification of arrival at destiny.

The sender of the message can configure the notification level as he wishes.

Content of the messages
The content of the messages is opened, this way the solution can be adapted to the concrete need The structure of the messages is the following one:

Head:

Identifier of the adressee of the message.

Identifier of the message

Time of the message

Body: Lists data units of variable length that can be of the following types:

Byte

Character

Chain of characters

Whole numbers with and without a sign

Long whole numbers with and without a sign

Numbers of floating comma

Numbers of floating comma of double precision

The Interchange of the OpenGate messages is bidirectional, therefore they can either be sent by the applications or by the devices, thus establishing a point to point framework.

Command/Answer
This type of messages always waits for an answer by the adressee. Two types of commands/answer exist: synchronous and asynchronous. The synchronous commands stop the execution of the program flow until they receive the answer. The asynchronous commandos allow the continuation of the flow with the execution of the application listening for the answer through a callback.

Events
This type of messages does not wait for an answer and usually is sent spontaneously by devices and applications without being previously solicited.

Notification
All the messages sent through the platform can be formed by the sender user
so that the platform automatically emits notifications of transit:

Security

Access Control
Before making any interchange of information, any wireless devices and control applications should first pass two validations in OpenGate:

User/Key [channel and organization] Challenge: Only devices

User/Password challenge [channel and organization]/ password:only the

devices and applications given access by the OpenGate administrators can

connect to the platform. You have to take into account that a user is identified

uniquely through his/her organization and the channel in which they wish to

interchange messages, therefore a user wishing to access

OpenGate should provide:

The name of the channel that they wish to communicate under.

Name of the user.

Password.

Access Control List: With this access control list you can restrict the range of IP addresses that can connect to OpenGate.

Point to Point Security
OpenGate implements the Secure Socket Layer (SSL). This characteristic offers point to point encyption of the communication between the devices and the applications.

Channels
Inside OpenGate the clients and applications of an organization are grouped by channels in a way that:

The users should inform the channel that the wish to connect to during the process of validation.

The messages interchanged between the users (applications and clients) a channel can not be accessed from the users of other channels.

Users foreign to the channel can not inject messages into the channel.