PointCast: Dr. Doolittle's Pushme-Pullyou?
Corporate IS mana
gers must realize that the Internet has become a n
ew application server (not just a file server) on their network. For many corporations, the Internet is a key source of information that cannot be summarily blocked by the networking folks whenever there's a bottleneck. Network IS doesn't really want to have any kind of content control, and in fact, it shouldn't. IS needs a separate function of security and content management that is outside the domain of the folks running the pipes and routers. Networkers will then be left to determine if the tools at their command (firewalls, access rights settings, router filtering and so on) will allow such policy to be enforced or monitored.
Inside the firewall, there may be a policy of reviewing applications for network impact before they go to production. PointCast never went through such a review, did it? It just happened. This policy may have to be updated to include Internet-centric considerations. Maybe nonreviewed applications will be the first to be taken offl
ine during periods of peak load or the last to be restored after more serious outage conditions.
PointCast I-Server to the Rescue
Most recently, PointCast has moved forward to solve part of its networking application paradigm problem. The company introduced a middle-tier distribution point--a reflector, if you will. With the new I-Server ($995 per Windows NT-based server), organizations can have an internal I-Server that functions very much like the one out over the Internet. All corporate-approved PointCast content is replicated to the intranet I-Server. It actually is pulled from the Internet server by the intranet I-Server. With registration, users who still go direct to the Internet server are repointed to the intranet or corporate I-Server.
Now, the data deployed or broadcast is pushed once and only once across the link to the ISP. The numbing load from PointCast clients pulling over that link is gone, replaced by a once-per-link server-pull delivery system. Moreover, updates to PointCast'
s executable are done automatically from the intranet I
-Server. All this has to be easier on PointCast's own site as well.
PointCast also is opening its delivery mechanism to be tied to other internal corporate information sources so that additional data can be PointCast to those screen savers. This way, the daily memo to employees can be on everyone's screen saver. PointCast has signed agreements with Lotus so that Notes/ Domino can publish data via this mechanism and incoming PointCast data can be deployed into Notes databases. This broadcast notification option--quite different from just publishing in Notes/ Domino itself--could kick off a workflow application that utilized the Domino infrastructure. At its simplest, the PointCast client is just another Web browser that can see Domino pages.
PointCast has yet to address security concerns fully. You might want certain broadcasts to be seen by only certain employees. Since PointCast data is traditional Internet--anonymously available--corporations wil
l have to be careful to publish appropriately, leaving links back into Domino that will require authentication to proceed. So, you'd publish a "Latest Sales Figures Are Available" notice, but only disclose the real numbers to those authorized to hear that "orders are down."
I do believe that such broadcast methodologies can be more effective and efficient than sending e-mail to everyone. Announcing the new 401(k) sign-up period this way would be better than the e-mail approach, particularly since the Web page for changing the 401(k) investments should appear directly from the URL on the PointCast client. Most e-mail packages today still don't have that URL capability.
On the other hand, e-mail is a more reliable form of delivery in most organizations--one that's supported by significant IS resources. If PointCast is to become a trusted information mechanism, it should be given similar resources. You don't want to hear later that the CEO was the last to see that a major competitor was taken over just bec
ause he'd not updated his PointCast client. Moreover, PointC
ast's remote or disconnected user approach won't be as effective as regular e-mail.
PointCast also has not changed the fundamental pull nature of its client. Each client still pulls from a server, only now that server is one step closer to the user (not over the ISP link). Going for three-tier data distribution may not be enough for customers with large WANs and distributed users. Such traffic, now more partitioned across multiple WAN links for geography, may be significant and require link upgrades. Another strategy is to deploy multiple I-Servers or aggressive internal proxy services.
In the end, PointCast needs to investigate better network-level broadcast or multicast technologies, including IP multicast. With the advancements in middleware and standards in the multicast area, we should see applications that publish data that is common to more than a few users moving to these more efficient delivery mechanisms.
With multicast, PointCast
would really be pushing, and the architecture could evolve to a more server-centric control paradigm. In fact, this would provide a viable approach to authentication as well, since authorization for participation in certain groups could be controlled at the server level. Mostly, multicast would further reduce PointCast's load on the network, enabling more centralized servers to update a wider distribution of clients.
Bruce Robertson is a program director with the META Group's Global Networking Strategies service. He can be reached at BruceR@metagroup.com.
| 
REPORTS
ANALYTICS
Follow 
