tisdag 17 juni 2008

Unified messaging based on WLCP

This post is a theoretical discussion on how to design a unified communications applications based on BEA WLCP product suite. I welcome all feedback and comments, how would you solve this problem?



The problem at hand is how to create an application that is able to send a message to a recipient in several different methods and how to receive messages on all kinds of channels and deliver them in the preferred method to the user. For example I am traveling and want all IM, SMS, MMS, PTT, etc send as email for me to view later on when I reach my destination.

The protocols supported are in this case SIP (MESSAGE and SIMPLE for IM and PoC for PTT), SMPP, SMTP/POP, MM7. It could potentially be extended with SS7/IN support for receiving calls and recording the message as an audio clip.



The solution is quite simple, although using quite some number of BEA products. Parts if not all could be solved using open source for smaller installations, but I am after all selling great stuff and we are talking Tier 1 telco's and not small garage companies.

The User Interface: The user has to be able to configure his/her preferences using a web portal interface. Using portlets allows inclusion into existing portals. Through the portal the user can configure all contact mediums including phone numbers, IM accounts, email accounts etc. The user also sets the preferred communication method. All configuration is stored in a database.

Service execution: The service executes in WLS, WLI or WLSS depending on what type of environment. I would for example run it in WLSS if it is mainly executing in an IMS environment. When a message is received the system checks which user this is and which is the preferred communication method (email, SIP SIMPLE, SMS, etc). Then the message is sent to WebLogic Network Gatekeeper using the ParlayX sendMessage standard WebService API. Quite simple application actually. It can be written in a few days or even hours for the most simple case as a proof-of-concept.

Message broker, policy enforcement and network connectivity: WebLogic Network Gatekeeper, WLNG, exposes standards based telecom webservices to third party applications. These applications can be executing in the operators domain or totally external in the third party partner's domain. WLNG is able to expose these WebService interface, it also applies very complex SLA and policy checking before sending the message. This allows an operator to protect the network, prioritize traffic and enforce that SLA's are applied. Once WLNG receives the message it looks at the protocol or number and decides which protocol to use. After passing the policy check the message is sent to the destination using the right connectivity. This includes SIP, SMPP, MM7, OSA/Parlay, SS7, SMTP, etc. SIP is supported through invoking the WLSS. It is also possible to write your own plug-in connecting to your network resource of choice.

IMS Env: In an IMS environment then I would put the service logic in WLSS and invoke WLNG from there for all non SIP events assuming that there are mostly SIP events coming. Then you don't get the policy enforcement unless you put WLNG and exposes the ISC interface directly through WLNG applying policy protection. This could be quite cool, but is a topic for another post.



Conclusion: Standards based telecom WebServices can be used to create very complex and advanced applications using WLNG. Other BEA products can be used to realize the portal and service execution part. There are several nice things with this solution, I will try to list a couple of them here:

  • Complete policy protection of what your applications are doing with the network

  • Network abstraction from the service logic point of view. It only gets an address from the database and WLNG takes care of figuring out which network resource to use depending of what's in the address

  • Independence of service execution environment. It can be .Net, Java, JEE, Ruby, whatever

  • Push down logic from application to service infrastructure





Will this work? Yes! Is it the best solution? If not the best, so there are not many that are better. Is it the simplest solution? No, there are simpler ways of doing it, but then you loose some flexibility and openness. Does it have enough performance and low latency? Yes, no doubt. WLSS and WLNG are very low latency, highest performance and are scalable to handle very high loads.

Inga kommentarer: