[JDEV] Jabber Transports - New Architecture

[Chris Chen]

How about this?

Consider the scenario where the Jabber Server still retains all its current 
functionality without change.  What we have now is this (in a short form 
relevant to my argument):

1) Distributed "email server like" architecture.  Let's define it as being 
able to query for a "service" (ie. for emails, through DNS's MX records) 
through another "service" (ie. DNS server in this case), and then routing 
messages through that server.

2) Ability to talk to multiple protocols at the same time (ICQ, MSN, Yahoo, 
etc).


So our current problem domain -- To "distribute" the communication with 
other protocols/services through Jabber.

Proposals:

1) Have clients implement the protocol -- not sound, goes against Jabber 
philosophy, too tedious to implement a client, etc etc.

2) Have server send plugin codes -- not sounds and difficult to send a 
language/platform-free data unless you're willing to create a C# CLI/Java 
CLASS -type file definitions and get every client to implement the compiler 
for it.

3) Have server send XML protocol definitions -- it's not very possible to 
be defining the protocol definitions for everything out there and parsing 
out the info to have working code with it.


My proposal:

Rather than try to have "distribute" the communication with other protocols 
to the clients or have it reside on the server, let's take a more "middle" 
approach.  Jabber already supports forwarding of messages based on the host 
part of the JID.  Thus, it supports a string that may also look something 
like "blahblah%hotmail.com at non.jabber.org" when I am connected to 
jabber.org.  It should allow for forwarding of messages to MSN to be routed 
to a server that supports such service (and if not, it should be fairly 
easy to implement as it's just an extension of the current Jabber 
implementation anyways).

Now imagine a set of servers that support, for instance, working AIM 
transports that is more than one Jabber server but fewer than the number of 
total Jabber clients out there.  The non-AIM-working Jabber Servers (call 
them "AIM Ignorants") will know how to route the AIM messages to such a set 
of servers (call them "AIM Forwarders" in this situation).

So what we get is a solution for our problem domain:

Let's reiterate -- Problem Domain -- To "distribute" the communication with 
other protocols/services through Jabber.

Solution Advantages:

*) Effectively eliminating the clients to code for protocol 
implementations, so clients stay the same as now.
*) Jabber servers can forward service-related messages to those that can 
handle them.  Those AIM Ignorant servers (be it disabled or blocked) will 
route the messages to the AIM Forwarders (server that hasn't been blocked yet).
*) Scalibility and Efficiency like the "email-style" routing.
*) Uses the current Jabber server implementations without much change, so 
less coding on the server as well.


Of course, every solution comes with a few little "perks".  Let me 
demonstrate with a scenario that will explain it better:

Imagine a world where the Jabber Server implements the solution.  The 
workflow of the message that is being sent by a client is as follows 
(including implementation suggestions and details):

1) Client is connected to jabber.org that is AIM Ignorant (because it is 
blocked).
2) Client sends a message to an AIM user user%aol.com at aim.jabber.org.
3*) jabber.org sends an UDDI query to the UDDI Registry, asking for AIM 
Forwarders.
4) A set of results come back from the registry.  Jabber.org picks out 
aim.noonecanblockme.org, connects to it through s2s connection, and sends 
the message through the AIM Forwarder.
5) aim.noonecanblockme.org sends the message.

In this scenario, I've marked the step that is additional to the current 
Jabber implementation.  However, UDDI queries and registries should be very 
easy to implement.  In fact, it doesn't even have to be UDDI.  It simply 
needs to be a registry that contains the set of servers for it.

Now the additional thing to change is also the working of service 
registration for the user and other parts.

I know there are more things to change than what I suggested.  However, the 
gist of the solution is that there is a "centralized" (or decentralized 
since the registry can work like the DNS servers) place to query for AIM 
Forwarders (but in a broader sense).

The biggest issues with this problem:

AOL comes over and decides to be a cheater and signs on as a 
user/server.  Then it queries the registry directly for the list of servers 
and kaboom, all the Smart Forwarders just became Dumb Ignorant Idiots.. 
:)  Thus I think a certificate-based authorization is required to connect 
to the registry.  The certificates are only issued to those that are 
approved.  Bigger overhead, but it will lead to better interoperability.

What do you all think?

Chris

PGP at ldap://certserver.pgp.com/