OK, Microsoft still hasn’t gotten Visual Studio.NET out yet. But Microsoft’s tardiness is hardly the point. We’ve all known for some time what the .NET framework will include, and for developers of distributed, web applications, the welcome news is that there is real competition with J2EE.
We’ve also remarked before of Java being the victim of its own success. Until recently, it was the only game in town for developing scalable web apps, thanks to features like distributed component deployment, database connectivity, messaging interfaces, transaction management and more.
But then there’s the nagging matter of XML web services. Sun was blindsided when XML emerged four years ago, and failed to proactively extend Java by originating web services technologies. Maybe the hangup was a “not invented here” syndrome, or a fear that web services might poach away some of the logic that should otherwise reside in Enterprise Java Beans.
Either way, the consequence is that Sun has ceded thought leadership on the next generation of web application technologies to Microsoft and IBM, who have both internalized web services into their tools. For instance, type “WebMethod” in any Microsoft Visual Studio.NET language, and your code will automatically generate a SOAP message. As for the Java folks, the best that they’ve come up with so far is proprietary tools that do the same things, and for standards, piecemeal responses for things like how to parse XML messages and generate Java classes. We’re wondering what’s keeping the JCP (Java Community Process) from coming out with its own WebMethod equivalent, because generating XML messages is hardly brain surgery.
The game isn’t over. Microsoft hasn’t even gotten version 1 product out yet, the workability of web services has yet to be proven, and the user mainstream is at least 6 – 12 months away from meaningful experimentation with web services. And web services will never be an easy way out to the tough challenges of application integration.
But Microsoft is clearly running with the ball, topping its SOAP act with a proposed Global XML Architecture, that will deal with missing links in web services technologies like security, authentication, and performance.
For the moment, Sun needs to forget about thought leadership. Generating SOAP messages, WSDL service definitions, and UDDI directory listings are no-brainers. Just add a few simple bridges to J2EE and make the whole darn problem a non-issue.
By now we’ve heard the exhortations to get back to business as usual, but to avoid opening envelopes with white dust. The Israelis having been doing that for years-their high tech industry doesn’t shut down every time another suicide bomber attacks.
Are we really back to business as usual? Yes, we’re back to business, but no, not as usual. The one-two punch of the Nimbda and Code Red viruses in the weeks after the terrorist attacks reminded us once more that webservers and email servers continue to be enterprise computing’s weakest links. Rewind the tape to September 11. On that day, email was the only dependable mode of communication for us New Yorkers. Just imagine the panic that could have ensued had those viruses been timed just a little bit differently.
Unfortunately, for most organizations, IT security policy is anti-virus and access control. Period. That’s akin to building another Maginot Line.
At Gartner Group Symposium last week, a couple points became chillingly clear. Analyst Richard Hunter mentioned that the enemy that you really have to watch for probably already has a company ID badge-a scenario redolent of those hijackers who casually blended in at Wal-Mart the night before they destroyed the World Trade Center. Added colleague John Pescatore, maybe it’s time we started encrypting, not just our external communications, but internal databases as well.
So what does a Real enterprise IT security policy look like? David Cotter, a security specialist for consulting firm Alliant Technologies, described a recent Fortune 100 corp. engagement.
1. Define policies– who’s in charge of what, and what’s considered an attack. Most companies have policies, but few cover IT.
2. Protect against viruses, not just with packaged software, but with escalation strategies and procedures to quarantine rogue servers at a moment’s notice.
3. Filter content, starting with a highly restrictive list of suspect keywords, then gradually easing up to eliminate those proving innocuous.
4. Monitor system events, logging servers, routers, firewalls, and any other network devices-and even if the logs are dispersed, make sure there’s a central portal to them.
5. Ingrain security to the internal corporate culture. Don’t just walk away from that live workstation, take it off the network, dummy…
For this client, the strategy probably will cost up to $5 million for the first couple years. Security’s like an insurance policy. It’s a lousy investment if you think your company will never be struck.