As service providers open up their networks, the differentiator will be how quickly they can put new services into place to respond to trends, and how quickly and effectively they can open up their infrastructure to partners, content providers and even consumers.
The problem traditionally has been that changing one interface could break thousands of others, thus making IT departments somewhat gun-shy about modifying, adding or deleting services in existing frameworks.
That is changing with the XML and TCP/IP-based protocol interfaces of Web Services. Already, Simple Object Access Protocol (SOAP) has been widely used to enable software modules to interact through Web Services Description Language (WSDL).
Four key areas are deemed critical to the success of service-oriented architecture (SOA): creation of an interface language, such as XML and WSDL; providing an information bus via the Internet; allowing flexible interfaces through XML documents; and enabling abstraction of interfaces from applications programming through such standards as SOAP.
Web Services uses robust messaging to foster granular visibility into the business context of XML messages, thus becoming a "wrapper" for legacy systems.
"That enables companies to extract business value from XML streams without affecting the underlying technical framework," notes Michael Madden, CEO of Service Integrity, quickly becoming a leader in the realm of Web Services management. "Web Services enables service providers and operators to add criteria and elements around discounts, upselling or cross-selling in their billing or order management systems, without creating Frankensteinian applications where C or C++ breaks down. It enables them to maintain base formats at a data-element level, by making the changes through the XML," notes Madden.
By allowing that type of abstraction and loose coupling, Web Services puts "flex joints" where business models are abstracted from any particular applications. "Web Services are necessary at those points in your framework where you know business processes must change," believes Steven Rdzak, infrastructure architect at Level 3 Communications LLC, which for the past year has been revamping its order entry system with SOA in mind. He is one of a growing number of architects who buy into the concept of service-oriented development of applications.
Web Services enables companies to make services the primary unit for composing applications from sets of loosely coupled, integrated processes, but SOA requires a major transformation. "Using Web Services requires 'federation development,' which means a big shift in mindset." He notes that IT "transitions from the object-oriented paradigm of building applications to a business-oriented mindset of assembling services from many different domains. "Going from object-oriented technologies to business-level messaging is one of the bigger challenges to employing SOA," according to Rdzak.
"For SOA projects to work, you need buy-in from a visionary at the top, whether a CIO or CEO, so that you don't have to do everything from a grassroots perspective," says Rdzak. "They have to realize that the 'quick-and-dirty' development that focused on getting applications out the door as quickly as possible now need more collaboration than ever before between IT and business heads. Pushing a focus on business and messaging rather than object technologies like PERL or J2E created plenty of arguments with object-oriented folks, who are accustomed to working in silos rather than collaborative environments."
To ameliorate the problem, Rdzak formed an architecture guidance group to find where Web Services and object-oriented design converge. "As C++, DCOM and CORBA must now work in conjunction with Web Services' registries and interoperable, modular technologies like WISDL, SOAP and XML, we are trying to foster closer collaboration between developers and architects."
Because architecture will be the key to remaining competitive, the role of architect will have to be elevated within organizations, according to Igor Sedukhin, senior architect with Computer Associates, which has been making major acquisitions to strengthen its Web Services management and security position. "Where it used to be the platform companies like Microsoft, IBM and HP that would talk of architecture, it will now be important for the service providers to focus on the soundness of their architecture. With SOA, code will no longer be the differentiator, as it will be the architecting of messages that will be the differentiator." He notes that much of the code writing will be facilitated by the platform vendors, which will incorporate Web Services standards into their tools and utilities around their .NET, WebSphere and J2EE offerings.
The process of getting upper management to focus on architecture can be "slow and painful," concedes Hossein Moiin, VP of technical strategy for T-Mobile International, which has made extensive use of Web Services to open up functionality to key third parties and partners. "We had to demonstrate over time to the CEO how we were able to link up our different frameworks—whether our 50 million-plus customer base, our seven branded and affiliated network operators, or literally thousands of content and application providers in the U.S. and Europe."
Moiin says that SOAP and XML were key to integrating various frameworks, UDDI for dynamic discovery of services, and WSDL for defining those services. "Most C-level executives will get lost in the acronyms," he says. "You just have to be sure to demonstrate how that loose coupling enabled the business processes to be dynamic and ever-changing."
To succeed with Web Services, Moiin believes companies have to recognize that object-oriented development and Web Services do ultimately converge. Object-oriented and Web Services design is much the same, but with different views of development. "Where object-oriented design was a 'bottom-up' approach, as objects were created to create services, Web Services now means first defining the services and then allowing that to drive the development of objects to provide services," he says. "It's the role of the architect is to join those views of the same elements and make sense of it."
Creating Autonomous Services Through Messaging
Once IT teams are geared more toward a service-oriented approach to development, the goal can be the creation of autonomous services that will be invoked across the Internet. That ability relies on the creation of registries, which are used to store and provide access to service definitions and related data about how to locate and interact with data. Registries are germane to successful Web Services deployments, because the process of finding all the necessary resources for particular services becomes very complex when service providers increasingly link to more third parties in the delivery of next-gen services.
Each party involved with the delivery of a service must register its resources in a standardized way. That's where Web Services protocols like UDDI come into the picture, as they provide a way for organizations to register services in a public registry. The service provider's software then can dynamically interrogate various Web Services registries to find those services that best meet the demands for cost, performance or other variables for that service. Something like UDDI offers standardized syntax for defining a registry's information model. Then, a WSDL definition spells out the specifications for how to invoke the service.
This enables service providers to announce their services over the Web, and it enables other organizations to make use of that service. It allows companies and individuals to search the Web for services they need.
"We in the OSS space are so specialized in what we do, but it is conceivable that in the future Web Services standards could even enable us to offer services as a commodity over the Web," predicts Ian Emsley, chief architect for Syndesis. "It's analogous to a university that sells its spare computing power on its grid over the Web for others to use. Through the use of Web Services mechanisms, service providers could announce that they have spare bandwidth in a certain time period, which someone could purchase for a premium price," says Emsley. "Or, we could even auction OSS services in that manner someday. If a regional NOC changes over time, we could in theory sell services as they need to change over the Web."
While that type of application of Web Services is not yet on the radar screen for OSS/BSS vendors, it is their customers whose services are increasingly being pushed to the Web via these registries.
For registries to be successfully populated with important information, and if definitions of customers, services and processes are to remain consistent, architects will need a deep understanding of data models. For that reason, Web Services registries must possess as much business information as possible about how services are used to create rich metadata repositories.
"That is the first step to understanding the business process flow and what each operation does," says Rdzak, noting that Level 3 is striving to better understand the nuances in its data structures—whether billing, provisioning, ERP, CRM or any other core system. "If we have that understanding, then we can use Web Services repositories to jump start SOA." He admits that means going beyond rudimentary WSDL. "It means getting as much business data in the registry as possible to provide the value-add information needed, so that managers can see how to re-use certain information across the enterprise," Rdzak says. "Then, the organization can define customers in an abstract way across the enterprise, so that all systems access consistent customer data."
As they choreograph new services, Rdzak and his team are in the throes of learning to understand applications and how they are implemented in the back office. "We want to precipitate a smooth workflow of business processes," he says. "Without doing that, you end up in the school of hard knocks, as you'll realize that the Biz Talk workflow won't work in SOA unless you truly understand each application interface." He recommends starting in small pilot areas, rather than a "big-bang approach."
Through composite applications, Rdzak says, Level 3 has built stronger fault tolerance and support for reliable messaging and policy structures. "With a composite layer in the middle, we've created a service-level façade layer, which enables developers to climb higher in the stack toward business assets so that there can be an easy-to-use interface with business meaning. Then developers understand how to transform requests for looking up credits or billing into corresponding applications," says Rdzak.
He notes that Web Services deployment becomes an exercise in business-facing abstraction rather than technology-based abstraction. "You want to be able to swap out applications on top of the middle layer, without impacting the business, so you can have multiple applications running behind the scenes to answer questions, transparent to the business user."
Tighter Machine-to-Machine Integration
To define customers and services consistently, Web Services standards for creating business registries have emerged to make data semantically interoperable, which is particularly difficult when multiple legacy applications support different functions. For service providers to measure how actions impact services and underlying infrastructure, they must give consistent semantics to services. "We have been working with the W3C the past two years to improve UDDI with Semantic Web—intended to further standardize definitions of services and tighten the integration between machines," says Rdzak.
T-Mobile believes that Web Services' ability to tightly integrate machine-to-machine communication will open the door to RFID services. "As we increase the utility of our networks through a focus on broadband and wireless Internet, the possibilities will be endless in terms of services we can think up," contends Moiin, who looks beyond using networks for data or telephony. "If cars, ovens, refrigerators and just about any object could exchange information in a meaningful manner, we could greatly increase the amount of traffic on our networks. Entire city blocks could be equipped with wireless technologies that enable machines, objects and people to communicate."
He imagines a day when, through RFID, subscribers could program wireless devices to flag certain books, so that people no longer have to search when passing a library or bookstore; or when people preheat the oven remotely while commuting home from work; or when hotel rooms are dynamically reconfigured according to personal preferences. "These are the possibilities that open up once companies can flexibly build services without disturbing the underlying framework," Moiin says, "which is where Web Services comes in."
Where binary mechanisms were complicated and made machine-to-machine integration difficult, Web Services' use of XML makes integration visual, enabling people to put tag names with business meaning on elements. "With visual representation of who the subscriber is or the total charge amount, with tag names saying 'subscriber' or 'charge amount,' complex binary commands revolving around bytes and complex equations will not be necessary to connect machines," explains Robert Houben, CTO at FusionWare. "Ultimately, that means business people who know the telecommunications business can be the application specialists integrating back-end systems."
That will free up the technology folks to concentrate on more technical issues, such as security and manageability—still obstacles to full-blown Web Services deployment.
Security and Manageability
One of the hottest trends recently has been the integration of management and security of Web Services—both big hindrances to early adoption of Web Services standards.
Already evidence is growing, as Computer Associates acquired identity management and Web Services transaction security vendor Netegrity; HP acquired TruLogica and SelectAccess; and IBM, Tivoli and Digital Evolution have joined forces.
"We believe greater use of Web Services as a front-end technology will drive faster adoption of security and management solutions than legacy integration usages," observes Richard Sherman, one of the authors of Janney Montgomery Scott's "Web Services Tsunami Report."
The report sees a lot of progress in management and security through Web Services, as evidenced by the release of WS-Addressing, backed by BEA Systems, IBM, Microsoft, SAP and Sun Microsystems. WS-Management was another standard published by Microsoft, Intel, Dell and Advanced Micro Devices that provides a framework for remotely accessing and managing various devices, application assets and enterprise software.
Also, SPML (Service Provisioning Markup Language) is maturing, and XML encryption, XML-signature, SAML (Security Assertion Markup Language) for AAA, and WS-Security from OASIS continue to mature.
With all of the security work going on, it will be management of security that will be important, as there will be many options for managing policies and enforcing security for them.
"The whole idea behind a loosely coupled architecture is allowing anyone to request any service, which ultimately means exposing assets," says Vadim Lander, chief identity architect with Computer Associates, which provides a shared identity-centric security infrastructure for securing and managing user IDs and Web Services.
User IDs will become the key variable in billing for new services. "With the push to deliver content, there will be a shift in how operators look at people, services and ultimately solutions," says Lander. Service providers no longer care about running a wire to a house, he says, but about how many people live in the house as individual identities—and how to market different applications to each of those identities:
With so many identities to handle, governance and life cycle management will become important when evolving versions of services. "Service providers will have to locate the service and update it for all the partners accessing it, as well as monitor how changes may affect other related services," notes CEO Tom Erickson at Systinet, which helped Level 3 to put Web Services in its back office and T-Mobile to use Web Services for partner integration. "As service providers increasingly open up portals to third parties for upsell and cross-sell opportunities, management of Web Services will be germane to success."
That management will grow increasingly complex as thousands of services evolve for human resources, billing, broadband, dial-up, SMS, location services and so on. That means service providers will have to be able to categorize services and maintain versions of them, so they can help people to find and connect the versions of the services that pertain to them. (That becomes even more important once consumers are allowed to access those services directly through portals and self-care applications.)
For service providers, it will be very important to know who the requester is and how much authority he or she has to perform certain transactions. Some believe a single policy-based infrastructure that covers individual user IDs and Web Services identities is the only way to go: "AAA will have to be provided by the same identity-based infrastructure, if there is to be end-to-end accountability," says CA's Lander.
Others contend it's impossible for one company to encompass all of the elements of Web Services, which is still somewhat of a moving target, as players continue to target certain niches, whether Web Services management, identity management, or security.
Ultimately, it is expected that companies in each of these specialties will converge and consolidate, but to achieve the breadth of functionality needed for enterprise-wide Web Services today, it will be necessary for companies to piece solutions together.
Insulating from Risk Through OSS/BSS
Management and enforcement could be further complicated by "alphabet soup" if Web Services comes to embody too many competing standards.
Thus far, Web Services standards are emerging from W3C, the Web Services Interoperability (WSI) organization and Oasis. W3C focuses on the infrastructure-level Web Services standards, such as SOAP, XML, WDL, WS-Addressing and so on. Then, there are the application-level standards for reliability, security and manageability defined by OASIS, such as WS-Security, WS-Reliability, WS-Distributed Management and SPML. WSI is working on profiling those standards and putting them into interoperable bundles.
Because of the evolution in Web Services, architects and developers must try to insulate themselves from changes by getting their vendors to take some of the risk.
"Any CIO should demand that Web Services interfaces be included in the suites for which they pay millions of dollars. It would help put the CIO in the driver's seat to do more with their architecture as they change services and rely on existing systems for billing and OSS functions," says Service Integrity's Madden.
While the bigger application server, ERP and integration suite vendors are starting to announce strategies around Web Services, there hasn't been too much noise from the existing verticals.
"It's a quickly changing environment of standards," says Houben at FusionWare. "In the beginning you had the U.N. backing the ebXML initiative, and then Microsoft and IBM and other big players supported UDDI and pushed ebXML out of the water. Now, several Web Services standards are being challenged or complemented by evolving specs and standards, so knowing which one to take a gamble on is difficult." At an application level, Web Services interoperability isn't an issue, but "baking it into the application at a deeper level," as Houben says, could be more troublesome if you choose the wrong standard.
For that reason, service providers increasingly are relying on COTS products and their vendors to take the risk. "When we started it wasn't the case, but now about 70 percent of our Web Services development uses COTS," says Level 3's Rdzak.
Because a lot of the integration pains come with converging billing, provisioning and other OSSs, some expect that OSS/BSS vendors will have to provide Web Services within their products to decrease service providers' spending for consolidating systems. "To do that would be relatively simple, but there is somewhat of a philosophical problem, as many systems are still based on CORBA," says Roman Stanek, founder of Systinet.
But with Web Services buy-in from Microsoft, IBM and other platform vendors, OSS/BSS vendors may have no choice but to ultimately offer Web Services integration as part of their solutions, especially since CORBA doesn't work well over the Internet. Interoperability through Web Services will be the only way to enable companies to have a uniform interface when dealing with different platforms and architectures—not only internally, but with external partners as well.
"Because the large core enterprise systems in telecom cannot be extended or hacked apart, we recognize that Web Services is becoming an attractive approach," says Cap Gemini's John Parkinson, chief technologist for the Americas. "By describing data in XML and using Web Services, you can wrap the legacy environment functionality in a standards 'wrapper.' " He says that using Web Services offers a "lightweight form of EAI" to tie pieces together in integration projects, so that "you no longer have to hardwire things together." He believes most software will have to be based on Web Services in the future "to maintain and manage development in areas where business models are uncertain."
In other words, service providers should avoid a hard-coding, silo approach so they have the flexibility to change their mind relatively easily about what business to get into.
"We can't tell carriers how or what will be best way to integrate is, so we have begun to expose our functionality through different Web Services interfaces," says Steve Siegel, director of product management with Portal, whose Billing Agility is based on Web Services standards. By tightly integrating Billing Agility with BizTalk, Portal hopes to offer more integration "out of the box." He claims Billing Agility can reduce integration times by 58 percent and cut hardware and software costs by 50 percent. "Because BizTalk acts as a message broker and integrates to Siebel CRM systems, there is further integration out of the box," he adds.
As customers look into Billing Agility, there will be a need for a "peaceful coexistence" between new COTS solutions and existing ones, according to Portal's Brian Pawlus, director of strategic alliances. "Carriers want to roll out dynamic changes without dumping legacy systems," he says. "That means new infrastructure has to sit alongside existing infrastructure, which Web Services enable."
Convergys also will work to guarantee its APIs work with various Web Services implementations, according to Mike Dimperio, VP for Infinys product management at Convergys. While Web Services is supposed to enable interoperability, Dimperio notes there are usually "nuances" in implementations, "which means we have to recognize that integrating with .NET will require different integration than J2EE." For that reason, Convergys claims to be watching what is happening with the Web Services Interoperability projects, intended to resolve some gray areas for interoperability between .NET and J2EE frameworks. "We know carriers are going to look for vendors that have thought through Web Services enough to build connectors into their applications," says Dimperio. Tier 1s already explicitly request Web Services support and XML interfaces, he says.
"We will be sure to have the functionality in our system so we can expose our capabilities via Web Services," says Mike Sauer, senior technical consultant for Convergys. He says that Web Services has been used in development of rating, billing, customer service and partner management functionality.
ILECs and CLECs may want to get into new product definitions and management arenas as quickly and cheaply as possible, but also allow rapid self-configuration off their core billing engines and customer databases. Their vendors' support of Web Services will be necessary to hook up to core systems and databases so that reference data and functions like billing can be easily accessed. That will become increasingly important as M&A activity continues, and service providers struggle to integrate data from multiple systems and databases—all of which contain different rules, terminology and billing structures.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article