Welcome to this IBM podcast, Object Management. Group's Telco ML, Example of a Mobile Communications API.

Transcription

1 IBM Podcast [ MUSIC ] Welcome to this IBM podcast, Object Management Group's Telco ML, Example of a Mobile Communications API. I'm Angelique Matheny with IBM. Many existing application programming interfaces, or APIs, such as GSMA OneAPI define commonly supported set of lightweight and Web-friendly interfaces to support mobile development in an operator agnostic manner. With Telco ML, delivery teams can build a component library of OneAPI objects, which are enabled for deployment and devices and operator networks alike. Telco ML provides a modeling view of the API resulting in greatly improved time to market and superior mobile services and applications. And joining me today to talk about this top is Irv Badr, Worldwide Go to Market Manager for the Communications Sector with IBM Rational. Hi, Irv. Welcome to the podcast. Thanks for joining us today. BADR: Hi, Angelique. How are you? Doing great. Let's just jump right in. Does one use Telco ML through a modeling tool? Is it UML based? -1-

2 BADR: Typically, that's the right answer, the answer being yes. The reason is because Telco ML does not introduce any new interface to the common API field. It is an encapsulation in an object-oriented manner of existing APIs; the API from GSMA is called OneAPI being one of them. So because of that, that encapsulation is purely model based, and as a result this is a fairly model-based standard. And the reason people use that is if they're using component-based development, for example, and they're doing project across the organizations which are all model-based initiatives. And that OneAPI you can have a hard time sharing components, because it's a procedure based. With the Telco ML, you're allowed to use objects and specifically SOA -- Service-Oriented Architecture -- type objects, and those lend themselves a lot better to sharing in a component manner. So for those people who are modeling knowledgeable, component sharing through modeling is the only way to truly have what we call a component library. And with Telco ML what we did is we took the OneAPI from GSMA and componentized it so people who do, let's say, cell phone development and they're using some model-driven development process, and people in the central service -2-

3 providers, for example, providers like Sprint, AT&T or other telcos all over the world, they are doing internal development using the same technology that OneAPI has dictated. In this case, through the model-driven approach, they could share components with their handset initiatives. Now those initiatives could be handset companies like providers like Motorola, Sony, Ericsson and so forth, could be using some components belonging to Telco ML while the providers like Vodaphone and so forth could be using the exact same component, sharing those with the other teams. And that's possible to do through the model-driven approach that Telco ML takes. And Telco ML then becomes basically a reference implementation of a model-based API in the world where there's so many APIs out there but none of them have been defined on a model-based approach. So that's one of the reasons we're deploying it, is to encourage model-based initiatives. That way we could actually go ahead and share components and not reinvent the wheel, so to speak, which is a quite actually common issue for people who have, let's say, a Telco has a handset customization group. Most Telcos do, and they buy a handset from a manufacturer -3-

4 or smartphone from a manufacturer, there's a lot of the development in common between that handset group as well as the IT and the network part of the communication service provider. With the modeling approach, it's much easier to share components with the handset group through...and also through the networking and the API side. So it's unification of all the component sharing between handsets and central office, which is quite efficient and leads to much higher quality and shorter time to market. Excellent. And what about current users? Are there any current users of Telco ML who have used traditional APIs before? BADR: Well, that's a good question, because most of the Telco ML was actually conceived by the service providers and European and the U.S. service providers, mostly. But what we at IBM did was took their effort and merged them with the best practices. So their efforts were basically API-based, and OneAPI being the most common one. But there's other APIs also; for example, there's a Presence API from OMA, the group called OMA. There's another API called Click to Call. And then there's a Location API, which is part of OneAPI. -4-

5 There's voice recognition and TTS -- Teletone Service Type -- APIs. But what Telco customers of ours did was they had a desire to unify these as shareable components. So when they're deploying their CSP, service provider application, they can also share some of those APIs with their handset clients like Sony, Ericsson, so forth. And with Telco ML they were able to do just exactly that. So a lot of the customers who have written this Telco ML standard with IBM have already used it and they're already existing users of Telco ML. Irv, how does Telco ML fit in with other standards such as Service-Oriented Architecture which you mentioned before and TM Forum set of communication standards? BADR: Well, Telco ML is actually an interface that got added on, as I mentioned before, but it's based on a SOA, Service-Oriented Architecture interface. Now, for those in our audience who are very software savvy and have been doing object oriented and Service-Oriented Architecture, SOA is not a foreign word. SOA has been around for a very long time. It allows you to have object, server objects and client objects interact with -5-

6 each other and perform services, which leads us up to some very efficient architecture and very reliable and bug-free architecture. So with the Telco ML, SOA ML was actually applied to OneAPI, plus some other APIs that I mentioned, for example, Click to Call and voice recognition APIs. And then we ended up with this toolbox of SOA-friendly API, so to speak. It's not really API. It's an object library, and what this object library will do is it allows people to share, not just share components but also build over time a library of assets of these components, these object-based SOA components. And in the future, when they're publishing some other APIs, this time not just GSMA's OneAPI, but let's say location service API for their developers, they could share a lot of the components that are laying around as model components. And the tool we used to do this, catalog all this, is currently Rational Software Architect, RSA. However, it's possible to do that in any Eclipse-based modeling tool. And what happens then is that these components become more and more widely used and actually become standardized. The Telco ML, the way it got standardized was because it was being used by a few telephone companies and so much usage -6-

7 that it actually ended up becoming a standard. Very similarly just like SOA became the backbone of Telco ML, it can also be more converged with other organizations. So, for example, TeleManagement Forum, TM Forum, is another very active standards organization that manages quite a few Telcommunications standards. One of the ones that is very relevant to us is called SES SMI, Software Management Interface, was very much geared towards mobile devices just like GSMA OneAPI was. But the TM Forum version of the SES SMI was much more global in its nature, was much wider in its scope. So those type of APIs are a very good candidate to become SOA friendly as well, especially TM Forum since has endorsed SOA as its choice of architecture. Many of the people who are doing TM Forum-type implementation have already used SOA just like we have with OneAPI. So the bottom line is that regardless of where the standards are coming from, regardless of what vertical your mobile industry is trying to target, SOA, Service-Oriented Architecture is the core set of technology that really helps the initiative of sharing and efficiency and time to market efficiencies that we're trying to gain here. So as long as that persists across these different standards -7-

8 organizations we see a lot of efficiency resulting in the API world. And Telco ML is a very good example of that. And Irv, my last question today, where do you think Telco ML is headed as it gets adopted over the next few years? And how is IBM support helpful in its adoption? BADR: Telco ML was basically used as a reference, or I don't want to use the word proof of technology, but it's actually a proof of technology, but much more than that. And the technology that we're trying to create a proof of is the API technology, which is the main item of interest here. So what we did was with Telco ML we looked at the span of the communication service providers and the device makers, the network equipment, as we call them, NEPs, Network Equipment Providers. And we saw what's their commonality, what's their common pain point and common needs. And messaging and basically the core message-based technology that OneAPI attacks or addresses is probably the most common one. So we picked that. However, with Telco ML, we could, as I said, expand it to not just location but also to market research-type applications, we can do navigation. We can do safety and then location search and navigation aiding and things like that which there's quite a lot of applications. -8-

9 So with Telco ML it can be expanded to include all that. Now our first plan at IBM with Telco ML is to publish some use cases, meaning how people are using it, how are OneAPI customers better using Telco ML, are gaining new efficiencies or releasing that as a white paper. We are also releasing Telco ML as a product add-on in the December time frame, which is basically a plug-in into our software architecture, tool called RSA, Rational Software Architect. And from there we could actually go ahead and do a full-fledged marketing of this technology, not just Telco ML, but APIs in general for communication service providers. Excellent, Irv. Thank you so much for sharing your time today. This is a great discussion, and we really appreciate you being here. BADR: Thank you, Angelique. That was Rational's Irv Badr talking about Object Management's Group Telco ML, an example of a global communications API, new API standard and best practices for the communications industry. To share this podcast with your colleagues, or if you're interested in more podcasts like this one, check out the -9-

10 Rational Talks to You Podcast Page at And to help you get started, we'll post a link to the IBM Rational Solutions for Communication Services Providers page. So be sure and check it out today. This has been an IBM podcast. I'm Angelique Matheny. Thanks for listening. Keep tuning in as Rational Talks to You. IBM Podcast [ MUSIC ] [END OF SEGMENT] -10-