[JDEV] From one to many - or Real time data transport?

[Peter Antman]

Hi, thanks for your answer, but I am not shure I got it all, see comments.

On 13 Sep, Thomas Charron wrote:
> Quoting Peter Antman <Peter.Antman at abc.se>:
>> I recently discovered Jabber (through Linux Journal) and finds it very
>> interesting. I am currently trying to understand its architecture. My first
>> reaction was, aha - an open source XML based Message-oriented middleware 
>> (MOM) product. Then I started reading the documentation and realized it was
>> Instant Messaging product with the ability to send messages from one node 
>> (entity) to another - Point-to-Point in MOM lingo (PtP)-, and to subscribe 
>> to another user/entity's presence - Publish/Subscribe (Pub/Sub) in MOM
>> lingo.
>> And this is fine, and Jabber is really making its way in this category of 
>> software. 
> 
>   This is where things get interesting.  You see, at a point, the definition
of 
> a 'endpoint' begins to blur.  If your producer is connected as a client, 
> sending to a client, you are point to point.  The primary issue here is, in
all 
> reality, there is no primary 'server' here.  Sure, there's the jabber server, 
> but it's called a 'transport'.  If you where going to use jabber for 
> disemination of this type of data, you'r producer would most likely be,
another 
> transport, which is part of the server side of things, not really a client.  
> But it is..  ;-P  Confused yet?


OK, I will try to comment on that, but it might include some response to your
comments further down. Lets try it this way. From the perspective of the
documented protocoll, jabber has these features:

Jabber has two distinct parts here as I can see:

1. An end client, wich basically allways is a client.

a. A client talks to a server (never a client) via the XML abstraction layer.

b. A client may subscribe to another end clients presence (via the server).

c. A client may send a message to another client (via the server).

d. A client may interact with the server (roster, query...)

2. A server part.

a. The server conists of several parts, wich may interact with each other.

b. a server part (transport) may interact with another server part - and is then
a client to that server part.

A couple of questions arise here:

1. To be a "client" in the server to anther server part, is that also covered
ny the XML abstraction layer, or is there an internal protcoll for this?

2. Is the server done in a way that it may reuse functionality?

   An example. The presence mechanism have to use broadcast, to broadcast a 
presence to all interesting parties. This broadcas must be implemented 
somewhere in the server. If one where to build a mechanism (as your mailing
 list functionality) you would like an end client to subscribe not to an end
 client but to sort of a server functionality. And the server part would 
broadcast any messages to all subscribed parties. Would it have to 
reimplement the broadcast itself - i.e basically hold its own list of 
subscribers and send the message individually to all subscribers.

3. Is it possible to subscribe to a precense of a server entity - i.e may a
 server entity have a jabber identity, serverlog at jabber.org for example,
 without the server entity being implemented as an end client using the XML
 abstraction layer? Or should it be messages at serverlog.jabber.org and then 
it would be up to the transport serverlog to interprete the message user ID. 
But then again, would it have to implement its own broadcast mechanism then,
 or is there some reusable part of jabber to use for this?

> 
>> Then I started reading the Jabber Internet-Draft. And in the connectionmap
>> in 
>> section 2 one finds something different, namely a transport meant to
>> provide
>> "real time data to Jabber, such as log notification". It's a part of 9.1
>> too:
>> "Any server-side entity can easily participate in the real-time generation 
>> and delivery of XML".
> 
>   Note the wording here.  'server-side entity'.  This probrably best describes 
> a transport.  They are all servers.  But they're clients to eachother.  They 
> may indeed have clients themselves, making them servers.  But they make use of 
> other resources, making them clients..  ;-P

See above, is there not infact two clients interfaces then. One between 
server entitys, and one between a server entity and an end client?


> 
>> This is interesting, and sort of makes Jabber look a little more like a MOM
>> again.
> 
>   It is, but doesn't follow the traditional model that a message oriented 
> middleware would.  It builds much of the front *AND* back tier into the system 
> itself.
> 
> 
>> The problem is this: I can not find any documentation in the protocols for 
>> such a feature, if you do not interpretate the quotes above in a naive way.
> 
>   Unfortionatly, code was being bashed out for a while here, and much of the 
> conceptual documentation has gone to the side.  This does need to be revamped.  
> Most of the documentation has been on the jabber client end, which talks to 
> the 'jabber transport'.  That's a narrow view of the jabber world..  That's 
> prob what you're missing.  What's going on on the server side of the fence..
>

Use the source Luke, or what ;-)
 
>> My interpretation is this (it might be naive too ;-)): There is some though
>> that it should be possible to have a real time feed of data of some sort and 
>> that users/clients should be able to get this data send to them as
>> messages.
>> If this is true, it would mean that Jabber would have to have support for 
>> Publish and Subscribe for a specific types of messages (topic in MOM
>> lingo), and it would start to look like a MOM again.
> 
>   Exactly.  This would be done by subscription.  Subsription is used to tell 
> something/someone you want some data.  It's also used as a way to have the
idea 
> that someone can 'subscribe' to your presence, which is, in a way, a way for a 
> server to be a client to you.  They work hand in hand.  You login, and send 
> presence to the server.  The server you are connected to looks at who you've 
> approved subscriptions to, and let's them all know you're online.  They, in 
> turn, do what they wish with this.  One of the many things would be, start 
> streaming data.  When you then log off, subscription is once again checked,
and 
> authorized parties are informed you are no longer online.  In a way, both
sides 
> of the coin are clients.  But they're both servers.  ;-P  Middleware, yes, but 
> here, everythings in the middle, except specifically for the jabber client.  
> It's definatly a client.  But then again, it can serve as a server by 
> specificaly informing a destination of presence, without telling the server at 
> all..  ;-P
> 

I do understand this, but following the available documentation this would 
stil mean that if you want to stream data to an end user (you know he is 
online by subsribing to his presence) you would have to send it to each and 
every one, ie, the published of the streamed data would have to know the 
identity of all participants, wich is not a god abstraction. It looks this 
way to me:

  Lets say we have two end clients, c1 and c2, and a real time feed rt.

  c1->register with real time feed.
  c2->register with real time feed.
  rt->presence of c1
  rt->presence of c2
  rt->send to c1
  rt->send to c2


  A better way to do it is to place something in the middle ( a topic in MOM 
lingo). Lets introduce topic t1.

  c1->subsribe to t1.
  c2->subsribe to t1.
  rt->publish to t1
  
  Now its up to t1 to see to that the real time feed is fed to al registered 
client (subscribers), this will be done by a broadcast mechanism - and I
 would guess it would need to have the same functionality as the presence 
mechanism.
  

>> Why do the quotes imply that? Because the only other way I can see it is that 
>> the publishing source (the live data feed) would have to know the identity of 
>> every one interested in getting the message - and if I understand the
protocol
>> correct, such a real time event notifier would have to send each individual a 
>> separate message.
>> Much like you do in a mailing program by defining a private 
>> group to send to (which mean that if more than one publishing party should be 
>> able to participate in the feed, rosters must be distributed between all 
>> sending parties).
> 
>   Yes, but you subscribe to the 'service' provided by the service.  ;-P  Note, 
> you may also allow the service to subscribe to you, but not subscribe to
it.  ;-
> P  There are really 4 levels of subscription.  To, From, Both, and None.
> 
> 
>> The logic of the presence mechanism - but applied to messages, would be a 
>> more well designed solution to this feature; sort of like a mailing list 
>> functionality in Jabber (with both half and full duplex). 
> 
>   Yes and no.  I've actually written a mailing list transport that does
exactly 
> this.  It recieves a message destined for a list.  It looks at everyone who 
> is 'subscribed' to that list, and mirrors it out to all parties wishing this 
> data.  In this case, the data being transmitted was generated from internal to 
> the jabber system.  It could have just as easily been generated by the 
> transport form, oh, say a news or stock feed.

Has this bean relesed or is it an internal project of some sort?

> 
>> Is this being thought about, is there any plans to implement such 
>> functionality, or is it there already, without me being able to find it? Is
>> it possible to interpret and use the groupchat functionality for this?
> 
>   Can be, and is very easily done.  The possibilities for the system are 
> staggering, and the documentation as of recent, *BESIDES* the JPG (Jabber 
> Programmers Guide, has been lacking.  The JPG, http://docs.jabber.org/jpg/, is 
> a good overview from the world according to the client.  Check it out, it may 
> help a bit..


I have read every bit of information I have found, including the JPG. What
 I basically find is that the internal API of the server is documented 
"somewhere else...", and there fore I hava eonly had the client protocoll 
to extrapolate my understanding of the server from (which I might have 
missunderstood...)
> 
>   Sorry if this reply basically sucks.  Just been a busy day, and didn;t have 
> to time to reply correctly, but it needed to be replied to..


No, it was a good start. But lets see if we can get somewhat further...

(And excuse me for my broken english, some of the thoughts extressed here is
 my real thoughts, some of them may be expressed in a distorted way ;-))

//Peter Antman

> 
> --- 
> Thomas Charron
> << Wanted: One decent sig >>
> << Preferably litle used  >>
> << and stored in garage.  ?>>