Michael Palmeter's Blog

Michael Palmeter's Homepage
Michael Palmeter is the senior product manager for the WebLogic SIP Server and comes to BEA fresh from 5 years with Ericsson Research where he was the Technical and Strategic Product Manager for Ericsson's IMS application platform.

Clouds, Federated User Profiles and IMS

Most Communications Service Providers consider their customer relationships, and the specific knowledge they have of their customers, as the cornerstone of their long-term success.  Nearly every major subsystem in a Communication Service Provider’s network contains data associated with specific served users; the information that is the basis of the customer relationship permeates the network at every level.  From security credentials and usage records to personalization, account information and geographic location, useful data is scattered across the system, trapped within stove-pipe network elements, applications and numerous IT systems.  Not only is there no single, standard infrastructure for managing all of this data, there is not usually even a straightforward means of determining exactly what data exists, or where.

In most late-generation networks, each new subsystem has typically brought its own data model, with a tightly coupled access interfaces, storage technology and (often inconsistent) approaches to security, reliability, manage-ability and scalability.  Over the time, incremental migration to later technologies, mergers and acquisitions, addition of new applications and services and inevitable changes to governance requirements have added cost and complexity to an already costly and complex endeavor.

Without a clear focus on the importance and complexities of data management, it became common practice to tightly couple application business logic with underlying databases.  This was particularly true for infrastructure that operated in the most demanding environments, where real-time characteristics and reliability during “busy hour” were paramount.  The limitations of this approach are obvious, in retrospect, but the practice was widespread: the “essential” use cases were well-known, and had been staples of the industry for decades.  Today, the range of services and capabilities that a service provider must offer is increasing almost daily, with only one certainty remaining constant: agility is the foundation of success.

The requirements for consistently reduced time to market, reduced capital costs for new services, reduced ongoing operating costs and the need to realize maximum value from existing investments require a new approach are changing the way the problems of data management are being viewed.  It is becoming very apparent that there is a critical logical network subsystem that has generally been overlooked and, arguably, under-specified: the Data Network. More than simply a data provisioning infrastructure, the Data Network ties together all of the disparate systems containing user (or ‘subscriber’) profile, service data and other shared data and allows for a single point of integration for new Data Resources and Data Users which supports the key characteristics of reliability, scalability and real-time performance without compromising the functional and operational benefits of standard off-the-shelf technologies. 

While this has been a churning area of debate within the Telecom community for several years, what seems to be happening is a convergence of a new sort.  The notion of Software-as-a-Service and the “cloud” infrastructure that is it’s underpinning are evolving toward a set of requirements that appear to be very much like those now coming from the Communication Service Provider community.

There is consolidation happening in the OSS space around subscriber information management, from Nokia Siemens Networks’ acquisition of Apertio, to Amdocs buying JacobsRimell and other similar deals.  The User/Subscriber Profile space is being collapsed into a new, larger, set of product offerings that are becoming increasingly similar in scope: profile virtualization (federation) and integration (provisioning). 

From talking with customers and luminaries in the industry, I have boiled the drivers for all of this consolidation down to a few major concerns.  While there is still a lot of uncertainty about specific feature implementations and technologies, the driving requirements that are common across the majority of CSPs seem to be

1) presenting application instances in the compute cloud with a uniform data model and profile schema,

2) supporting massive scale (tens of terabytes of data)

3) integration with existing back-end databases (including transformation and heterogeneous queries),

4) operating characteristics (throughput, latency and deterministic behavior) and

5) SLA and security policy enforcement and 6) profile life-cycle management.

These concerns used to be resolved through best-of-breed components and ad hoc integration at deployment time, but there is a huge growth opportunity for a provider that can pre-integrate and deliver a "whole system".

In case you hadn't noticed, I have a great deal of enthusiasm for this opportunity, and I believe this is not so much about SOA as it is about WOA (so-called Web Oriented Architecture) and "cloud” computing.  I may be reaching a bit, but here is some coverage (John Markoff, ‘New York Times’) on an announcement from Microsoft that made me think a bit about how much beyond my Telco focus this paradigm could be:

Microsoft Reveals a Web-Based Software System

And just to put a finer point on it, here’s a great Blog post from Dana Gardner (on ‘Seeking Alpha’) that makes a powerful point about where data virtualization and management fits in the bigger picture of the cloud computing trend from an IT perspective.

SIP Servlet 1.1

The JSR 289, better known as SIP Servlet 1.1, is coming soon and it will be a very substantial update of the old JSR 116.  The SIP Servlet specification brings JEE a new protocol (Session Initiation Protocol) and is very likely to have a big impact on the ways in which rich Internet applications and enterprise SOA support real-time communications enabled applications.

SIP Servlet Discussions

Visit the SIP Servlets Google Group

Vision and Value: Standards-based, Web-centric Communications Service Delivery Platforms

The Telecommunications industry has historically been defined by the particular technologies employed to facilitate highly reliable, globally accessible, conversational audio-centric distance communication (well, let's call it 'Telephony and physical networks' to make things simpler).  The social benefits of this conversational distance communication capability have been profound, and have lead to regulatory environments, operational practices, technology standards and business models (on the part of the access network operator) which have changed slowly relative to other comparable industries. While evolutionary change has been the norm since the earliest days of telecommunications, recent technological development and changing user behaviors are set to upend the status quo on a scale not seen since the popularization of mobile telephones in the mid 1990's.

The emergence of ubiquitous broadband Internet access, proliferation of multimedia-capable devices pervasive adoption of standard, easily implemented and widely supported mechanisms for interaction between network-connected users has lead to a disruption of the environment in which the Telecommunications industry has prospered for decades.  The capital costs of providing basic network access have fallen dramatically, and the nature of the access network technology has allowed the applications that use such networks to be almost entirely operationally decoupled from the network itself.  The notion of "Internet access" as a service, distinct from the access to applications which are delivered via that infrastructure threatens to finally destroy the de facto monopoly of incumbent Telecommunications.  The basic voice and messaging services that have virtually defined them in the minds of generations of aging consumers are no longer solely their domain.  Voice communication service providers like Broadvoice, Vonage and Ebay take full advantage of customer-provided Broadband Internet access.  These providers essentially offer client software, Service Infrastructure and connection to the Public Switched Telephone Network for cases where callees are not directly available on their private networks.

Even these providers, for the most part, are struggling However; the technology change is even more profound than many anticipated even a few short years ago.  The very concepts of "Telephony" are a legacy of a rapidly obsolescing technology, now relevant to a youth population, in the developed markets, in the same sense as the Long Play record.  Telephony services of historic importance, like call forwarding, call answer and the more recent services like short messaging are relatively trivial to emulate and operate using Internet and Next Generation telecommunications technologies like the IP Multimedia Subsystem.  So trivial, in fact, that their value is becoming negligible in isolation from the services and content that are at the heart of the World Wide Web user's experience and expectations.  The Internet, as it is experienced by a surging population of affluent, broadband connected and youthful consumers, is able to offer the real-time, person-to-person communications capabilities users require, enriched by (or often enriching) information and content sharing services combined from disparate providers.  These providers, for the most part, are already using the World Wide Web as a vehicle for exposure of their assets to business partners and end customers.  In many cases, these assets exist entirely because they can be exposed in this fashion, as is the case with companies like Google, Amazon.com, Ebay and the other first and second generation Web titans.

There are limitations, however, in purely proprietary systems that may prove to cap their penetration to a relatively narrow user population.  The driving benefit of standards is interoperability between systems, and it is unthinkable that there should not be many independent systems operated by geographically, politically, economically and technically insulated providers.  This is a simple matter of redundancy; at issue is the survivability of critical communications infrastructure.  While it is possible to deliver many advanced capabilities through proprietary means, at least where it comes to the user's experience, there are benefits to the use of standard infrastructure that are visible to users, and few limitations.

For example, users that install the proprietary Skype Voice over IP client (VoIP) are offered the option of installing a Skype Tool bar that extends most current Web browsers.  This browser extension automatically inserts code into rendered Web user interface by looking for telephone numbers and replacing the relevant mark-up with a click-able icon representing that number.  By clicking on the icon, the Skype VoIP client software is launched and automatically begins connecting with the target number (or other Skype user via a Skype ID).  If this target callee is registered on the system and currently reachable via a Skype client, the call session is established directly.  If the callee is not reachable directly, the Skype network routes the call to a Public Switched Telephony Network (PSTN) gateway device that is connected to the IP network at a location that is considered "local" to the callee's premises, incurring the lowest cost.  This ability to "inter-operate" with the PSTN is, in fact, the basis of the Skype business model; Skype charges users for the right to terminate basic VoIP calls outside the Skype network.  In practical terms this is a very low-cost approach that relies on the pervasive presence of the client software to drive adoption of behaviors and infrastructure that are entirely funded and supported by the users themselves, and to charge for the capability that is itself the bulk of cost of sales.  There are real limitations, however, to this approach that will become visible to users by comparison as standards-based systems begin to proliferate.

Using an IMS-like system, for example, it is possible to offer users a number of means to achieve superior utility and convenience, with more fine-grained control over the cost of delivery.  This standards-based system offers the ability to dynamically (or according to the providers design) insert similarly click-able icons or other elements of user interface into Web applications developed and delivered third parties. These click-able icons, widgets or other interface artifacts can similarly connect a callee to a caller, but with the advantage that the system connecting the caller and callee is able to make complex decisions about the caller's likely intention based on time, location, preferences, billing status, identity, group membership or any other data related to the caller, callee or context for the communication session.  These decisions can result in the callee being offered personalized information about the disposition of the caller, options regarding how the caller would like to proceed or other interaction with applications acting on behalf of the caller or callee.  These range from applications like Interactive Voice Response (IVR) user interfaces, simple voice mail, interactive Quality of Service selection, interactive or automated media negotiation, multi-device communications sessions.  All of these advanced services require interoperability between the systems used by the caller and callee.

With all of this in mind, however, it is not the utility of proprietary systems that is the primary threat to the incumbent CSPs; it is the possibility of a proprietary system becoming a standard combined with the radical change in user expectations regarding price, service, reliability, ubiquity and usability that is the real threat.  Given the recent write-down of the value of the Skype acquisition by Ebay, this possibility seems to be, as would be expected, receding.  The possibility of a proprietary system becoming a de-facto standard is very low (although examples of this are easily found), and it is likely that most of the larger proprietary IP communications systems will evolve toward standards.  While user expectations can be met using a variety of technologies, it is likely that the transition from legacy technology to new technology will involve major changes to the business models of most incumbent CSPs.  Surviving this potentially radical shift in business models is the greatest feat they must accomplish, and incumbent CSPs find themselves obligated to invest in process and technology change to improve their odds for a successful transition.  The Telecommunications industry as a whole is being challenged, and the growing minority of forward-thinking service providers that understand their need to evolve are seeking partners who can provide the infrastructure and expertise needed.  The Service Delivery Platform concept, as an example, has origins in the long-understood need for new revenue and growth, but the actual deployment of SDPs seems largely motivated by the desire to mitigate risk.  Neither opportunities for growth nor risk are currently in short supply.

The needs of this leading edge class of incumbent service providers dovetail well with BEA's historic position in the marketplace for Information Technology infrastructure and our current and future product and service offerings.  Service providers such as Yahoo!, Google, Ebay, Facebook, Amazon.com, Salesforce.com, Bebo, LinkedIn and the like are largely technology companies, driven by effective internal development of applications and infrastructure at the lowest relevant levels of the "platform stack". Telecommunications Service Providers have historically relied on their operational excellence ( as providers of an "essential" service) and the massive scale of their investments in physical plant, effectively operating as utilities, to shield them from competition.  They have relied on strategic technology partners (Network Equipment Vendors) to deliver pre-packaged systems built to carefully negotiated standards to continuously improve their operating costs and extend their reach to service more customers.  Prior to the introduction of Wireless networks (which was itself the last great disruptive Telephony innovation), this interest was almost exclusively cost-focused; there was little that could be done to a network that could increase the perceived end-user value of a minute of casual conversation. 

The notion of "differentiation" has only recently been regarded as relevant to the business models employed by these large incumbent providers, and they are ill equipped, organizationally and culturally, to develop the means to innovate and evolve at the same pace as their now well capitalized and mature Web competitors.  In many cases, such as with Google, these challengers are not only unburdened by investments in legacy infrastructure and outmoded organizational structures but are also very well capitalized and no longer deterred by the billions of dollars required to build and operate their own access networks. 

Incumbent Communications Service Providers need vendor partners (like BEA) that can rapidly augment existing infrastructure with tools and technologies needed to offset the CSPs own limited ability to innovate on the scale of their new Web competitors.  In the next two years, the notion of a "vendor built" network will begin to describe only a minority of the largest incumbent CSPs whose physical assets and massive scale are sufficient to force the largest NEPs to truly and finally devolve into out-sourced R&D teams.  The rest of the market will either have re-develop their own differentiating R&D and delivery capability or be trodden upon by the technology-focused new entrants that are born from a culture of technical and business model innovation (again, a reference to Google and Facebook and the like).  Technically, these "Tier 2.5" service providers will require the means to expose their assets to internal communities of casual developers and internal R&D organizations.  In this phase we foresee the rapid growth of the market for "Network Middleware".  This phase will be one best described as "transitional", in that it will not require wholesale changes to business models.  The focus of this phase is cultivation of the means of technical innovation as a differentiator, both in terms of new revenue and new cost savings.

Quickly following this initial phase, however, (or perhaps overlapping by two to three years) will be an equally intense period of development focused on business model flexibility.  This “second phase” will build upon the successes that come from an increased ability to undertake effective R&D and will lead to the development of new assets which can be exposed to users and 3rd parties via the Web, harnessing it as both a sand box for innovation and an immediate source of new revenue.  By adopting an infrastructure which "Web-ify's" the CSPs assets and makes them as easy to access as now well-known Web services like Google Maps or Amazon S3, it is possible to create value in a similar way.  Beyond the ability to initiate a voice session or send a text message, CSPs can offer conferencing capabilities that bridge multiple networks and technologies transparently.  They can broker media transcoding between providers and consumers based on device, client and local network capabilities.  They can provide globally accessible storage for preferences and personal information, multiple user interface options for applications, special access to content stores, handle charging and billing for third parties, offer spare network capacity for computing tasks or data processing, provide user location information or contact preferences information to external applications and a host of other valuable capabilities. There are non-functional requirements on the desired infrastructure as well, however.  The Service Infrastructure that enables this integration and exposure capability should not prevent or complicate in-house development of other more tightly coupled and sophisticated consumer services, and should not have to be sourced from a single vendor.  Taken together, these services and requirements illustrate both the capabilities of and need for Service Delivery Platforms, and make it clear what value BEA is well positioned to deliver.

Operationally, the need for scale, performance and efficiency, security, and other characteristics distinguish the necessary infrastructure from the similar enterprise-focused products that exist today.  Beyond this issue of Web exposure, the unfortunate (from the incumbent's perspective) reality is that the capabilities that once were considered highly advanced and uniquely valuable to users are now bordering on trivial in the minds of a whole generation of new customers that can barely recall a time before Voice over IP became relatively commonplace.  The need for exposure to the Web is merely the beginning of the transformation that is required, and ultimately the success of business models based on this approach will necessarily lead to development of new capabilities for which a proper Service Delivery Platform and SOA infrastructure is required. 

Even large enterprises may become their own CSPs, benefiting from lower costs, improved security, greater utility and usability and seamless interoperability with other similar systems via the Web or purpose-built IP interconnections.  Ultimately, the integration of coordinated, real-time communications channels with business process automation on a mass scale will result in tremendous value for users.  Group-ware, for example, that integrates voice mail and email and handles scheduling and automatic initiation of conference calls, offers a significant value, particularly if it does not require purchase of extensive new hardware (hence Microsoft's "VoIP as you are" marketing campaign slogan for the Unified Communications capabilities their software now provides). This value will be material in terms of service usability and, utility and substantially reduce costs and improve, cost reduction and new revenues for enterprises of all types.  Integration with integration and exposure via the World Wide Web will drive mass adoption of key technologies and volume deployments of BEA products as a consequence.  One of the added benefits of current standard technologies is their functional commonality - Enterprise VoIP systems are often re-purposed systems developed for the "Tier 1" CSPs.

Great BLOG on IMS (and SCIM in particular)

Check out The IMS Lantern for some great thinking on the SCIM and other IMS topics of interest.

Why I think "Web 2.0" is Important

When I first heard the term “Web 2.0” I must admit that I was sceptical.  It seemed, at the time, like hype without substance.  Every characteristic of the Web 2.0 seemed to be merely an incremental advance from something that came before – elements of it were obvious and familiar on the one hand, and imprecisely defined on the other.  Personal web-pages evolved into BLOGs, HTML was gradually replaced with XML, use of Java-Script for making those nifty drop-down menus evolved to AJAX frameworks, embedding multimedia content went from “bells and whistles cool” to commonplace, and so on.  My feeling about much of this has changed dramatically, though, over the last few months and I am now a staunch advocate of this perspective.  What I failed to appreciate is that the real change that’s happened in the Web that marks the birth of “Web 2.0” is not in the technology, but in the perception of tens of millions of user and Web developers of the Web’s potential – the Web 2.0 is a “re-think” on the future of the Web and not a statement about any specific technical or cultural milestone. 

What I, and many of my colleagues, are realizing now is that the future of human communication is not all about ubiquitous access to IP networks and off-the-shelf network equipment, but is likely much more specific to the killer Internet application of the early part of this decade: the World Wide Web itself.  I think many people believed, particularly in the Telecommunications industry, that the limitations of low-power mobile devices, lack of a clear comprehensive standard for application user interface, the different non-functional requirements of certain wireless network technologies, and so on, required standardization that paralleled and potentially obsoleted the WWW as they knew it.  WAP is one such example, and I suppose MMS may be another.

And at the time when all of this work started, the rationale was perhaps sound.  The notion of having a hand-held device that could emulate a PC in terms of a user’s access to the Web was considered far-off, and the ubiquitous broadband IP network access such a device would require was equally futuristic.  When I started with this particular technological revolution in 1998, this was all true, but time and change have continued and now, in 2007, we have 3G, municipal WiFi, 40%+ penetration of broadband in most major markets, and an evolved Web 2.0 which effectively decouples the User Interface for services from their network-side implementation.  And we have the iPhone, and all of it’s arguably more advanced peers already widely used in leading-edge consumer electronics markets like South Korea and Japan.  To some extent, the convergence of the information technologies, as the early Web clearly was, and communications technologies has happened, but in a way that was without centralized control or oversight.  This is, not surprisingly, the way broad-based technological change often happens.  And also not surprisingly, many “bricks and mortar” network operators have suddenly realized that they are not as unique as they once believed.  Despite the fact that many Telecommunications service providers own their networks and have historic customer relationships, they are essentially just another enterprise seeking to monetize their assets and expand their business using the Web as a delivery medium and means of improving their ability to reach and retain customers.  In fact, I’ll make a rather bold and provocative statement here (well, perhaps not so bold and provocative to some): Telephony is dead, and the Web 2.0 killed it while we were busy waiting for all-IP.

The perspective that I have taken recently is a big change for me.  When I think about telecommunications these days, I think in terms of the PC and AJAX client container as the “ultimate” endpoint for any communications session.  To a great extent, I think that every other device can be considered a variant of the PC with, perhaps, some specialization related to it’s typical role in a user’s work-flow.  Some devices are mobile, some are small, some are designed for use via a hand-held remote control, others are used for data entry, etc.  The variation is increasingly in terms of user interface, owing to different form factors and specialization for different end-user work-flows.

The great leap forward in Web 2.0 is the decoupling of the user interface from the “view” (I’m talking in terms of the J2EE “Model/View/Control” paradigm) presented by applications accessed over the network (whether those are end-user devices or huge server farms in the data center is immaterial).  The early Web relied on application-driven rendering of User Interface using HTML: the Web application itself defined the user interface and that user interface was developed to support a range of work-flows that were internal to the application.  In the early days of the Web, each application was atomic and required a device with a particular form factor in order to be used effectively.  The notion of “client adaptation” was briefly popular, and some companies made money doing device detection and transcoding (BEA has such a product) and even offered environments that allowed developers to hint at the rendering that would be most likely appropriate for any given device form factor.  The Web 2.0 approach, by contrast, is to break out each feature of an application (or easily re-used used work-flow) and expose them as a single “application service” using a very high-level (read: “easy for laymen or novices to use and integrate”) style in which the actual rendering of the user interface is largely (if not completely) subject to the capabilities of the client and the interest of the end user (or some third-party integrator).  This means that “applications” increasingly exist in user-controlled environments and not in service provider environments – what “service providers” do is expose their infrastructure and data resources in bite-sized, readily accessible pieces and allow other service providers or end user to do the minimal integration needed to derive maximum value from those capabilities. 

From this perspective, capabilities like secure network-side data storage, bandwidth-on-demand, trust brokering, billing consolidation and access to legacy (pre Web 2.0) databases, clients and other infrastructure are the real assets that a typical Network Operator possesses.  Compare this with the capabilities that a service provider like, say Google, offers: Web search algorithm and database, an advertising system, email service, and the like and you’ll see that there are far more similarities than differences from a Web 2.0 user’s perspective.  Increasingly, the differentiation of one network operator from another, and from the likes of EBay, Google, Flikr, Amazon.com, Yahoo!, MSN, Salesforce.com, LinkedIn and others, will come down to the ease of use and novelty of these individual exposed services and the ability of the masses of Web 2.0 enthusiasts and end users to find new synergy by mixing and matching them to create new applications.  And whether the user interface is a speaker, microphone and dial-pad or an AJAX famework and a Web browser on a PC, these services are all increasingly likely to share a common server-side implementation built on well-known technologies and styles like HTTP, XML, SIP, AJAX, FLASH and the like.

From where I stand, it seems like the “convergence” that the Telecommunications industry has been talking about for nearly a decade is finally here, and it’s being called “Web 2.0”.  Go figure.

Caching and REST Web services

I’m really fond of the notion of REpresentational State Transfer (REST) these days, and right now I’m chewing on the relationship between REST and caching and resource abstraction/normalization (take a look at the Wikipedia entry on Representational State Transfer to get a sense of my frame of reference for this blog).

Despite the fact that REST usually involves the HTTP protocol, the data object (representation) in question can be accessed by any means that gives me the basic CRUD that I’m looking for.  This has no bearing on the business logic of my application; I could be using any data access layer that gives me the CRUD operations that I need to allow me to modify that object and communicate the changed state back to the resource.  In a multi-protocol world, this is a pretty powerful concept.  The exact nature of any connector is irrelevant beyond the Data Access API supported by the connector that I am using.  To stretch this a bit further, let’s suppose that a middleware container may, for all practical purposes, be a connector (at least in this sense).  The architecture that leaps to the forefront of my mind is one in which the connector acts as a bridge between the client and the resource, but does not dictate anything whatsoever about the business logic implemented by the resource itself.  To my mind, this makes the notion of Enterprise Data Fabric (a data grid augmented by some resource integration toolchain) very complimentary to the concept of REST services and very neatly appropriate to container-based middleware (like, say Servlet containers).

Now the cases that I’m really thinking of are relatively few, I admit; I’m thinking mostly about applications that have both SIP and HTTP capabilities, like conferencing, messaging, telephony, presence, group list management, and so on.  These are not fringe cases, of course: they’re central to the entire universe of Next generation Networks standardization.  What’s more interesting, though, is the immediate relevance to what is happening in the Web 2.0 world at the same time.  The Telecommunications standards bodies, namely the IETF and all of the other bodies that roll IETF RFCs into their layered specifications, have latched onto the notion of the XML Configuration Access Protocol (RFC 4825) as a generic framework for personalization and preferences management (the ‘User Plane’ of next-generation networks).  What made this such a good choice was not the fact that XCAP is a REST framework, but that this approach exhibits a number of key characteristics which are really important in Internet-scale, high traffic, multi-vendor environments: loose coupling, resource efficiency (communication state is easier to maintain), backwards compatibility with existing infrastructure and scalability (through caching).  It is on the last point where I thin there is something to be considered that Roy T. Fielding’s excellent dissertation considered explicitly.

If we consider the notion that the Data Access API exposed to application business logic executing in a middleware container constitutes a connector (in the REST parlance) then it is entirely reasonable that such a connector may incorporate a caching capability.  The container may also handle identity management, privacy and Service Level Policy enforcement.  It could even provide an environment for resource integration with the cache that hides the complexity of the resource entirely from the business logic of the service.  Now I realize that this is all a bit far from the letter of the REST law, as it were, but my point is that there are elements of REST that can be brought to bear in implementations that stray quite far from strict REST application in the context of the World Wide Web and HTTP.

In this regard, I think that there is a relationship between REST principles and, for example, infrastructure like BigTable, which meets not only functional requirements of end users, but is inherently predisposed to very large scale, high performance systems.  I predict that REST and Data Grids (and the notion of the Enterprise Data Fabric) will emerge as central concepts in the nex big wave of development of the Web 2.0.

xcap-client: AJAX XCAP Client

xcap-client: AJAX XCAP Client.

This is a very nifty project.  I’m quite enthusiastic about it.

microformats | About microformats

microformats | About microformats.

It’s been a while since I blogged, and I must admit I’m feeling a bit buoyed by the incredible progress that has been made in the last year within the Telecommunications industry and the promise of merging real-time communications (read: “Telephony”) with the World Wide Web.  In some ways, over the last few years, it has become clear that this is not so much a merger as an acquisition: the direction of change seems to be increasingly driven by the evolution of the World Wide Web and not merely the roll-out of underlying IP infrastructure.  Real “Convergence” is happening farther up the stack that many people anticipated even as recently as two years ago (myself included).

One of the really fascinating developments that we have been watching unfold is the evolution of Service Oriented Architecture into three fairly distinct, but parallel, sets of technologies and design principles.  On one hand, we have the incredible progress that has been made in developing a set of protocols and architectures for business process automation.  Stuff like enterprise Service Busses and Data Fabrics and Business Process engines.  At this point, most (the vast majority) of major enterprises are already taking an SOA approach to development of their IT infrastructure.  The benefits are pretty well established and the products that are needed are now widely available.

In the Telecommunications industry, happening in parallel with the advent of SOA, is the emergence of a real-time variant on the theme of service oriented architectures.  It’s more rigidly defined than the SOA we’re used to in the IT domain, but there are many design goals and technologies in common.  The specifics aren’t important in this context, to be honest, aside from some observations which I’ll get to later.

At the same time as SOA and IMS have been developing, we have seen the world of “Web 2.0” technologies and approaches come to dominate the way end users interact with the World Wide Web.  There are many similarities, of course, in the problems and opportunities and challenges that IMS, SOA and Web 2.0 seem to address, and it could easily be argued (perhaps it is even self-evident) that Web 2.0 is the “user facing” part of both IMS and SOA.  The distinction between Web 2.0, IMS and SOA, is more one of emphasis than of principles.

So if we take a moment to compare, I’d say that SOA tends to focus on a few technologies, namely Simple Object Access Protocol and it’s adjacent technologies as a base toolkit for service integration.  The early SOAP approaches were very aligned with verb-heavy RPC-style services, although this seems to be out of vogue now to some extent.  The services that are exposed in enterprise SOA architectures are modeled along organizational and functional boundaries, and tend to be optimized for re-use and maintainability rather than usability.  You could argue that this is not dictated by the technology but is merely a byproduct of it’s common application, but that is neither here nor there for the purpose of this discussion.

Now this is of particular interest to me (being more of a Telecom guy than a Web guy by experience) because the current standardization happening in fora like the Internet Engineering Task Force (IETF), 3^rd Generation Partnership Project (3GPP) and the Open Mobile Alliance embraces a very RESTful approach to Web services for a certain class of key use cases in next generation networks.  This aligns extremely well with the dominant Web 2.0 style, from RSS to Google Maps.  What is truly interesting to me is the fact that both the Web 2.0 and IMS seem to have come to similar conclusions about how to use REST web services for presentation of user interface to network resources.

I’m specifically talking about the “user Plane” of the network and a set of protocols and standards around the XML Configuration Access Protocol (XCAP).  XCAP is a very simple REST Web services standard that maps simple CRUD semantics and XPath to the HTTP protocol.  The result is a relatively straightforward and open-ended REST framework that can be used for a multitude of services far beyond the cases that are considered explicitly in the standards.  If you add some other complimentary stuff like AJAX client frameworks (for rendering UI), WebDav (for transactionality), IP Multimedia Subsystem (for integration with next-generation and last generation communication networks) and the Session Initiation Protocol (for event notification and real-time session control) you get a very rich environment for developing “widgets” or “microformats” that securely expose real-time communications systems (whether enterprise or Telco class) to Web 2.0 developers and users in a fashion that readily allows composition of those capabilities into applications that simultaneously interact with the myriad of other services available on the Web.

So what made my click my “blog this” button when I came across the microformats.org site was the really down-to-earth focus on usability over “high concept”.  I think there is tremendous merit to the spirit of the microformats approach, particularly since it fits so neatly into the NextGen communications services paradigm.  I have no doubt that we are entering into an era of dramatic change to the way we view communication, and the surprise to some may be that the way forward is all about communications-enabling the Web, rather than Web-enabling the communications network.  That’s merely my opinion, of course.  But I suspect I’m not alone.

The Problem Wth Distributed Systems and the Benefit of Co-Location

SIP Servlet 1.1 (JSR 289) and the Service Interaction IMS

Representational State Transfer (REST) and Data Distribution in SIP/IMS Networks

Service Capability Interaction Management (SCIM) in IMS

So What is an "IMS Service", Anyhow?

Separating SIP from the VoIP Umbrella

Telecom has an SOA too - the IMS

The concept of the Service Oriented Architecture (SOA) is not new, although the reference is most commonly used in the context of modern information systems typically used in and between large enterprises. Service Oriented Architectures for information systems have largely been evolved from technologies and approaches that build popularized by the Internet. The IT industry has settled on an SOA approach that relies on the use of HTTP as the addressing and transport infrastructure and eXtensible Markup Language (XML) as a generic format for inter-process messages.

Current generation Web services-based SOA define a number of technologies that supplement standard transport protocols (primarily HTTP) to complete the architecture, such as the Universal Description, Discovery (UDDI), Integration protocol and the Web Service Definition Language (WSDL) and, optionally, the Simple Object Access Protocol (SOAP).

The combination of HTTP and XML, for example, is sufficient to allow the concept of a Service Oriented Architecture to be effectively realized through largely off-the-shelf products and widely available competence. In many cases, simple and relatively low cost upgrades of existing infrastructure are all that is needed to begin realizing a Service Oriented Architecture. There are substantial limitations to this approach, however, which make it generally unsuitable for a broad range of applications.

For a number of reasons, largely related to scale, resource efficiency, security, inter-domain interoperability and reliability requirements, real-time communications systems have not benefited from the Internet in the same way, or to the same extent, as information systems. Recently, however, a dramatic shift(fuelled by the remarkable increase in global IP network capacity, geographical coverage and the increasing power and flexibility of the computing devices available to consumers) has altered the balance of forces.

The fundamental ability to make use of the Internet (and all of its component technologies) for real-time, full-duplex exchanges of streamed data, such as voice and video, has only recently become achievable at the scale and cost levels needed to supplant legacy communications systems. The communications industry has standardized the essence of a Service Oriented Architecture of its own that, in many ways, exceeds the scope of the information systems from which it draws much of its inspiration.

This architecture is known as the IP Multimedia Subsystem (IMS).

About the IMS

There are several excellent sources for information about the IMS. I reccommend that anyone interrested in the IMS start by looking at the Wikipedia entry for IMS as a starting point.

Wikipedia - IP Multimedia Subsystem

From an industry perspective, the IMS is generating a good deal of buzz. One of the best sources for Telecom industry news and analysis is the Light Reading website (and the Heavy Reading consultancy).

Light Reading

A pedagogical white paper will be published in the upcoming weeks that deals with the specific comparison of IT SOA and IMS in more detail. Of particular interest is the IMS vision for Representational State Transfer (REST) "Web Services" using SIP, HTTP and XML rather than the more generalized SOAP protocol so common now in IT SOA discussions.

April 2008

Search this blog:

Archives

April 2008
December 2007
October 2007
July 2007
June 2007
July 2006
May 2006
February 2006
January 2006

Categories

Recent Entries

Clouds, Federated User Profiles and IMS

SIP Servlet 1.1

Vision and Value: Standards-based, Web-centric Communications Service Delivery Platforms