OpenFire Phase Summary

Starting from March to study openfire, in fact, is to do a set of IM system, it is precisely this reason to understand the openfire. I never thought that there were so many open-source products that I could do im, and I didn't think that XMPP was such a powerful protocol. It seems that the standard is the first, good standards can promote industrial development AH.

OpenFire and simple demo before written a "technical note: XMPP Openfire+spark+smack", then the main focus on how to let this system run up, but now still at this stage, just learn something to leave some notes.

1, for the study of XMPP is very important

At first I felt it was too easy to build a set of Openfire+spark, and to change the interface of Spark to become a new product, so it was not too deep to think that the XMPP protocol was so advanced. Just as the simple thing is over, the core is the agreement itself, understanding the protocol can better understand the operation of the system in order to realize how complex this system is. Of course it's a bit complicated for me, especially when it comes to the front and back end combination design and start.

To this end I recommend a domestic XMPP protocol translation website: http://wiki.jabbercn.org/%E9%A6%96%E9%A1%B5.

Of course, if the English is good, then the original: http://xmpp.org/about/technology-overview.html

After a period of learning, the feeling of QQ and the basic principle of the real and xmpp very similar, but the use of the protocol format some differences, perhaps this is the level of instant communication abstraction. But is the markup language using XML a waste of traffic? Although XMPP is very convenient to expand, these tags are really big enough, like the usual text chat, perhaps the middle mark generated traffic and chat content is quite. After all, I'm not up to this stage of big traffic, so it's just an idea.

2. Some design points and ideas of OpenFire

OpenFire source code as a whole look at or relatively clear, the expansion of support plug-in and component mode. In the recent expansion of the discovery of OpenFire source code itself is not very good to modify, the dependency is very strong, but the dependency between the module is relatively loose, the class dependency in the module is basically tightly coupled. Just OpenFire can be extended through the plug-in, the source code itself depends on a lot of small, so that overall is very good.

The main ways to extend plugins in OpenFire are:

• Iqhandler

In the XMPP protocol, the IQ packet refers to the information/query, can be used for data query between the server and the client, Openfir implemented a iqrouter to handle the IQ package. The natural Iqhandler is the specific IQ pack processing unit. Iqhandler is based on namespace for interception, so you can customize your own namespace.

Iqhandler provides two abstract methods for deriving a class implementation:

    /*** Handles the received IQ packet. *     * @parampacket the IQ packet to handle. * @returnThe response to send back. * @throwsUnauthorizedexception If the user that sent the packet are not * authorized to request the given operation. */     Public AbstractIQ HANDLEIQ (IQ packet)throwsunauthorizedexception; /*** Returns The handler information to help generically handle IQ packets.      * iqhandlers that aren ' t local server IQ handlers (e.g. chatbots, transports, etc) * return <tt>null</tt>. *     * @returnThe iqhandlerinfo for this handler*/     Public AbstractIqhandlerinfo GetInfo ();

The Handleiq method is to unpack and process the business, and finally return the result package.

getInfo is the command space used to return the current Iqhandler

Then you need to register to Iqrouter for this handler to take effect, you can create Iqhandler objects and add them when the plug-in starts:

@Override      Public void Initializeplugin (PlugInManager Manager, File plugindirectory) {        new  iqgroupchathander ();        = xmppserver.getinstance (). Getiqrouter ();        Iqrouter.addhandler (Iqhandler);    }    @Override    publicvoid  Destroyplugin () {        Iqrouter.removehandler ( Iqhandler);    }

• Compoent

Compoent is also a more commonly used extension method that can be processed by packages for a specific subdomain. For example, MUC registers a different service, each service has a subdomain, and the system distributes the different subdomain packets to the specialized service. This brings a benefit, can fully customize a set of sub-domain package processing business, followed by the implementation of the public number of subscription number in order to solve this idea. And OpenFire also has a mechanism for remote components that can be extended into a separate business system so that the openfire can only serve as the core of message processing.

The concrete application is also relatively simple, realizes the component interface, and registers in the ComponentManager. The most important method in the component interface is the Processpacket method, the code is as follows:

    /**      * Processes A packet sent to this Component.     *     @param  Packet the packet.      @see Componentmanager#sendpacket (Component, Packet)      */     Public void processpacket (Packet Packet);

Note that the parameters in the method are packet, which means that the communication primitives under all subdomains can be used for processing here.

The registration and Exit methods are as follows:

       ComponentManager = Componentmanagerfactory.getcomponentmanager ();         Try {            componentmanager.addcomponent (this);        }         Catch (Exception e) {            log.error (E.getmessage (), e);            System.err.println (e);        }         Try {            componentmanager.removecomponent ("subdomain");         Catch (componentexception e) {            log.error (E.getmessage (), E);        }

• Packetinterceptor

In OpenFire so the transmission is based on the packet, the packet on the derivation of different communication primitives, such as message, roster, JID, IQ and so on. Based on this principle, it is possible to provide a set of packet interception mechanism to achieve a relatively powerful extension mechanism. Such a mechanism is provided in the OpenFire. Interceptors for packages are available in the Iqrouter\presencerouter\messagerouter.

// Invoke The interceptors before we process the read packet            true false);

Interceptors are registered in Interceptormanager, and interceptors are called when routing packets, and the code above is an example of code that is intercepted in a route.

Then the same implementation of an interceptor Packetinterceptor interface, and registered to the Interceptormanager can be.

Interceptormanager.getinstance (). Addinterceptor (Interceptor); Interceptormanager.getinstance (). Removeinterceptor (Interceptor);

With the above three methods, OpenFire can develop a variety of uses, so the official itself has implemented the release of multiple plugins for use. It is also advisable to use plugins for openfire extensions, unless your custom requirements are high, and the OpenFire itself is not adapted.

My requirements are almost always achieved, and it's very easy to upgrade the new version later, and there's no problem.

3, Spark's tangled

Spark also comes from the jivesoftware, but it doesn't feel so good to expand. Maybe I didn't fully understand its expansion principle. In fact, my requirement is to rewrite the spark UI while adding my own features, such as group, subscription number, etc. First think of Spark is also support plug-in, but the last change in code, it is found that the dependency is too deep, basically with the interface related to the existence of dependencies, and finally may have to rewrite a set.

In fact, there is a uicomponentregistry class in spark, and some of the main interfaces are registered in this class. But it's abhorrent that most of these registered classes cannot derive new classes to replace these registered classes. Like what

Private Static extends Chatroom> Chatroomclass = Chatroomimpl. class;

This is the chat window of the registration class, then if I want to write a chat window of their own, is not directly the registration class to replace it? No, because the other code will altogether use this

    @Override    publicvoid filesdropped (collection<file> files, Component component) {    ifinstanceof  chatroomimpl) {        = (Chatroomimpl) component;           for (file file:files) {        Sparkmanager.gettransfermanager (). SendFile (File,            Roomimpl.getparticipantjid ());        }        Sparkmanager.getchatmanager (). Getchatcontainer ()            . Activatechatroom (Roomimpl);    }    }

In another class, altogether directly uses derived classes for type judgments, which is just a point, and there are too many similar points. So it's not possible to start thinking about what to expect by deriving the classes registered in Uicomponentregistry. Plus time is limited, also lazy tube so much, let development directly in the source code to change.

Damn it. 2.7. The 7 version of the upgrade found that the code changed, this version of the upgrade smack4.x version, and a large number of use of the new features 1.8. So it went through a code merge before it was upgraded. In addition, smack basically does not provide an extension, only provides the event subscription.

But Spark is a cross-platform, it is easy to run under the Mac, and the code is Java, and temporarily do not want to abandon, and so on in the future to consider whether to rewrite it.

OpenFire Phase Summary