Diving into the nuts and bolts of Microsoft's Web services offerings, Mark Lucovsky, HailStorm chief software architect, conferred lessons learned and best practices companies should consider while working to expose their businesses via Web services.

Microsoft's HailStorm, officially named .Net My Services, comprises a set of user-focused services inducing MyCalendar, MyPresence, MyLocation, MyContacts, and MyInbox.

Speaking here at the InfoWorld CTO Forum, Lucovsky said Microsoft's vision for HailStorm is to "empower users to securely store, access, and share information across the Internet anytime, anywhere, and from any device."

Exploring the architectural issues that arise while building Web services, Lucovsky said the major differentiation in a Web services architecture is who is at the center of the model. Turning the traditional application-centric model on its head, at the center of the HailStorm Web services model is not an application but an identity, he said. This could be a person, a club, an organization, or a resource, he added.

"We bind data directly to the identity," he said.

As an example, Lucovsky pointed to the HailStorm MyCalendar service. Rather than the Outlook calendar application residing at the center of the MyCalendar service, an individual's personal calendar is at the center, and any application that wants to access that person's calendar can use Web services protocols to do so.

Because Web services allow all applications to access the same base set of data, applications will be forced to compete in a fundamentally different way, he said.

"How do you keep a customer in a model where users' data is the center and all application are peers with the same access? All applications then have to compete on value," he said.

Another architectural issue to consider is whether to expose Web services via APIs or protocols, Lucovsky said. There is a danger here when dealing with ISVs, he cautioned, because ISVs may be unwilling or unable to code to raw protocols. But if you build an API layer to help ISVs, you may end up encouraging tight binding between applications and services, which may not be manageable in a distributed Web services architecture.

"The key thing you need to work toward is a loose binding between a Web services client and a Web service itself," Lucovsky said.

He also encouraged attendees to consider when building Web services whether to program to an object-centric or XML-centric model. One pitfall to look out for in the object-centric path is how to obtain extensibility when you are programming at a high level, he said.

Organizational issues are also important to consider when going down the Web services route, Lucovsky said. These issues include what workforce skills are needed, how to train your company to think differently, and how to handle internal coordination of development efforts. As a company begins down the Web services path, the workforce must be trained to think in a fundamentally different way.

"It will happen with Web services and for the next big thing that comes along, whether that is peer-to-peer or something else," he said.

The primary skill a workforce needs is a deep understanding of XML, particularly name spaces and versioning.

"The big thing we had to deal with [at Microsoft] was learning and embracing XML," Lucovsky said. "XML is more difficult than people think."

Also important is re-training the workforce to openly embrace elements of Web series such as statelessness and distributed computing.

Furthermore, organizations must understand the role of peer-to-peer in a distributed Web services architecture, he said.

"P-to-p and Web services are complementary, but teaching people the key elements of both is important so you don't have tensions between the two groups. Both belong in a distributed architecture," he said.

Offering advice about how to coordinate internal issues with business process development, Lucovsky recommended a "top-down" approach, in which an organization lets a business process drive the underlying technology development.

"A top-down approach makes a lot of sense for Web services. Have a top-down model drive the plumbing you need," he said.

From an industry perspective, interoperability is a critical issue, and organizations such as WS-I (Web Services Interoperability Organization) are a step in the right direction, Lucovsky said.

"It is very important for all of us in Web services to look at the problems around interoperability," he said. "These are real problems and are very relevant to companies that are opening their business as Web services."

Furthermore, there is still much development work that needs to take place to further standards such as XML and SOAP (Simple Object Access Protocol), according to Lucovsky.

SOAP 1.0 is a simple protocol that enables the encoding of objects in a message body, but "it doesn't tell you how take a SOAP packet through a firewall, how it will be routed, how to do security or reliable messaging. There is a lot of next-generation protocol and SOAP work that has to happen for us all to be successful," Lucovsky said.

Enterprises right now should start taking steps toward Web services, he said. Firstly, Lucovsky recommends that a company conceptualize pieces of its business as a set of services and think at an abstract level how to digitally represent those services.

"What is the electronic face you would put on your accounting or purchasing systems and processes?" he said. Companies should "begin Web services pilot projects now to get their hands dirty and understand where [they] are going."