I have an enterprise application which for many reasons is set up as a one server (app instance actually, multiple app instances can reside on a single physical server) per network (for example Trumark Financial has app1.service.com while First Protective has app2.service.com). Now each app instance has it’s own database with it’s own user table and to make matters a little more interesting there are groups inside a single app instance so not everyone in a single app instance can see everyone else. Now this all works (rather cleverly I think, but then I’m biased), what I would like to do is introduce an XMPP server on top of this, allowing for instant messaging through standard clients while observing the account/group system being administered inside my app. I’m right now starting to hack away at the *Provider interfaces but I’m hitting a bit of a wall. It seems that OpenFire is built around a one app instance per network model, so Users in any part of an OpenFire instance are discoverable by all other users (I’m taking this from the fact that findUsers doesn’t take as a parameter the current logged in user, unless there is some global context that I’m missing).
My question is, am I missing something? I tried to search this forum for the answer and I did find one thread about UserProvder (http://www.igniterealtime.org/community/docs/DOC-1524) but this only seems to confirm my assertion. So is this something I can do with OpenFire? If not, does anyone have any ideas of another server that I can try?
Ok so that’s interesting, I’m going to look at the filter interface. My questions was more about the user discovery aspect of OpenFire (ie a search for other members should return the same users that a search for connected profiles in my application returns). Here is an example that might illustrate the concept better.
Image this table called UsersTable (and I know this would be bad schema, in my app groups and memebers have a “many to many” relationship)
User
**Group
**
Allen
Trumark
Bill
First Protective
Carl
Trumark
If Bill does a search for L he should only see himself (which is filtered out so then zero results are returned). If Allen does the same search he should see Carl. The only way to resolve this search correctly is to factor in the group affiliation of each result as it relates to the group of the user performing the search. In SQL the query would be
SELECT * FROM UsersTable WHERE Group=user.Group;
This case “user” would represent the user executing the query. I realize I might be trying to use a screw driver like a hammer. OpenFire seems like it was designed to require 2 instances to work the way I’m trying to use it (a Trumark instance and a First Protective instance to use my example). This is not a bad thing, just makes administration more of a challenge for my particular use case.
That that would an interesting way of looking at the problem. If I already have a profile connection system, why try and graft on to OpenFire’s system. I’ma bit sketchy on how OpenFire tests the online status of your buddy list. Is that the job of the IM client? And if so is it just a series of indavidual calls to the OpenFire server for each friend’s status? If thats the case then I can just make the findUsers function always return an empty list, and I can exend an IM client to use my API for a “friend list” (the next step after this would be to introduce a JavaScript IM client in my app (think Meebo but with only XMPP support)).
the IM client sends its presence information to the Openfire server which forwards it to the connected clients which have a subscription (roster). So as long as you have a user in your roster you’ll get presence updates when the user logs in/out or changes the status to away.
Ok so following this logic out, if I eleminate searching as a OpenFire service (UserProvider.findUsers() always returns 0 results) and I manage authentication and roster editing through my code adn web service, then OpenFire will take care of managing who the messages go to, while my code manages who can see whome. I just have to take care to prune a users roster when they leave a group in my code. Do I have that about right?
there a rosters and there are shared groups. Every user can modify its roster and add or remove other users. Shared groups are managed by the server admin and maybe the better choice for you.
Every user can chat with every other user by sending a direct message to him, no matter whether the user is in the roster or not.
So you may want to use also the packet filter if you want to block communication between users which don’t know each other. So you can also block packets to “search.example.com” and thus disable search without a code change.
Not sure if a web service is required, maybe you can use the external database provider.