Hello to all, my name is Eduardo and i'm working @ PT Inova
Very good diagram. It illustrates one possible solution.
I think that your original argument for independent protocol handlers will result in better architecture though.
Instead of having one root SBB for the presence service, that works with all protocol events, it would be cleaner if there are two independent "translating" services. One for SIP and another for XMPP. Plus another Presence Service with its own root SBB which understands higher level events. Protocol specific services will talk to the generic presence service via this higher level API (as think Norbert suggests).
Ranga illustrated this design as having each protocol dependent SBB put a higher level event on a named activity context that actually does the presence processing.
Am I making sense? If so, can you please update your diagram to verify that we are on the same page?
Now that you have developer access, feel free to upload to the files&docs section.
I also got the similar assignment i.e. developing a Presence server but using XCAP.
In the XDM architecture, I could see a "Subscription Manager" (https://openxdm.dev.java.net/servlets/ProjectProcess?tab=2) , which I hope will do some of the processing of Presence stuff.
May I know what will be the role of Subscription Manager and how it can be used in making the presence service using XCAP.
> Well, I thought to separate the actual protocol differences because if someone wants to add a new protocol it would need only to build a SBB that deals with that particular protocol RA and with the generic presence service SBB.
This is a very important advantage. I can see why there would be interest for integrating RAs for legacy protocols such as SS7 or H.323. These should be possible to build and plug in optionally without affecting the generic presence server.
Ok, I made a new diagram regarding Ivelin's ideas, which breaks the Presence Service to 3 *components*. You can check it out @
This possibility for the final architecture is close to what I first thought but some people argue that one service - presence - should have *only* one Root SBB. The way I see is this are 2 services, the generic presence service and the specific presence protocol translator, the first can be reached from SLEE directly and from network, using the service the second provides.
Please tell us your opinion.
Looks great. What tool do you use for these diagrams? I've been using Magic Draw (when the spirit moves me to make such diatams that is ).
I have been using an old version of Sparx Enterprise Architect, you can try a trial at http://www.sparxsystems.com.au it's not a diagram draw tool, it's a full developer tool.
Ok, check this diagram @
This is my idea for the architecture, it supports all parts (User Agent, Wacther and Presence Service) to be in or out of SLEE. The agent's root SBBs decide (based on configuration or self discovery) if they use RA or the SLEE SBB child for the service.
I will implement, at least, the Presence Service and Watcher parts.
Let me know of your thoughts :)
Just some comments. I would of thought create a JCC/JCAT RA that is able to handle both SIP and XMPP. Not sure where JCC/JCA RA is at right now, but that would bridge the two protocols.
Hi and welcome,
Why not a single Sbb for both RA? With two event handlers - one for each RA.
i.e. onXMPPEvent and onNotify ( for SIP )
Dont know if that makes sense but I thought I'd throw it in as food for thought.
Well, I thought to separate the actual protocol differences because if someone wants to add a new protocol it would need only to build a SBB that deals with that particular protocol RA and with the generic presence service SBB.
Just want to flesh things out a bit more.... What do you envision the root sbb of the presence service looing like in this case ( what would be its convergence name)?
Message was edited by: eduardomartins
Hello I have to deal with a similar problem.
(Please note I am relatively new to SLEE area)
There will be a service which has to handle different "legs" with different protocols. Approach is to have one service SBB controlling the whole thing and which uses childSBBs for the different "legs" protocols. So there is one protocol SBB per leg, which means one childSBB per RA. The protocol SBBs have to deal with all protocoll messages and communicate with the service SBB via a "higher level" API, here I hope application defined events could be used or also the local interfaces of the SBBs. The protocol SBBs should be potentially used by differrent service SBBs too.
In my service example the initial event is a SIP INVITE. To make the service SBB the root SBB my idea is the following:
The service SBB assigns for the INVITE, but delegates further processing of the incoming SIP leg to a SIP childSBB (creating SIB child, attach childSBB to incoming AC, childSBB will get then INVITE too, and then informs the service SBB via the "higher level" API about the service incarnation). It is up to the service SBB then to create further child SBB(s) and RA for outgoing legs then.
So basically this approach is in line with eduardomartins approach.
Any comment is appreciated.
Well actually I was thinking in a diferent base SBB for each RA and then a common Child SBB using a high level API (PAM?) for the service.
You would need a common root sbb. That common root sbb can have a custom convergence name that returns the same string whether it sees an XMPP event or a SIP presence event. Then delegate to the appropriate child sbb for handling each protocol.
Rough thoughts... maybe another approach will work better.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.