Part two of a three-part series.
All Terri Kouba wants is a little flexibility.
As a systems developer at the University of California, Berkeley, Kouba is spearheading an effort to create a unified communications system. The system will tie e-mail, voice mail and fax to a single in-box and allow access to it from anywhere - be it an e-mail client, a telephone, or a mobile phone or device.
Oh, and Kouba wants it to be open enough so that she can mix and match vendors or add new technologies as they come along.
Part 1: New formula for apps access
Part 3: Galileo travels down Web services path
She thinks she's found the answer in Web services.
The university is in the midst of its three-month Unified Communications Technical Pilot, which will put standard interfaces on existing e-mail, voice mail and fax systems using Simple Object Access Protocol (SOAP) and XML. The latter is used to convert one system's output into XML documents, which are sent via a SOAP message to another system. The receiving system's Web services interface converts the sender's XML documents into an input it understands, letting the two communicate.
If the university's pilot works as planned, the effort will go live early next year for 50,000 users.
"Web services are like Lego blocks," Kouba says. "They will enable us to move into the future without replacing an entire architecture." The university will use its existing e-mail servers as part of the new system.
Web services provide a flexibility that the university has never had because it always has been locked into one technology for voice mail, one for e-mail and one for fax. Now the school can tie it all together without being required to change or replace anything as would be required in a typical monolithic unified communications system, which Kouba say is another lock-in she doesn't want.
"Web services will allow users to get any message from anyplace at any time through any device," Kouba says. "It will also allow us to have a single number, so you can reach me at one number for my phone, cell phone, fax and pager."
She says a Web portal will let users set rules for routing their calls. "So we not only have the single-number reach but it also gives us a call-routing feature we don't have today."
Kouba knows the desired results will cost money, although she won't know the exact amount until the pilot is complete. "We don't know if we'll need one or 15 boxes," she says. "We want redundancy so we will double all the hardware we buy. It could be some pretty serious money, but it is for a customer base of 50,000."
She also says her network architecture will see little change, because all the servers will be deployed in one data center, but that there will be administrative costs to ensure up-time.
The university is executing the pilot with the help of Magnet-Point, a Web services company that specializes in creating Web services interfaces for communication systems.
Web services technology, a collection of standard protocols based on XML, is typically touted as integration technology for e-commerce systems. Kouba says MagnetPoint caught her eye in applying Web services to unify her communication systems.
What she likes about Magnet-Point's Web services is that they turn a message into a neutral object that is transmitted from the sender to the receiver. The objects are passed using SOAP messages that contain XML documents.
"It is kind of like UPS. UPS doesn't care what is in the box, they just say they are going to come pick up a box and take it from the sender to the receiver. That's what Web services is going to do for us," Kouba says.
The pilot system connects three servers, all of which run on Sun hardware and the Solaris operating system:
A message server that runs Sendmail, which was developed at UC-Berkeley in 1981, holds e-mail and voice mail, which is stored as a .wav file.
A telephony server acts as a gatekeeper between the phone system, the messaging server and the third leg of the stool, MagnetPoint's Presence and Avail-ability Server (PAS). PAS is a collection of more than 100 Web services modules that are prebuilt in-terfaces to various systems, including e-mail, telephony, directory, and calendaring and scheduling.
PAS also is the rules and routing engine, dictating where a message is delivered and to what device. Communication between the PAS and other communication servers is handled by Web services interfaces using SOAP and XML.
When a call comes in to the university's PBX, which is leased and runs off-site at Pacific Bell, it is routed to the telephony server, which sends a SOAP message that checks the call-routing rules on the PAS. If the rules call for the message to be delivered to the phone, it is routed to the receiver's phone. If the call is not answered, it is rolled over to the telephony server, which again uses a SOAP message to check the rules for what to do. If the call is to be routed to voice mail, the telephony server records the message as a .wav file and routes it to the message server again using an XML document carried by a SOAP message. The XML document is converted at the messaging server using its Web services interface to a format it understands.
When a user checks e-mail, he can play the .wav file and even forward it to another user. If the user checks for messages via the phone, a VoiceXML interface announces new messages and provides options that can be selected from the keypad. The .wav file is then converted to analog on the telephony server and played over the phone. If the user wants to check e-mail, a text-to-speech system will be integrated into the PAS with a Web services interface. The university has not yet chosen a product to perform that function.
Similarly, if the user accesses the network with a cell phone or a device with a wireless connection, the PAS recognizes the device and sends the requested messages out through an appropriate module built for the user's device.
Users also have the option of installing a small desktop instant-messaging client that the PAS can use to send notifications of new messages and to see if other users are online and to send them messages.
"The biggest benefit is that we are not locked into any device, any type of message," Kouba says. "Tomorrow if we have holograms it just becomes another type of message - another neutral object created using SOAP and Web services."
Another thing Kouba likes is that she is not writing any Web services herself.
"We don't want to become Web services experts. We are a university - our mission is to provide education and research," she says.
The system has a Web portal interface so students, faculty and staff can set up their accounts manually. The system provides them with a phone number, an e-mail account and the ability to set their personal routing rules.
Students pay for the voice-access features, but the in-box is free.
Kouba says she hopes the pilot is successful, but she keeps a critical eye on Web services.
"The scariest part is that Web services is in its infancy; it could crash like X.500 or anything else. If that is the case, hopefully we will find that out in the pilot," she says.
"But we want it to work, we want to make this work," because she says it is the closest thing to IT nirvana she has ever seen.
RELATED LINKS
Contact Senior Editor John Fontana
Other recent articles by Fontana
The other two articles in this series:
New formula for apps access
How one chemical company is using Web services.
Galileo travels down Web services path
Galileo International is cracking open the proprietary systems and networks it has run for 30 years, a move aimed at revolutionizing and personalizing the way it does business.
