Myths About Network Intelligence

Today ICIN 2008 started with revealing some myths about network intelligence. Roberto Minerva from Telecom Italia has been working with network intelligence for quite some years and collected eperience from what to avoid when dealing with network intelligence.

The topic itself is very interesting and especially the angle taken by Roberto where he uses the Anti-Pattern pattern. Looking at solutions from the other angle than usually gives you new views to an area and opens up for new thoughts. This is what I experienced during the talk.

Roberto had identified the following Myths:

• Network Transparancy
• Network abstraction hides information. In worst case the hidden information prevents further development of services using other features not exposed by the abstraction framework.
• Solution to Network abstraction is to introduce a flat architecture with a gradually increasing level of abstraction. Thus a service can use the highest abstraction level interface possible still meeting the feature needs. If a more finer grained interface is needed that is available by other interfaces in the flat architecture. You could view this as a stair of abstracted interfaces.
• Open API
• Today Open APIs are focused on call control or messaging type of interfaces
• Look at the importance of data and data representation. Google's main business is profiling and collection of data in order to provide targeted advertisements.
• Network with Quality
• The QoS issue impossible in network of networks
• Look at P2P where the intelligence is in the edge.
• Data Networks and Services it is hard if not impossible to keep the network quality promise (or SLA).
• Cloud computing and WebOS was brought up by Roberto. WebOS could very well be sticky service many operators are looking for.
• The Need for Centralization
• IMS and SDP is traditionally seen as a winning proposition. These are centralized solutions.
• Google and Amazon are reinventing the service platform concept and are exploiting the Client-Server paradigm much beyond what an operator could do.
• Operators can use WebOS and P2P much more to create a decentralized network providing sticky services.

Presence Zone for Contextual Presence Location Information

Presence Zones Enriched Location data with contextual information. 

 

Presented by IBM research in Haifa. They have run a research project trying to enhance presence information by adding context to the location where I am and then set presence status based on that.

 

The concept is based on defined zones with certain attributes. There can be automatic zones and there can be zones set up by a restaurant that pushes out information about menu and offers together with presence info. A zone can be identified using different location technologies like GSM triangulation, cell-id, GPS, Bluetooth, RFID and generic near field communications.

 

In the case of a restaurant owner he puts in a bluetooth device that identifies guests as they enter and leaves and sends that information to the presence server.

 

On top of this enhanced context aware location information there can be applications created that utilize the automatic presence information. The most obvious example would be enabling end-users to create their own mashup between presence and other sources like restaurant guides, astma information, etc.

 

Other applications can be call routing, pre-call presence information, targeted advertisements, offers, quiet zones and what-have-you.

Opening Interfaces - Impacts on Telco Business Models

This morning at ICIN 2008 starts with a panel discussion on opening interfaces and how that impact the business models of the telco operators.

The panel is led by Kristofer Kimbler and consists of Roberto Minerva, Agustin Nunez, and David Pecota.

My key takeaways from the panel disussion:

• Operators are already open, however they want to charge from the beginning limiting adoption. Contract management, charging, payments (between operator and developer) and security are factors in the mind of the operator.
• How to charge? Look at the business model of iPhone applications which enables ease of payment transfers between buyer and vendor.
• Global access to the open APIs is crucial. Here Google and iPhone serves as good examples.
• Open interfaces is happening today through Google Maps for example
• Presence, location, social networks: traditionally the telco has provided this. Today the internet is leading innovation, development and adoption.
• The customer for open interfaces is the developer. Developers are lacy. Make the interfaces easy, global and simple return on investment (payments).
• Customer data and profile information is a unique attribute of the operator.
• IP models on top of existing legacy is the unique heritage of the telco operator. Pure internet players don't have this which simplifies life and provides global access and availability.
• Operators should define themselves as the enabler of the social network, not telephony or access.
• Enterprise applications is an easy market to target today where the end customer is ready to pay and sees a direct value. Discussed Dentists and other healthcare providers. Microsoft providing enterprise services through Exchange server. Going beside the operator avoiding tricky business models. Voice capabilities in the enterprise market
• Business model and common API's today:
• Skype for Salesforce
• Marketsize and availability of enablers and APIs
• Don't fight the internet

I think the panel discussion was interesting and also highlighted the challenges. The telco operators really need to transform themselves in order to catch the opportunity.

Kill your darlings - The death of the Killer Application

We all knew it, the "Killer Application" is dead. What is there to replace it?

During ICIN 2008 a common theme so far is the need for open telco operators providing services for various kinds of mashup. This implies that the search for the next killer application is dead. The open telco should provide services to its customers. It is unclear so far which services the operator should provide and how to charge for the service.

From my point of view the question is wrongly asked. A better question would be "What do your customers need? What would simplify their life?". Opening up the telco only helps if you know what your customers will need to use. The opening of the telco itself is more of a technical exercise than of anything else. It is however important as a foundation for execution of an open telco operator enabling colaboration with external innovation and development. How do you get to know what your customers needs and wants?

One way that I have been experimenting with is to open up labs or trial areas where the operator and customers can collaborate and play with open services. By tracking what becomes popular an operator can focus efforts in that area to provide quality of service, security and the appropriate business model. With a thorough follow-up and evaluation of how services are used a greater understanding of underlying drivers and motivators can be understood. From this point the operator can evaluate which services to open, business models, bundling and alignment to strategy and vision. It is extremely important to be in line with your strategy and vision otherwise customers will be confused and/or there will not be a continuation of the process due to misalignment of strategy.

Another important aspect of opening up telco operators is to provide billing and CRM functionality supporting personalization and business models. Being able to personalize customer offers helps being relevant and meeting the individual customer. Supporting different business models is critical in enabling flexible payments and bundlings of services. Who should pay for the open services and how? Flexibility here enables advertisement and someone-else-is-picking-up-the-bill business models.

In short: The Killer Application is dead, it's time to open up the telco. In order to succeed you need to know your customer and what he wants. Flexible billing supporting business models and payments enables a sound business for all parties.

Why are everyone talking about SDP or Service Delivey Platforms?

During a dinner yesterday I called SDP dead as it is not a generic component. It is rather a philosophy on how to deliver services than a ready steady platform. So from now on it is more correct calling it SDE, Service Delivery Environment, or SDF, Service Delivery Framework, as TM Forum.

Listening to ICIN 2008 Keynote speakers David Pecota, Microsoft, and Augustin Nunez, Open Movilforum, they focus on how to deliver services to customers. David was talking about the converged lifestyle. Users are using telecommunictions in all kinds of possible ways thinkable seamless over telco networks and internet. Delivering services supporting a converged lifestyle means that a service should work across networks and services should be aware of each other. The question is what are users ready to pay for a converged lifestyle?

I think that Augustin was spot on when answering the question with an open telecom transforming from channel to the open sea. Users are not willing to pay for the converged lifestyle itself. However, they will use the open telecom services/enablers to mashup new services. As they are doing this and paying for these mashed-up services they are actually creating the converged lifestyle. So the answer is to expose the different services like IP-TV and let the users create the convergence and inclusion in their lifestyle.

Low cost to fail for which convergence is actually asked for and customer willing to pay for.

ICIN 2008 To the Hilt

After months of preparations writing papers and presentations I'm finally at ICIN 2008 ready to present in one session and one poster. The titles are:

• Agile IMS Service Composition - How to Quicker Respond to New Market Demand
  
• Loyalty Based Customer Interaction - Driving More Revenue From Your Existing Customer Base
  

It is very interesting being at a show where everyone is very skilled and knowledgeable.

Key to the telecom industry is to view itself not as a telecom industry anymore. If it sees itself as telecom it will become a pure datapipe. The key is providing the right services (the multimillion dollar question) using the right architecture (providing foundation for execution of the business vision and strategy) enabling users making an impact (in their lives simplifying social relationships). 

We will see what is said on these and other topics during the conference.

Automagic Presence Awareness, Why?

Wouldn't it be nice if my presence status could be updated automagically? Whenever I do something the network somehow is aware of what I do. My presence information would then be automagically updated.
The problem is that when we get more and more gadgets that is aware of my presence status or that subscribe to my buddy-list (for one or another reason) the task of updating presence status gets overwhelming. This will in itself limit the actual usage of presence information outside today's Y!, MSN, etc. With a way to automatically have applications being aware that using the applications have a specific presence meaning. Then I am relieved from the task of keeping my presence status updated all the time and that task is handed over to software to do it automagically.

Before you say that this is really not what I want, let's list some good things that this would enable:

• Gadgets can update the rest of the world with my presence status automatically.
• My buddies will have my correct presence status.
• With a more correct presence status other applications can emerge that make use of the new trustworthier information.
• I don't have to bother about continuously updating my current doings.

First let me give you an example of what I mean:
In today's world my PC is aware of when I'm using it and sets my status to "Available" when I'm using it and to "Away" when I have not been using it for a certain amount of time. The next wave would be to have my phone company set my status to "On the Phone" when someone calls me and similar applications like Video-on-demand. What would be of more interest is if my phone could know if I'm sitting still or moving (in or out of office perhaps) and then automatically update my status. Or if the game I'm playing could let people know that I'm actually not available even though I'm at my PC. And so on for an endless number of applications.

What is needed to make this happen?
Well, first of all you and I need to ask for this and similar functionality. We are already doing it for Instant Messaging and the proponents of IMS and SIP are hoping we will be doing it for the telecom domain as well. I certainly hope it will become as prevailing when using my phone as it is with instant messaging today. The next step after this is to make presence information as ubiquitous in all applications regardless of domain as it is today in the IM world. To make this happen we would need a couple of things to be in place:

• A configuration repository of which presence status I have when doing a certain activity
• A generic API for applications to access this repository
• Or a mediator that interprets what I'm doing with my configuration in the repository
• Applications and gadgets make use of the repository to publish presence information automatically

As a side note Yankee Group foresees the Anywhere Connected device and as such it would be nice if it could make my living easier and not harder ...

Movement from BEA Dev2Dev completed

I have now moved all entries from my previous blog at Dev2Dev. I will continue here with blogging about SIP (Session Initiated Protocol), SIP related topics like IMS, Multimedia, SCIM, JAIN SLEE, Mobicents, Sailfin and telco related business development. Stay tuned!

Is Free the next Killer Business Model?

When you use Skype to place a call to your mother on the other side of the earth or across the street it is free. There are no costs for you, not at least upfront. When you sign up for a 18month mobile phone plan you get the phone for free. When you search the entire web for information, pictures or news you don't pay a dime.



These services are just a couple of examples of services that are free for you to use. They all have in common that they somehow are touching digital and thus the price goes towards zero, becoming Free for the end user. Of course this is not the whole truth. Someone or something is paying for the lunch. Usually this is advertising. It could also be part of a bundle where you buy one thing and the rest for free. It can also be someone else who is picking up the tab to reward you for loyalty.


Will this be the future killer business model? Everything becomes Free. That is kind of contradictory, how can gratis be a business model?



The UK based MVNO operator Blyk have already proven that being Free is successful. Now Blyk is not entirely Free. They have a great combination of stringent segmentation, good service level, compelling advertisers and additional services that have a cost.


Which billing systems or application platforms for that matter allow charging based on ads instead of per use? If I am an application vendor then I would like to be able to hook into Google AdWords to generate the ads for this specific user and then relate the provided service to a specific entry in Google's invoice. Can I please get this Now?


Done correctly, providing services for free will greatly increase the availability of telco type of services since there is always a way of getting paid. It will enable The Long Tail of applications to be affordable for a much larger group of people and thus drive adoption. Today a lot of people do not dare using services since they don't trust the way they are charged. Thus it greatly limits the number and types of services brought to market. Introducing Free as a concept paid for through other usages will enable a vast number of new applications and services and thus Free is the next Killer Business Model!

Is SIP dead?

Is SIP dead?


Well some people say so, the future is pure IP, HTTP, REST, AJAX, Web, etc. There is no room in that picture for a protocol related to session control. People will find other ways of accomplishing that using existing common web protocols.


Yet other people look at SIP from the call control point-of-view and think of it as a failed protocol since the vast majority of all calls are still placed through legacy call-control protocols in the SS7 family. They look around and see no SIP anywhere.


Are these two views true or false? Well, neither I would like to say. User Generated Content and User Generated Applications are to a large extent one of the key driving forces for many operators. How can they use these to generate new revenue? Exposing REST based call control interfaces does not help in actually setting up the call itself. On the other hand, having several media resources involved in the delivery of a service is quite daunting using traditional SS7 if at all possible. Especially if the delivery involves new and legacy terminals across domains outside of the operator.




Let me take a few examples that I'm aware of where SIP have actually helped in increasing the service level and also generated increased revenue.


Network Norway is a Norwegian service provider focused on enterprises. They had the challenge on how to deliver their services across IP and SS7 domains with the same service level, functionality and cross domain calls. They chose to use BEA's partner Gintel to deliver a SIP based solution connected with both SS7 and SIP networks. Thus they can seamlessly deliver the same service across all domains without any service interruption. More info here about the solution: Gintel References.


SCIM is a very good example of the value that SIP provides. Service Capability Interaction Manager, SCIM, allows an operator to flexibly and without any reprogramming create new service combinations from existing service assets. The major differentiator is the mechanism in SIP that allows the message to traverse from service to service each making its own changes to the SIP message and then marking the SIP message for any future participation in the session. Thus a SIP message can visit many different services while being set-up. By introducing a SCIM an operator can easily enable fast service combinations to meet short term opportunities. A capable SCIM should also be able to connect to legacy SS7 networks and involve many different kinds of services in the session setup without affecting each service.


Second Life is a great virtual world. While many people use it to play a different life than what they are doing in this world, it wouldn't be too bad to communicate IRL (In Real Life). Telecom Italia's Alice island has a way to communicate between the first and second life. You can use a gadget called First Life Communicator in order to call between avatars anonymously. The call is placed through ItalTel's Telecom Service Box, TSB, which can be invoked through Web Services and connect to different kinds of network elements. By using SIP and SIP Servlets TSB can seamlessly connect to differnt networks. Through the Web Services exposed it is easy to create mash-ups such as the one with Second Life. I would call this a very elegant way of combining Web 2.0 User Generated Applications with seamless network access. For those of you who wants to read more on the subject, here's your salvation: http://www.italtel.com/allegati/events/the_service_box.pdf




One might think that these examples are just small and irrelevant. Well, in one way they are, in another way they are the sign of real change within the telco industry. Smaller players are innovating and creating new services that are similar to the existing, but when using new types of technology they can create some astonishing results. Like a tidal wave I believe it will hit the industry and change it from the bottom up.


What is the major driver for this? I believe this is the death to stove pipe solutions and the emergence of SOA and convergence among all kinds of services. I want my services to be able to participate in the same session regardless of when they were created and which access they use. With ad funded services and personalized advertisements the advertizing industry will not accept anything else than cross-service behavioral. SIP is an excellent technology for reaching that goal. In combination with a SCIM it gets too good to be true.

What is the future of MobileTV?

I have been asking myself a couple of questions lately:

• When introducing a new service or product, what are the main success factors?


• How is MobileTV fulfilling these success factors?


• How could the future of MobileTV be look like?

I got some interesting insights and learned a few lessons about success factors when listening to Yanke Group's CEO Emily Green at a luncheon in Kista hosted by Mobile & Broadband Showcase at Kista Science Tower on April 23rd. I will here shortly refer to these success factors and see how they applie to MobileTV. You can read a reference from Emily here: http://www.yankeegroup.com/Sweden.do



First, let's start with Yanke Group's definition about key success factors:

• Does it meet a basic human need?


• Does it liberate the user?


• Does it remove, not add friction?


• Can the user sell the story?

You can rate a new service on each of these attributes from 1-3 and then sum it up. If it reaches at least 10 then it will probably become a success.


As you can see the main message is if it meets and relives people in their daily life and if the service is simple to explain to others. Then you will create satisfied users with a viral effect that will drag in new users.



So how does this applies to MobileTV? Well, there are at least two forms of MobileTV that I'm aware of:

• Terrestrial which is similar to today's TV which is broad casted. The main standards are DVB-T (used today for normal TV) and DVB-H (which is DVB-T adjusted for the handheld, backwards compatible). This technology uses separate infrastructure as compared to the wireless network.


• Streamed which is stream over a wireless broadband connection. Allows multiparty communication and interaction between end-users and content provider. Personalization of contents like VoD, Podcasts, advertising is possible.

Basically both technologies sends moving images to a hand held in real time, however the user experience is like traditional TV in the first case but on a very small screen and personalized and unique in the second case. Let's have a look at the success factors now to compare these two different MobileTV technologies and see if any of them may succeed.



Terrestial

• Does it meet a basic human need? Yes. Points: 3


• Does it liberate the user? Well, kind-of. Points: 2


• Does it remove, not add friction? How useful is normal TV on a small screen? I would say no. Points: 1


• Can the user sell the story? Who would tell their friends they have just seen Simpsons on a 2 inch screen? No. Points: 0

Total points are 6. Probably not a success.



Streamed

• Does it meet a basic human need? Yes. Points: 3


• Does it liberate the user? Yes, you can watch what you want wherever you are. Points: 3


• Does it remove, not add friction? Removes place and time. Integrated with IPTV and it would be a hit. Points: 2


• Can the user sell the story?Yes. Points: 2

Total Points are 10. Probably a success.



What do I think of MobileTV? Well, I am after all full of SOA methodology and thinking. I would therefore think that a Stream solution with full SOA integration which allows me to access content regardless of device would be the most effecient way of securing user success. If I have watched a trailer for a move on my way home I would like my IPTV to suggest that or similar movies. If I have a Fiat car I would like my Fiat ads to be displayed on both my MobileTV and my IPTV channel. Integration seamlessly regardless of device that is what I believe is the key success factor from a technology standpoint.

Why can't I get a cold beer when it's hot outside?

I attended a lunch today hosted by Sweden Mobile Association in Kista Science Tower where Emily Green, CEO of Yankee Group, presented and fueled a very interesting discussion among all participants.



My general takeaway from the lunch was how I can get my fridge to know when to order more beer so I always have cold beer when it is sunny outside. And barbecue of course to feed the hungry.



It seems like a stupid question, why would anyone care. Why not fill up the fridge with beer and drink it when the sun is shining (just open your eyes, stupid, if it's bright, the sun is shining, no need for complex solutions to simple problems ...)? However the interesting fact is that with more and more gadgets getting connected wirelessly this is exactly what can happen. My fridge will know what I have in it through the use of RFID tags. Since the fridge itself is connected someone (like me or my shopping agent) can check what it contains. Mashing that up with a weather forecast service and you can consider the beer as cooling down already.



Generalizing a little bit everything that can be empty makes sense to connect. Then someone can use that information to act. The fridge is just one example.



So what's in it for an operator? Well, what if they provided the fridge with this connectivity and offered it as a RESTful service for you or anyone you trust to utilize? Then they can charge not for the connection itself but rather for the possibility of letting you or your agents to innovate on this information.



The key is that the operator opens up their closed environments and creates the foundations for such unknown innovation. Let the spirit of the internet cross-fertilize with the seamless always-accessible infrastructure from Anywhere.



I kind of like the thought of a cold beer ...

Mobile World Congress, here we come!

Finally it's time for Mobile World Congress in Barcelona. I have prepared my contribution in the form of two demos covering Web 2.0 and Service Capability Interaction Management, SCIM.

• Web 2.0 shows how one can use WLNG to create a mash-up between Google Maps, Facebook and Location information from the telco. A very powerful and easy way of have end users creating and sharing applications with real-time telco content. It is hard to do technically since it requires quite a lot of security, policy and SLA enforcement which is exactly what WLNG is good at.


• Service Capability Interaction Management, SCIM, shows how to combine an incoming call with legacy SS7 PrePaid, SIP calls to WLSS, and WebService invocation of an IPTV system. the end result is a PrePaid user who calls a friend while the friend is watching a VoD session. Depending on the settings the caller id is displayed, the call is rejected or sent to voice mail. BEA is doing this demo in cooperation with Convergin

Apart from having the demos done and ready I've prepared all my meetings with existing and new customers and partners. The agenda is quite busy, but I hope to see something interesting to share with you all during the week.



There are quite some rumors going on in the industry. Will Oracle do a big push, which new phones are announced from Nokia and SonyEricsson, how will IMS evolve and what will be the main theme?
Personally I think we will see a lot of video in the form of video sharing (YouTube etc), IPTV, MobileTV, etc. Web 2.0 and communities/user creation will probably also get some attention. How will the operators react?

Did I mention Oracle? Oopppss, should not do that ... anyway I didn't say what I think about the offer and what the future roadmaps will look like so I should be safe ;-)

IMS/SIP support in the new release of WLNG

BEA released a new version of WebLogic Network Gatekeeper, version 3.0, on July 16th. One of the new features found in that release is support for IMS ISC interface in particular and SIP in general. Why is this good?



It is good for several reasons. It allows WLNG to protect not only legacy enablers but also IMS enablers such as presence, location, and call-control. When WLNG exposes a ParlayX interface like CallControl's setupCall it can go through either legacy IN/SS7, Parlay gateway or IMS network. BEA WLNG now supports all three methods hidden from the end user. WLNG determines through the advanced policy check that the right network is used for each leg in a call. How does it work?



In the policy engine a decision is taken on which network plug-in to use depending on factors like load of that plug-in, numbering plan, which numbers are handled by which part of the network. For example if it's a SIP URI then the policy engine return a SIP plug-in. The plug-in basically forwards the message to an embedded WLSS instance that comes with WLNG. It sends the SIP message and handles all interaction with the SIP based network and then returning the result to the plug-in. How can it connect to SS7 then?



The nice story here is to use Convergin Accolade WCS SIP based SCIM and IM-SCF. Then the SIP based call gets transformed immediately to SS7 by Convergin Accolade WCS. WLNG thus makes real use of WLSS and Convergin providing the needed functionality in a future safe and migratable manner. All this is totally hidden from the application. It just invokes the ParlayX call-control interface and which network that is invoked is irrelevant to the application. Utilizing Convergin Accolade WCS in this environment allows it to be used as SCIM, IM-SSF and IM-SCF in pure SIP application execution from WLSS. Thus using a combination of BEA WLNG and Convergin Accolade WCS enables operators to at the same time protect their network and also expose these services through telecom web services and get a cohesive management of the complete solution.



Not to forget is the importance of continued protection of the IMS/SIP based services through applying advanced policy control, partner management and monitoring. It is easy to forget such important parts just out of pure pleasure working with WLNG ;-).

Programming model vs Connectivity or SIP Servlet vs JSLEE

Confession: I like the SIP Servlet way of doing things!

I will try to list some of the reasons and my arguments supporting my choice. Let's see if I succeed ...



First of all: Programming model.
OK, I admit that I like the SIP Servlet programming model a lot. It's specified in JSR-116 and JSR-289 which is due to release in Nov 2007 which means it took less than 2 years to complete. Not that fast, but still quite OK. Why do I like it? My background as a J2EE developer and architect is of course quite influential. I like the HTTP Servlet programming model. It's easy to understand and implement and the same applies to SIP Servlets. The threshold is low for beginners, especially if they are used to HTTP Servlet programming. When you write simple applications, they are really easy to develop and maintain, an important aspect in modern software development. When the applications grow they will of course be more complicated. For really advanced applications, the model can get in the way since there are a lot of events happening and you need to remember in which order they occur. It would not be too bad with an even higher abstraction layer above SIP Servlets. How that should look like is another question ...


When I get into these kind of problems I usually move my application into Spring and use the SIP Servlet as an adapter. I honestly don't think it's so much the SIP Servlet model as my own ability writing clear understandable code. Spring gives me the inherent support and is guiding me in creating code that is beautiful in the same way as it helps J2EE getting better.





Support for the SIP Servlet programming model has been growing lately and now all the major vendors have support for SIP in their application servers or it is in their road maps. This includes IBM, Oracle, Sun, Ericsson, Ubiquity and others.



Secondly: Convergence with existing JEE environment
In the spec it is defined how a SIP Servlet should work in conjunction with HTTP Servlets and EJBs. This allows for a converged standards based container. It basically just adds another container to the plethora of containers available today in a J2EE server. Since the spec is so similar to the existing servlets it is very easy to integrate it with existing enterprise Java applications or any WebService for that matter.



Thirdly: Separation of connectivity from programming model
Connectivity is an important part of any telecom application. SIP Servlets and especially the container hosting the SIP Servlet, in this case BEA WLSS, has a number of standard ways to connect to various sources. These methods of connecting to resources are not dependent on the programming model as such and they are independent of the programming model. The main advantage is that it enables the developer to select the best programming model for the needs at hand, the best connectivity standard for the task and thus leads to an open and flexible non-vendor lock-in solution.


For example I can create a SIP Servlet that sends an email for every SIP Message received. I create my SIP Servlet and then uses Java Mail to create and send the mail. This is a standard implemented by WebLogic Server.


Another example is that while setting up a call I can check the caller against a black-list exposed as a web service. Once the initial Invite is received a call-out to the web service is done. Since I have the WSDL a client stub is created in BEA Workshop (or any other modern IDE) with a few clicks.

Final example is the opposite, exposing SIP presence information through a web service. A web page wants to display the current presence information for a specific user. A SIP Servlet is created and then exposed as a web service. The Web page invokes the web service and the SIP Servlet gets the presence information and returns it to the Web page for display. With BEA WLSS this is done with a few clicks and the SIP Servlet is exposed as a web service.



Fourthly: Standards based
SIP Servlets are standardized in JSR-116, JSR-289 and then there is a Media Server API being standardized in JSR-309. All other connectivity methods are also standardized in JCP or elsewhere. JSLEE have JSR-240 and standardization of the resource adapter interface is not yet done.



Fifthly: Inter and Intra Container Service Orchestration
This is actually not an argument for SIP Servlets in general, more for BEA WLSS since we are partnering with Convergin. Through Convergin Accolade WCS in combination with BEA WLSS a customer gets a complete migration path from today's service execution to tomorrow's All-IP based services. Services can be developed today using tomorrow's technology and be exposed to legacy, pre-IMS and IMS networks. The same applies for existing legacy services that can be exposed through legacy adaptor capabilities of Convergin Accolade WCS. In conjunction with the exposure of services to different networks, we are also able to do advanced Service Capability Interaction Management, SCIM, where blending SIP with IN/SS7 and SOA services into a complete complex service adds yet an advantage. This is not part of the SIP Servlet spec, but is possible through using the SIP protocol in combination with proprietary solutions in the case of SCIM. IM-SSF is standardized through 3GPP.



Sixthly: All-IP and IMS
If you are an operator and have an All-IP and/or IMS strategy it feels quite natural to select an execution environment based on the programming model, maturity of container, existing installed base etc. Then the SIP Servlet spec fits very well into an All-IP strategy since it features all best-in breed attributes and with a clear path towards IP-based services. With a combination of BEA WLSS and Convergin SCIM we can offer a very fast, low latency, fast-time-to-market through efficient programming models and tools, a complete SOA vision and a broad range of partners. For more info on the BEA and Convergin cooperation please read this press-release: http://www.convergin.com/show_flashpr.php?docindex=pressdocs/pr18_20061207.swf



Well, enough said on this topic. Now you know why I like the SIP Servlet standard and my current understanding. Obviously I may have misunderstood things or missed important aspects of other technologies. Please don't hesitate to comment on that :-) As you also may have noticed I haven't talked directly about JAIN SLEE in this post. The main reason being that I don't want to talk about something I don't know as well as I know SIp Servlets. However, the arguments for why I like SIP Servlets should be understood in the context of JAIN SLEE and my arguments in this post are thought of being indicative for why SIP Servlets have advantages in these areas.

WLCP products in new releases

As of July 17, 2007 the core products of the BEA WebLogic Communication Platform geared for the telecommunications network are available in new versions. In the following you find the most important capabilities for the BEA WebLogic Network Gatekeeper and the BEA WebLogic SIP server in an overview.



BEA WebLogic Network Gatekeeper 3.0



The BEA WebLogic network Gatekeeper (WLNG) 3.0 is a "Major Milestone release". Main innovations are the complete revision of architecture and the associated migration into our JEE environment (WebLogic server) and the smooth integration of the SIP server for possible binding to SIP/IMS based networks. Here is an overview of some the new features of the WLNG 3.0:

• Final migration into a JEE architecture (based on BEA WebLogic server 9.2)


• Support of IMS and SIP networks by the integration of the BEA WebLogic SIP Server 3.0



• Improved Telecom Web services with Parlay X 2,1 support and WAP Push
  
  
  
  • call control: 3rd party call control, audio call, call notification, call handling
  
  
  • Mobility: Terminal status, terminal location
  
  
  • Messaging: SMS, MMS
  
  
  • Presence
  
  
  • Payment
  
  
  • WAP Push
  
  
  
  
• Improved High Availability and Reliability by the proven Clustering -, load Balancing and Failover technology of the WebLogic Server


• Improved OA&M Framework


• Extended Policy Enforcement with geographically distributed SLA enforcement


• Externally callable Policy engine


• Improved developer support by a new Creation Environment Suite


• Docs: http://edocs.bea.com/wlcp/wlng30/open/index.html


• Download: http://commerce.bea.com/showproduct.jsp?family=WLNGSDK&major=3.0&minor=0

BEA WebLogic SIP server 3.1



The BEA WebLogic SIP server (WLSS) 3.1 release is focused on improvements in the support for "Network Address Translation (NAT)" and improvements in the OA&M functionality. Here is an overview of some of the new features of the WLSS 3.1:

• Integration of the WLSS Management Frameworks with the WebLogic Diagnostic Framework


• Substantial improvements for Data Collection, Logging, Tracing, Notifications and Code instrumentation


• Supervision of SIP and Diameter using the administration console


• Support of the RFC 3581 (Symmetric Response Routing; does header support)


• Improvement for SIP Clients in NAT-networks in the handling of Firewalls


• Performance: With JRockit 27.3 (http://edocs.bea.com/jrockit/webdocs/index.html) we have measured significant performance improvements.


• Docs: http://edocs.bea.com/wlcp/wlss31/index.html


• Download: http://commerce.bea.com/showproduct.jsp?family=WLSS&major=3.1&minor=0

AJAX XCAP client project started using SIP Servlet

One of the main advantages with IMS is the availability of user data including presence, location, preferences, status, group list information, authorizations, etc. Through the existence of this data in the network it is possible for all kinds of applications to easily access it and incorporate during execution. A presence application can get my group list from the group list server, get the location and presence of all people on the list and then display this information. The protocol used to fetch such information is called XCAP and is specified in RFC 4825.



XCAP configuration is stored per user in a XML repository. It can be part of another server, such as Group List Management server, or in a standalone XDMS server. You have to know which server the information you want is stored in order to access it. An alternative to this is to use central cache server that gather data from all sorts of repositories and expose that user information as XCAP. It appears to be a XDMS server but does not store the information itself, only acts as cache. Then administrator of the cache configures the physical repository for the information accessible through the cache.



XCAP is stored as XML in the server and is returned as XML in HTTP messages. Thus it is very easy to access the data using HTTP and a XML parser. Only parts of the document can be accessed using XQuery and thus subsets can be sent out when it changes. This makes XCAP very flexible for storing all kinds of user profile information, it is up to the application what needs to be stored.



Since the information is stored in a generic manner, can contain all sorts of user information and reflects in real-time user activities there is a need for a generic XCAP web client that can be reused in several different applications. Since the information changes in real-time inclusion of AJAX concepts is natural. Let me therefore introduce to all of you the Open Source project "AJAX XCAP Client" hosted on BEA Dev2Dev. Please let me know if you want to contribute. It will still take some weeks before we have anything real to show.

Mashing up Telephony without protection?

Now it's time for mashing up Telephony services in the same way as Web 2.0 has revolutionized the creation of web sites. One thing I've learned the last year is that the killer application for telco operators are not any specific application or service. It's rather the possibility to introduce new services fast to market which are short lived or have a small target audience. What Cris Anderson calls "The Long Tail" where selling less of more is the key.


In the Internet domain that means the ability to fast create new sites reusing existing services in new unique combinations and possible a few new services as well. This is called Mashups. Telco's needs to be able to do Mashups to gain the fast-time-to-market they are longing for. One of the main building blocks when creating a new service using Mashup is to reuse existing services, and then WebServices are the most important service building block. Hey, wait a minute, are you saying I should open up my network to anyone who wants to create a service reusing my telco service? I'm not going to do that !!!!



What is needed to allow basically the whole world to use existing telco services to Innovate new services through Mashup is a safe and secure way exposing these services in a standard way. Once that is done these services needs to be secured and have policy control to enforce the Service Level Agreements offered by the operator. Finally we need to actually connect to the network otherwise not much is gained ... although without connection it will be quite safe ;-)


I once read a report from Heavy Reading claiming that 80% of the telco services will be accessed through WebServices. I believe those services will be used in different kinds of Mashups or whatever you would like to call them. At least Mashups are one way of utilizing the webservices exposed and after all this entry is about mashing up telephony.



Which technologies are out there allowing easy exposure of telco services as WebServices enabling quick and secure Innovation of new services in a standard based way? To me the only standard available out there today is ParlayX. I know OMA once tried to do it, but so far I have not seen any major releases from them in this topic.



Who can then expose these services as ParlayX webservices and provide both powerful policy protection and network connectivity? To my knowledge it is only BEA who has the needed solution with a large market attraction with live deployments in all continents. Our WebLogic Network Gatekeeper performs all of these features in a scalable, secure, performant way. After all I work for BEA ... ;-)


Why am I bringing up this topic of Network Gatekeeper here? Since I wanted to highlight a few of the services that won the Telephony Mashup contest I wanted to show you what is needed to actually do Telephony Mashup for real. No telco operator is going to let anyone access their network without proper security and policy protection.



Which services of the winning ones are the best? Why should any be the best? Didn't we agree on that the future is more of less? Shouldn't all services be deployed and having customers decide which deliver the best value? Yes! So I will not have any thoughts of which service is going to win in the market place, it's up to the users. But I still see quite some interesting trends in the type of services reaching the higher positions. The common topic is text-to-speech or other forms of using the voice as control instead of typing numbers on the key pad. Which service can you create with access to basic Internet services like Google, Netflix and YouTube in combination with call, location and messaging from the telco world?



As we say at BEA: We enable Innovation through our inventions. This means that we create technologies and then the community use them to innovate new exciting combinations. Or to be extremely honest, the community creates the standard, we implement it in the best way and combine different community technologies to create something new. As we did with Network Gatekeeper where we combined ParlayX, WebServices, and JEE and created a really cool exposure and policy protection entity that can be used in SOA type of architectures to allow, among others, Telephony Mashup.



My personal favorite after all in the winner category is the SMS GeoBlogging Service from BT. They have basically implemented the Virtual Air concept from Ian Pearson using technologies available today. Which Telephony Mashups do you like? Look at Telephony Mashup Finalists

VON Europe Spring 2007

Today I visited VON Europe Spring 2007 in Stockholm, see VON Europe Spring 2007. It was a very early morning in a sunny and warm Stockholm when the first meeting started at 8.00 AM with a coffee and water (yes, it was very warm) in the bar. It's funny with all these meetings, they add limited value individually but the total mass of meetings somehow magically seems to add up and deliver value. I met with our strategic partner Broadsoft to discuss ongoing deals in EMEA. Since it was VON with its focus on VoIP it was the perfect place meeting Broadsoft.

What we're doing with Broadsoft is very interesting, especially the extendability part where it is very easy to add complementary features to an existing Broadsoft installation. One such thing we're seeing quite some interest in is how to connect IPTV with Broadsoft residential VoIP or IP-Centrex. Many telco's and triple/quad players have Broadsoft deployed and an IPTV offering and are thinking on how to make use of the investment done. Using BEA and our products that comes out as a result of our strategic cooperation solves this elegantly. Of course this can as always be done in several different ways, but our solution is open and adaptable to changing contexts. It's not limited to just IPTV, even if that is what customers are asking for a lot.


Another feature that we enable through our Broadsoft based products is to very easy do Presence Based routing of calls. When a call comes in we can do a presence check and then use the result as a decision point on where to route the call. That in combination with White/Black lists creates a very powerful, yet simple solution and extends the OOTB features provided by Broadsoft.



One thing that disturbs me with Broadsoft and their likes is that they somehow believes that just because they do the best product in one area, it doesn't necessarily mean that all they do meets the same standard. For example, why would I bother using the Ringback Tone solution that comes with Broadsoft? There are numerous solutions out there that are probably better or at least are more adjusted to what the specific operator's customers want. Using the BEA offering allows extending/replacing the RBT that comes with Broadsoft.



Talking about RBT, I met also with Movial today to see what can be done using their client expertise. They have an excellent address book application that is synchronized with a network based repository using XCAP. It works very nice and the repository can be reached from any device and all devices are always up-to-date. What I would like to see in addition to this is a RBT enabled address book that allows me to automatically set the RBT for this person from my address book. This saves me the time to use a browser to update my RBT settings. Suddenly it would become useful and I can actually imagine myself using it.



Apart from this the show was smaller than last year and not many participants. We'll see if it survives next year.

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.

Talking to me?

The telecoms industry is great at inventing technologies, worse at making them useful to a great number of people. Which data services have been really taking off in recent years? In Europe it's SMS, Korea/Japan it's email and in Japan it's also iMode with pictures. And in the US it's to some degree Push-To-Talk, PTT.



Since I'm from Europe I know most about how the SMS industry works. One way of paying for services and content is through premium SMS. You send an SMS to a premium number and get some kind of service in return like a ring tone or similar. In the background invisible for the average end-customer, the SMS is sent from the operator to a system hosted by the content supplier. It handles the SMS and sends back the content as an SMS, MMS or WAP Push.



This is usable to some degree, but still not good enough according to my experience. Older people, disabled, kids, people not used to SMS, etc have problems using it. So why not talk to the system instead? In PTT there are generic channels an operator could configure for different usages like ring tones, weather, sport results, stocks, etc. When you want to use one of these services you simple select that channel och say what you want to do. The system responds with a voice message through the same channel. Simple, usable, not much can go wrong and cheap!



So what is needed in order to realize talking to your customers and they talking to you? Not much actually :-)

• Enable a couple of public channels in the PTT server hosted by the operator


• Write an application using the ParlayX messaging API


• Write a BEA WebLogic Network Gatekeeper, WLNG, plug-in for PTT using the Extension SDK


• Start market the service to your customers!

Now since it is working and your customers can select a public PTT channel on their handset and talk to you. You send back a confirmation and the requested information as voice or through SMS/WAP Push. How does this work?

The PTT plug-in in WLNG works as a PTT client receiving the PTT INVITE message. It redirects it to a media server that receives the voice from the end-user. The voice stream is transferred into voice XML and sent to WLNG. WLNG sends it as any message to the third party application using the ParlayX messaging interface. The application receives the message as text (as in any SMS) and handles it as today when receiving an SMS. The application sends back a confirmation or the result as text. WLNG sends the text to the media server as voice XML and the media server transforms it to voice and sends the voice on the PTT channel back to the user. If it was just a confirmation, then the application uses the normal mechanism to deliver the content to the end-user. Done! Not too complicated, huh?



Since you are a smart guy, you are wondering which services can I build using this technology? What about a weather service? WLNG combines the call with a location call and the generated weather report is read to you by the media server. Another service could be latest stock price, timetables, eBay, Google Map trip instructions read to you, and much more. It's up to your fantasy ...

Finally a good Open Source SIP Servlet implementation

And so the news are out during JavaOne, Sun and Ericsson are cooperating on creating an Open Source implementation of the SIP Servlet spec in JSR-116 and the upcoming JSR-289. See http://www.ericsson.com/ericsson/press/releases/20070508-1125135.shtml.

Finally I say, since this is a big step forward for the SIP Servlet component model. What has been lacking so far is real competitors to WebLogic SIP Server. As a result many customers are hesitating on which way to go - should I choose SIP Servlets or should I go down the JAIN SLEE path. With this move and the upcoming products from both IBM and Oracle all major vendors are now gathered around the SIP Servlet standard.



Why is this good? I believe that you need to see a certain amount of vendors in one technology area before it is considered mature and will have an enduring life. JEE is one such example, Long gone are all the other 'standards' that companies were trying to get customers to buy into. Do you remember HP Bluestone? JAIN SLEE, which is an excellent technology and architecture, faces the same problem. No major player has any products implementing JAIN SLEE. There is only Mobicents OS and then OpenCloud and jNetX which are commercial. I've seen AlcaLu offering their OSP, but it has never got any major traction. While SIP Servlets were facing the same risk if death or even worse ignorance, it is now on its way becoming the number one component model for Next Generation Networks in the telco industry.



I personally don't see it as necessarily a better technology than competing component models (JAIN SLEE mostly) but its wider industry adoption and inclusion in major technology vendors offerings will bring it to become the technology of choice. Now when Sun, Ericsson, IBM and Oracle together with BEA is including SIP Servlet technology into their platforms means it becomes part of extremely advanced middleware platforms with all the features you would expect, like HA, clustering, very high performance, SOA integration, etc.



What we miss though right now is a credible IN to NGN migration story. Hopefully we as a SIP Servlet industry and BEA as a vendor will have an opportunity to get back on this topic.

Virtual Air - another location example

Virtual Air is something that the British futurist Ian Pearson came up with some years ago that I happened to pick up a couple of weeks ago.



Virtual Air is basically a connection between the physical reality we all live in here and now. Whatever we do it stays in the real world so to say. To experience what happens you have to be there when it happens. Virtual Air on the other hand connects the virtual reality with the physical reality. Imagine that you standing at the bus stop waiting for the bus. Suddenly you see two beautiful birds sitting and chatting with each other. You pick up your camera phone and takes a quick picture, attach it to the virtual air surrounding you. Someone else at that bus stop can then see your picture (if you put it public) and read the attached note. You can add lyrics, or a sound recording on how it sounds here and now. There are no limitations. Later on people can see what has happened at that place and read about it. The Virtual Air becomes both a virtual extension of the current here and now and also a historical repository of what has happened in the past.



In the future when you're wearing VR glasses you can equip yourself with an avatar, different depending on who's looking at you. Houses can change look during the day etc. There are no limitations!



Why would you do this? First of all it's a way for people to communicate with other in time and space. It lets people contribute to society in a quite new way. You can have different privacy levels to allow different people to see your notes and media.



Technically it would be quite easy to develop. Have a special short code for Virtual Air. Send an SMS with your notes and the system will collect your location and store the note together with the location. When someone wants to see what's in the current location you can either send an SMS to the Virtual Air number of have a client application running. The important thing here is to make it as simple as possible to enable the masses to use it. In IMS you can use presence to add the current presence status to the message. Also using a Media Server and a Video Sharing application that comes with Nokia smartphones it is very easy to record a See-What-I-See stream and upload it to the Virtual Air.



Once again a quite interesting example of a location based application together with messaging.

How about a burger at half price?

Here's an idea on how to increase the sales of burgers by using simple SMS and location based services. The main idea behind this is to get closer to your customers and at the same time increase the sales and customer satisfaction. The idea is applicable to all goods that are fresh and made to order. It can be burgers, bread, ice cream, coffee, etc.


You enter a burger restaurant and place an order. You order additional tomatoes and onion. You get your order and eat the burger. That was delicious!


How can the restaurant be sure you will go there tomorrow? How can it simplify the order process and speed up delivery? Why not let the customer pre-order a burger for tomorrow for half the price? Then you are sure that the customer will be there tomorrow as well and since you know what the customer prefers you can have the order ready when the customer enters.



Let the customer send an SMS with the pre-order while in the restaurant. You know which customer it is and you know which restaurant from the location. When the customer gets closer to the restaurant the next day you automatically gets the information from the network and can start preparing the meal. When the customer enters the restauarnt he can go to the pre-order counter and collect the order. It is already paid so it's just to pick it up and eat.


This is possible through WLNG who can allow third party access to the network from an application. In this case the burger application connected to the ERP system of the restaurant or chain. The application can get the current location of the customer to identify which restaurant it is. The application also initiates a location trigger to know when the customer gets nearby the restaurant the next day and can initiate the pre-order. The application can charge the customer for the burger using content based charging. When the customer gets nearby the restaurant the next day it initiates the order and sends an SMS to the user informing about the pre-order being executed. When retrieving the order the customer can make another pre-order for the next day. In this case we are using the following technologies from WLNG:

• Network initiated SMS


• Application initiated SMS


• Location information


• Triggered location information


• Content based charging

And the careful reader asks himself, why does this let me make more money and raise the customer satisfaction? Let me give some of the reasons:

• By allowing pre-order you are sure that the customer will stay by your place the next day. He is not tempted by a competitors offers while goining towards your place


• The detailed order is already stored in the system so the customer does not have to tell you his personal style all the time. This increases customer satisfaction


• By giving him a rebate his loyalty is increased and he feels he gets something from you for being loyal


• And finally you get his mobile number and can start building trust and get permission for getting more detailed information about the customer. You can start collecting a little database about your customers and thus being able to make more effective marketing.


• You save money of not having to do so much advertising since you build up a base of loyal customers that pre-orders their favorite food (or whatever you sell). They will probably also tell their friends and you get more customers for free. Since they got you recommended they are more likely to become loyal customers. Now you only have to exceed their expectations :-)

Adding SOAP Message handler to WebLogic Network Gatekeeper

Why would you like to add a SOAP Handler in the WESPA layer in WLNG? That is a really good question, the answer shows a little bit of what you can do with WLNG and SOAP.



They complement each other very good. SOAP adds portability and extensibility since it is not bound to any programming language or OS and it is based on XML Schema. XML Schema allows you to extend the contant and SOAP has the notion of a HEADER. WLNG is extensible with new protocols and interfaces still utilizing the same policy control. In my previous post you could read about how to extend WLNG using the Policy features. In this post I will discuss on how to extend using SOAP Message Handlers.



But before I start to expain a little about how to actually do it, I would like to discuss what you can do with it? Here's a list:

• Validates the IP address of the caller


• Replaces some data in the message, for example masking the MSISDN


• Extracting transaction id or other data from the header and associates it with the call. This data can later be retrieved in a policy for example

So, first the basics. WLNG uses Axis for it's WebServices. With Axis comes a couple of Ant tasks that are used to generate the stubs and skeletons Java files from a WSDL file. It also generates the deployment file server-config.wsdd. In here lies the magic when it comes to extending WebServices with SOAP Message Handlers.

You can have a SOAP MEssage Handler on both the request and the response (that is sent back to the client). It can be on both the client and the server side. What I'm discussing here applies to all cases.



The other thing you need to know and do is to create the class(es) that implement the new Message Handler and doing whatever you want it to do. You should normally implement the interface javax.xml.rpc.handler.Handler (http://ws.apache.org/axis/java/apiDocs/javax/xml/rpc/handler/Handler.html).
When you have done that compile and jar it.




No the time has come for some fun. First you have to update the server-config.wsdd file with your new classes that implements the Handler interface. You can read more about how to do it here: http://ws.apache.org/axis/java/reference.html#DeploymentWSDDReference.
It's not very easy to understand so here's an example:

Handler definition:

<handler name="GenericHandler" type="java:org.apache.axis.handlers.JAXRPCHandler">

<parameter name="scope" value="request"/>

<parameter name="className" value="com.bea.wlcp.test.soap.GenericSoapHandler"/>

</handler>



Handler Chain:

<requestFlow>

<chain name="TestChain">

<handler type="GenericHandler"/>

<handler type="AuthenticationHandler"/>

<handler type="TransactionHandler"/>

</chain>

</requestFlow>




The Handler Chain is defined per service after all the operations declarations.



Finally you create an Ant target in you build file. The Ant target updates the war-file making up the WebSerice (for example parlayx.war) with the updated server-config.wsdd and the jar-file containing the actual aimplementation. Remember to place the jar-file in the WEB-INF/lib directory.


Related to this topic is how to associate the data with the current request. That will be another topic on this blog. Stay tuned :-)

Online charging with WebLogic Network gatekeeper

WebLogic Network Gatekeeper, WLNG, is an excellent tool for providing your partners with a standardized, yet simple interface to the telecom network.

In WLNG there is a very powerful functionality for doing policy control. When a request is sent from the application down to the network, i.e. an SMS, WLNG performs policy control. In the policy control it is checked that the application sending the request is not violating any limitations agreed upon between the service provider (hosting the application) and the operator. These checks could for example be that the application is only allowed to send 10 SMS per second or that the number is not allowed to receive anything from this application.



The policy check is done on all calls going from the application to the network and on all calls going from the network to the application. In the documentation for WLNG you can find the exact point in which the policy check is performed and the name of the check. So these checks are always performed to validate the current SLA.



However this is not enough. You can add your own policy checks in plain Java code as a compliment to the SLA data. What's good does that do, you may ask?



Well, it allows you to do additional checks in other systems before passing the request to the network or the application. Since these checks are done on all calls to and from the network you can do a check before a call goes to the network and then if the network managed to deliver it you can do an update of that same call.



How is this done? WLNG provides a message id that can be used to correlate the two calls. So when a call goes from the application to the network a call can be made to another system using the message id. When the network has successfully delivered the message the policy call is made once again with the same message id. The external system can use the message id to correlate the two calls.



So what can this be used for? One example from the real world is online charging. This example is valid for both calls from the network to an application as from an application to the network. Let's assume an application is sending an SMS with weather information as requested to a user's mobile terminal. When the policy is applied according to the SLA there is also a piece of Java code executing. It connects to the charging system and validates that the user has enough credit on his/her account. If that is the case the SMS is send to the network for final delivery to the user. When the user's terminal acknowledges the SMS the network is sending a delivery report back to WLNG. When WLNG receives this report is applies policy again and the Java code is executed again. This time it connects to the online charging system and uses the message id to correlate with the previous check made when sending the message. It charges the user according to the delivered message.



This is just one case where the flexible policy engine in WLNG can be used to create much more functionality than first thought of. Do you have any more ideas of what could be done using the policy engine and executing Java code inside it?