I’‘m interested in creating a Gateway for Yahoo and was curious what the best way to implement this. I’‘ve spent some time getting familiar with the code base, but want your feedback regarding the best way to build this. I’'m using jYMG library that associates a user to a session. I would need to translate the JID to the jYMG library and maintain that association.
It looks like I’‘d need to build a Component or Plugin that handles this. Then maintain a map between active JIDs and their corresponding jYMG session (I’'m not too concerned about saving username/password combos at this point, I just want to get it to work).
I was also looking at the s2s implementation and realized that this is too low level for what I need. jYMG handles the (bidi) connection with the server so I need something a step higher. I was looking at the RoutingTableImpl and it looks like I need to create a collection of domains that are associated with gateways (MSN, AIM, etc) that get routed to the appropriate RoutableChannelHandler.
Does this seem reasonable? The RoutableChannelHandler seems like the most likely place to maintain the JID/jYMG sessions and handle the processing of the requests, the only question is how do I get callbacks from jYMG back into place? Do I just get the RoutingTable and call route going the opposite direction?
We’'d eventually like to have a set of interfaces that developers can implement for gateways. That would simplify a lot of tasks. However, to start:
Create a plugin that also acts a component. The component name would probably be yahoo, so a full name of “yahoo.yourserver.com” where yourserver.com is the name of your server.
Hardcode the connection information into your component as a start so that it always connects to the yahoo service as a certain user. Then, try to make messages sent to someuser@yahoo.yourserver.com get sent to the actual Yahoo user names “someuser”.
So, you might be able to re-use some of the logic RoutableChannelHandler, but I don’‘t think you’'d want to use that class directly.
Thanks for the link to JEP-10. I agree with your goal for creating a set of interfaces to support gateways.
I created a BasicModule called GatewayManager and on init, added a route to the routing table. I’‘m not entirely sure how to register subdomins to components, but I’‘m guessing the MUC classes will provide some insight. Also, what’'s the best way to get packets from the client? The best I can tell is to place a JID in the RoutingTable and make sure a RoutableChannelHandler is registered for that JID. Is this correct?
Check out the source of the broadcast plugin. It’'s a very simple example of how to create a plugin that is also a component. The gist is (in initializePlugin):
// Register as a component.
componentManager = ComponentManagerFactory.getComponentManager();
try {
componentManager.addComponent(serviceName, this);
}
catch (Exception e) {
componentManager.getLog().error(e);
}
Looking at the Component mechanism, it provides a way of processing packets destine for the sub domain, but I need to get all packets for a particular user so I can translate them to the gateway. Once the user comes online, I need to translate that to the user being online on the gateway, etc. Any ideas on how to handle this type of packet processing?
Some time ago Alexander Buloichik started to implement a gateway framework (ie JEP 100) and reached a point where some incorrect roster management on the server prevented him to finish the gateway. Since we are now following the XMPP spec very closely the roster&presence bug was fixed so that wouldn’‘t be a problem now. Alexander is going to send me the latest code so after I reviewed it I’'m going to check it in CVS. As I recall, though he was writing the gateway for MSN the framework was generic enough to be used for other legacy networks.
In general, you don’'t have to care about packets routing since the server will do all the work for you. Writing a component is the best way to go. Using the component as an external component would be even better since many people may want to run the gateway as another process to off load the server. Developing the component as an external component will force you to not use any private JM class. Therefore, you will be immune to JM changes and your external component may be even used with other XMPP servers as well.
After I checked in the gateway code to CVS I will update this thread.
Any thoughts regarding my last post? I understand the component as a destination, but the gateway needs to also be able to route information back to the user. I guess I should create a XMPP packet and call XMPPServer.getInstance().getRoutingTable().getBestRoute().process( ); to send the info to the user/client?
The broadcast seem like it was simply wrapping up a call to the broadcast method (exact name escapes me), but doesn’'t support the component generating incoming packets to the server.
I would recommend using the second suggestion made by Ryan since you may want to run your gateway as an external component instead of an internal component. Therefore, you should avoid making any reference to JM internal classes.
Currently, I have an alpha code base that supports JEP-100 Registration and unregistration, login/logout. Still pending is the roster management (one false start, I’‘m currently worknig on v2 and basic handling of messages. Once I can get a working proof of concept (using Yahoo! as the target gateway), I’‘ll publish the code…if Gato et al, can create a incubator in svn, I’'ll post it sooner
Part of the fun of being an external component is that I don’‘t have access to any of the underlying code from jive messenger (this is something Gato and I believe is a good thing). My first pass was trying to maintain that information and push it to JM, I looked at JEP-0144 as a means to do this, but to date JM doesn’‘t support JEP-0144. However, if the client supports it, than it shouldn’'t be difficult. Does anyone know a client that supports JEP-0144 at this point in time? Free would be nice, considering my development budget for this project.
I finally decided to not maintain any of that information. If a user wants to access a member on through the gateway than they need to register with JM, the gateway will gladly honor the request (it assumes you know what you’'re doing) and forward the messages. This goes both ways. If a message is sent from the legacy server, the gateway happily forwards it along. JM will silently discard it if that entity is not registered in the recipients roster. rosterx could make the maintenance easier, but either JM needs to support it or the client.
that I don’'t have access to any of the underlying
code from jive messenger (this is something Gato and
I believe is a good thing).
This is actually something I think I differ on with Gato. External components are quite nice in that they work with a variety of servers. However, it can be a major PITA to not have access to the internal API’‘s. For example, it just wouldn’'t be possible to do presence handling the way we do in Asterisk-IM as an external component. I also love how easy it is to deploy a plugin vs. external component. Although, if you used the Whack classes to build your external component, it should be pretty easy to make it also work as a plugin…
I didn’‘t really think JEP-0144 had anything to do with the server, at least in the way I interperted it. Its a process by which an entity can make suggestions to a client as to whom to add to its roster. I personally dont know of any client that implements it currently, but its really very easy to get smack to use it, considering its really just like one attribute away from regular rosters. I don’'t know if persay it makes the maintenance easier in your case because then you have to maintain a roster for each user in side your gateway to know to tell the client who to add, modify, or delete. Though it does make it more convienent for the end user who doesnt have to then repeat the tedium of adding everyone to their jabber roster from yahoo or wherever.
Reading the spec, it seems that any entity can inquire about any other entity. This means that if the server has an JID to represent it, it can ask questions (or recieve updates) and act on them as well. This means I don’'t have to maintain roster information on the gateway because I can just hand it off as it rolls in. Since rosterx offers suggestions[/i] I can repeat the notice without concern of “spamming” the target entity (assuming the target entity handles rosterx notifications gracefully).