Proposed Spec To Let Web Services Go Wireless
During this week's Intel Developer Forum, Intel, Microsoft, BEA Systems, and Cannon will propose WS-Discovery, a new web service spec that will describe ways for devices to find and connect to conventional, wired Web services. The spec, to be called WS-Discovery, would work with both .NET and Java-based wireless devices.
Some of the biggest names in enterprise computing want to make it easy to integrate wireless devices into your web services development projects.
During this week's Intel Developer Forum, Intel, Microsoft, BEA Systems, and Cannon will propose WS-Discovery, a new web service spec that will describe ways for devices to find and connect to conventional, wired Web services. The spec would work with both .NET and Java-based wireless devices.
In specific, WS-Discovery would work like this: A mobile device could locate and access web services by "asking" or polling the network, via WS-Discovery, "what services are available to me?" WS-Discovery-enabled services would respond with a list of options, and a connection would be made. WS-Discovery would compliment, but not require, DNS or UDDI directory services. Where such services like DNS and UDDI exists WS-Discovery will transition to using those richer network services to reduce network traffic.
A copy of the full spec for WS-Discovery is available.
For it part, a Microsoft exec said the company plans to implement WS-Discovery in Indigo. Go to on ongoing chat on this topic.
The WS-Discovery protocol focuses on two key things: (1) notifying systems through a multicast protocol when a device or Service is available, and (2) providing a location "bootstrap" so that UDDI systems and event-driven systems can continue to locate and communicate with the device.
The protocol works by providing a means by which a device can "announce" itself to a local network, and then "chat" with interested systems and devices that are looking to communicate with it. Microsoft, Intel, BEA and Canon are intending WS-Discovery to be used as a way to bring a mobile/wireless device into web services-enabled network. Once connected, the wireless device could natively leverage other protocols (like WS-Eventing, WS-Addressing, WS-Security, and WS-ReliableMessaging) for ongoing system-to-system communication.
"This protocol is not meant to replace (at least in the short-term) the device-specific Universal Plug-and-Play (UPnP) specification that Microsoft has successfully championed," Zapthink analyst Ron Schmelzer told IDN. "UPnP will be used first and foremost to let systems know when devices are available for direct communication, while WS-Discovery will be a way to let an entire network know about the Services that are available on that device."
Further, because WS-Discovery is a multicast protocol, it is not designed to replace UDDI either. Rather, WS-Discovery is seen as a lightweight option for local connection to wireless devices, peripherals, etc. and not for WAN wireless connects outside the firewall. The reason for this is that multicast protocols are very "chatty", which means they can consume a lot of bandwidth as they continue to notify systems that they are available for interaction.
Schmelzer describes the following use scenario for WS-Discovery: "One can imagine a scenario where you plug a network printer into the network, it configures itself on your machine with UPnP, and then communicates with other servers on the network using WS-Discovery to let them know that it can print digital color photos. "