XMPP for communication with Sensors, Actuators and Streaming on interacting BUS-platforms:
( EPR-eDevice Templating )
The eXtensible Messaging and Presence Protocol (XMPP) is an open technology for Real-Time communication. It is an open-standard communication management protocol for message-oriented middleware based on XML. ( The protocol was origionally named Jabber).
XMPP fits all kind of real-time instant messaging for:
Condition Monitoring
VoIP-signalling
Video-streaming
File-transfer
Important use is Smart Grid and other Scosial networking services.
With EPR-eDevice modules XMPP is used to organize communication between eDevice module(functional model as an CAM-template) and it's connected sensors(inputs) and actuators(outputs). It allows for easy two-way communication, so no polling has to be used. This protocol is used since a huge count of sensors and actuators could be connected to one EPR-eDevice and for controlling them, standard serial tunnels will suffer from overload and inconvenient usage.
XMPP-Strengths:
Decentralization : The architecture of the XMPP network is similar to email; anyone can run their own XMPP server and there is no central master server.
Open standards : The Internet Engineering Task Force has formalized XMPP as an approved instant messaging and presence technology under the name of XMPP (the latest specifications are RFC 6120 and RFC 6121). No royalties are required to implement support of these specifications and their development is not tied to a single vendor.
History : XMPP technologies have been in use since 1999. Multiple implementations of the XMPP standards exist for clients, servers, components, and code libraries.
Security : XMPP servers can be isolated from the public XMPP network (e.g., on a company intranet), and strong security (via SASL andTLS) has been built into the core XMPP specifications.
Flexibility : Custom functionality can be built on top of XMPP; to maintain interoperability, common extensions are managed by the XMPP Software Foundation. XMPP applications beyond IM include groupchat, network management, content syndication, collaboration tools, file sharing, gaming, remote systems control and monitoring, geolocation, middleware and cloud computing, VoIP and Identity services.
XMPP-Weaknesses:
In-band binary data transfer is inefficient : Because XMPP is not yet encoded as Efficient XML Interchange but as a long-lived XML stream, binary data must be first base64encoded before it can be transmitted in-band. Therefore any significant amount of binary data (e.g., file transfers) is best transmitted out-of-band, using in-band messages to coordinate. The best example of this is the Jingle XMPP Extension Protocol,XEP-0166.
XMPP-Decentralization and addressing:
The XMPP network uses a client–server architecture (clients do not talk directly to one another). However, it is decentralized—by design, there is no central authoritative server, as there is with services such as AOL Instant Messenger or Windows Live Messenger. Some confusion often arises on this point as there is a public XMPP server being run at jabber.org, to which a large number of users subscribe. However, anyone may run their own XMPP server on their own domain.
Every user on the network has a unique Jabber ID (usually abbreviated as JID). To avoid requiring a central server to maintain a list of IDs, the JID is structured like an e-mail address with a username and a domain name (or IP address[15]) for the server where that user resides, separated by an at sign (@), such as username@example.com.
Since a user may wish to log in from multiple locations, they may specify a resource. A resource identifies a particular client belonging to the user (for example home, work, or mobile). This may be included in the JID by appending a slash followed by the name of the resource. For example, the full JID of a user's mobile account would be username@example.com/mobile.
Each resource may have specified a numerical value called priority. Messages simply sent to username@example.com will go to the client with highest priority, but those sent to username@example.com/mobile will go only to the mobile client. The highest priority is the one with largest numerical value.
JIDs without a username part are also valid, and may be used for system messages and control of special features on the server. A resource remains optional for these JIDs as well.
XMPP via HTTP and WebSocket transports :
The original and "native" transport protocol for XMPP is Transmission Control Protocol (TCP), using open-ended XML streams over long-lived TCP connections.
As an alternative to the TCP transport, the XMPP community has also developed an HTTP transport for web clients as well as users behind restricted firewalls. In the original specification, XMPP could use HTTP in two ways: polling[16] and binding.[17] The polling method, now deprecated, essentially implies messages stored on a server-side database are being fetched (and posted) regularly by an XMPP client by way of HTTP 'GET' and 'POST' requests. With BOSH, the client uses HTTP long polling to receive messages as soon as they are sent. This push model of notification is more efficient than polling, where many of the polls return no new data.
Because the client uses HTTP, most firewalls allow clients to fetch and post messages without any hindrances. Thus, in scenarios where the TCP port used by XMPP is blocked, a server can listen on the normal HTTP port and the traffic should pass without problems. Various websites let people sign in to XMPP via a browser. Furthermore, there are open public servers that listen on standard http (port 80) and https (port 443) ports, and hence allow connections from behind most firewalls. However, the IANA-registered port for BOSH is actually 5280, not 80.
A perhaps more efficient transport for real-time messaging is WebSocket, a web technology providing for bi-directional, full-duplexcommunications channels over a single TCP connection. Experimental implementations of XMPP over WebSocket exist, and a (now-expired) Internet-Draft documenting this approach was published at the IETF but not yet standardized.
Implementations :
XMPP is implemented by a large number of clients, servers, and code libraries. These implementations are provided under a variety of software licenses.
Deployments :
Several large public IM services natively use XMPP, including Google Talk, and LiveJournal's "LJ Talk"[18], Nimbuzz, and Ovi (Nokia). Various hosting services, such as DreamHost, enable hosting customers to choose XMPP services alongside more traditional web and email services. Specialized XMPP hosting services also exist so that domain owners need not directly run their own XMPP servers, including WebEx Connect, Chrome.pl, Flosoft.biz, i-pobox.net, and hosted.im.
XMPP is also used in deployments of non-IM services, including smart grid systems such as demand-response applications, message-oriented middleware, and as a replacement for SMS to provide text messaging on many smartphone clients.
Extensions:
The XMPP Standards Foundation or XSF (formerly the Jabber Software Foundation) is active in developing open XMPP extensions. However, extensions can also be defined by any individual, software project, or organization. For example, Google has defined a number of non-XSF extensions, which are used in Google Talk and Google+ (e.g., for signalling related to Google Hangouts). Another example is the federation protocol in Apache Wave, which is based on XMPP.[19]
Competing Standards:
XMPP has often been regarded as a competitor to SIMPLE, based on the Session Initiation Protocol (SIP) protocol, as the standard protocol for instant messaging and presence notification.[20][21]
The XMPP extension for multi-user chat [22] can be seen as a competitor to Internet Relay Chat (IRC), although it is not as widely used as IRC.
Similarly, the XMPP extensions for publish-subscribe [23] provide many of the same features as the Advanced Message Queuing Protocol.