WSJ's Industry Editor, Norbert Mikula, recently spoke with Dave Deutschman, chief technology officer of Quintessent Communications, headquartered in Seattle, WA., about their entry into the Web services market.

Dave, can you tell us about Quintessent and your duties as CTO and VP of Marketing?

Quintessent Communications, Inc. (QCI) is the leading provider of interconnection gateway solutions for telecommunications companies. These solutions form the basis of carrier-to-carrier provisioning of telecommunications services such as voice, data, wireless and cable. In essence, Quintessent provides supply chain automation software for the communications industry. QCI's solutions manage the business rules required to exchange service order data, allowing carriers to dramatically improve the efficiency of provisioning new orders and thereby significantly improving return on investment of their networks.

My role at Quintessent is to look for new opportunities where we can apply our core products and competencies to create new products and increase revenues. I am also looking at emerging technologies to determine how those technologies can be used to enhance our ability to deliver products or increase our value proposition for our customers.

The definitions of Web services vary greatly from person to person. How would you define Web services? What do Web services mean for you and your industry?

Using Web technologies, search, find, and execute business functionality that has been implemented using Web technologies. The service may be a Web site containing content or a program.

The telecommunications industry historically is slow in the adoption of new technologies to support its' business practices. However, the use of Web services as a delivery mechanism for providing services could have a major impact on their operating expenses. Take for example a corporate IT group that has a large network infrastructure. Today you would call your local sales rep to place the order for a new circuit to add capacity. A few days later, you might get confirmation that the circuit has been ordered and be provided with a due date for the installation. Hopefully the sales rep recorded the circuit termination points correctly and the order doesn't stall because of a bad service address. Thirty - sixty days later, you hopefully have a circuit that has been provisioned as you expected.

Now change the model in the world of Web services. From a network design tool, you search the Internet for a company that can provide a circuit from the validated service addresses at your desired price point. Once you find the right provider, you negotiate a contract for the circuit, and start the provisioning process. Status for the circuit is provided to you real-time and the circuit is installed in 10-20 days.

That is the change in the business model that Web services would facilitate for telecommunications. Obviously there are other issues that need to be resolved to completely automate the provisioning process, but at least you are certain that the order is correct.

What do you think about the J2EE vs. .NET as a platform for Web services controversy?

That is a religious discussion. As a software vendor, we look to utilize the technologies that have the widest acceptance in our market, which is telecommunications. J2EE appears to have greater acceptance in the larger carriers than .NET. Part of the religious war gets to their reluctance to use Windows as the base operating system for mission-critical applications such as the ordering of services for customers.

I would look for the common elements of their strategies. Both strategies tout the use of declarative definitions for the interface. XML is the basis for declaration for both strategies. WSDL and UDDI are the implementations backed by both camps.

Can you please outline for us the problem for which you decided to include Web services as a component of your solution? Were there other potential approaches and if so, why did you decide to go for Web services?

One of our key customers and business partners is our service bureau provider. They use Quintessent's products as part of their OSS Interconnection service bureau. This service allows carriers to match the cost of acquiring a new customer to the revenue without investing their precious capital in software. This service provides a customer with faster time to market, easier entrance to new markets, and the ability to generate revenues more quickly.

Part of our service bureau's original plan was to provide these services via a web based user interface. Most of their initial customers were small carriers who had not purchased software to generate and manage orders. These carriers used the Web interface to enter and track the orders until the service is provisioned.

As the telecommunications market suffered through the investment "nuclear meltdown" of 2001, larger carriers who had purchased software to manage services orders but who had not automated the processing of the orders with their trading partners, began to look at a service bureau as a viable option for this function. However, these carriers did not want to enter the order into two different systems and were looking for a solution from our service bureau to provide for the integration of systems in a cost effective manner. As our service bureau software vendor, they turned to us to provide a solution.

As we researched the customer's needs, we found that many of them had selected an Enterprise Application Integration (EAI) product to integrate their back-office computer systems. We also found that a number of them wanted to minimize all operational costs, including circuit charges. Being that all EAI vendors provide a B2B component and all carriers already were connected to the Internet, use of Web technologies was natural choice to solve the problem.

There was one additional issue that required us to look a little deeper at available Web technologies. The ordering of telecommunications services is a lot more complex than filling out a purchase order for office supplies. Many of the products require complex instructions to properly provision the service. Also, not all business scenarios (i.e. new order, change order, cancel order) apply to all types of products that are being ordered. This makes integration of the order management and our software difficult. Developers are required to implement a lot of business logic to determine how to complete the order. We are looking at the implementation of Web services to help solve the problem.

How hard was it to sell the idea of Web services in your company? Who was involved in the decision-making process? Did you encounter any major arguments and if so, how did you address them?

Not really. Quintessent wants to be seen as a leader in our industry. We are always looking at new technologies to determine how they can be used by telecommunication service providers to reduce the time to deliver new services. We formulate an approach and launch a "trial balloon" with our customers, prospects, and business partners. Some trial balloons have floated, while others have not. Use of Web services in our product offering is one that has been getting support.

What were the major problems with respect to Web services that you have encountered during the project?

We are too early in the project to provide a lot of input. I am apprehensive about the potential issues we could encounter when integrating a Microsoft COM environment with a J2EE environment. I think we may also encounter issues depending on the transport and data types we use in the implementation.

I am concerned about the management of the WSDL declarations. The message structures for telecommunication services are very complex. We will be implementing a number of operations and may have multiple bindings per service. Maintaining all of the individual XML files and their relationships could be problematic.

During discussion and at conferences, security seems to be a recurring theme high up on the list of issues for IT experts. What is your view on this? Did you have to address any security-related issues in your project?

Many of the services we will implement require authentication of the user. There are different access levels required to perform certain operations of a service. For example, you would allow a sales rep to pull a customer service record, but you would not allow them to issue the service order. Linking the operation to roles or access levels is important in telecommunications. It would also be very hard to secure or hide the service when you want it broadcast to a wide audience. So, providing authentication and role-based or access-control based security is very important

Web services is still a fairly new and, some would argue, very immature, technology. What would you say? What are, in your mind, missing building blocks of Web services standards and technologies?

In the telecommunications world, trading partner interfaces are frequently changed, usually because of changes in tariffs for services, new technologies being deployed in the network, and new product offerings. Even though the industry has a standards organization that is tasked to provide standard interfaces for ordering services, the standards body has historically provided implementation specifications for the industry after the trading partners have changed their systems to support the new or changed services. The net result is a variation in the techniques used to support the new or changed services.

All of these changes must be "normalized" by products such as those offered by Quintessent. Changes in the required or optional data elements and their characteristics in the interface have a ripple effect back to the order- management system. The industry needs some mechanism that allows the carrier ordering services to validate that business rules it is using to complete the order are current and if they are not current, what new elements are needed, what has changed, or what has been eliminated. Once the notification of changes is received, tools must be in place that allow a business analyst, not a developer, to correct the data transformation issues created by the changes in the interface.

The authentication and authorization issues must be addressed and linked with approaches already used by IT organizations.

Finally, the use of a configuration repository for maintenance and support of the XML declarations is a must if we are to have a scalable solution for large organizations, such as telecommunications providers.

Have you ever tried to quantify any return on investment (ROI) as the result of your project?

It is too early in the project to qualify this. We will be working with a customer to project the ROI for the project and can report on the success at a later date.

As a last question, what advice would you give anybody out there who wants to jump on the Web services bandwagon?

Be aware that use of Web services is in its infancy. The industry is bound to encounter issues that will require changes in standards and features. I would equate this to the early days of the browser wars. You need to be aware that changes will be required in the interface. However, the availability of components at reasonable costs, helps to reduce that risk.

Pick a small prototype project to get yourself familiar with the technologies and the issues. Work out the kinks in the prototype and then take the outcome of that solution and apply it to something real and tangible.

Author Bio
Norbert Mikula is industry editor of Web Services Journal and has more than 10 years of experience in building and delivering Internet and e-business technologies. He serves as vice chairman of the board of directors of OASIS, is recognized internationally as an expert in Internet and e-business technologies, and speaks regularly at industry events. norbert@sys-con.com