Embedded Systems November 2000 Vol13_12

Issue link:

Contents of this Issue


Page 79 of 189

wit Jlnl, th success of UPnP d p nds on th various Jndu ries fJ Jng together and defi"Jng a common and extenslbl API. discovery and service APis for a dynamic environment as might be found in the home. UPnP uses IP and many other FIGURE 11 ~~ ~ lnteroperability API ------------~~ssagi~;-~ys~~~------- - ------------ --- -----------] K- - - ---- -- ---- --- [ 1394 Communication Media Manager j! :... --- --------- -------------------------::.:_-;;::-c:). Platform Specific API ---~ ·--- -- IJ<:ndor Spctlflc f'la!form ·- existing protocols. Included in those protocols are three that provide for the configuration and discovery por- tion of the protocol stack. These three protocols are the automatic pri- vate IP addressing (APIPA), which provides configuration services where DHCP servers do not exist; multicast name resolution, which provides name-to-address translation in net- works without DNS; and simple ser- vice discovery protocol (SSDP), which allows devices to find services provided by other devices on the net- work. See Figure 10. After a device discovers a service it TABLE 3 Device T e/Eiement Java b'ytecode DDI controller Resource manager Stream manager DCM manager Registry Event manager Messaging system 1394 Communicat ion Media Manager HAVi SOD Data DCM manager [..f) -.J ..J -.J -.J ..J -.J -.J " -.J both a description of the data as well as the data itse lf. A negotiation mechanism is provided that lets devices find a common representa- tion of the data to be transmitted. For example, a digital camera may be able to present its image in a 24 bit per pixel (bpp) color format, an 8 bpp grayscale format or in a 1 bpp, 300dpi monochrome format. A print- er engaged in aJetSend session with this camera could then choose the format in which it would like to receive the data. The JetSend specifi- IAV [-.,I] [-./] [..J) [-./] -.J ..J ..J ..J ..J ..J BAV LAV wishes to use, it receives both a URL and possibly a piece of XML code that provides the device with specific infor- mation needed to make use of the pro- vided services. As withJini, the success of UPnP depends on the various industries getting together and defin- ing a common and extensible API. This has not always been a trivial exer- cise because it is often difficult to develop a one-size-fits-all interface even for similar products. Open Systems Gateway cation defines a base format that all devices must support so the negotia- tion will never fail to find a common format. JetSend does not specify any partic- ular transport mechanism and can use any reliable transport. Any discovery services are provided by the transport itself, such as lrDA. JetSend itself does not provide any discovery mechanism. Universal Plug and Play Universal Plug and Play is an initiative driven by Microsoft to provide for the 78 NOVEMBER 2000 Embedded Systems Programming Initiative The Open Sy~tems Gateway Initiative is the brainchild of a consortium dri- ven by IBM, Ericsson, Lucent, and others. It attempts to provide a mech- anism for non-IP protocols to com- municate with the rest of the world via the Internet. The OSGi is based on Java and has three required ser- vices and several optional services. The required services are the equip- ment manager, which interfaces to other IP or non-IP networks such as LONWorks, 1394, or HomeRF and provides virtual IP addresses to these devices; the resource manager, which controls threads and connections; and the remote service administra- tor, which allows new services to be downloaded.

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems November 2000 Vol13_12