Blog Tools
Edit your Blog
Build a Blog
View Profile
« April 2007 »
S M T W T F S
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
You are not logged in. Log in
Entries by Topic
All topics  «
Apple Fritters
Calamity
Chinadotcom and VCSY
DD to da RR
Endorsements
Facebook
GLOSSARY
Gurgle
HP and VCSY
Integroty
Microsoft and VCSY
Nobody Can Be That Stupid
Notable Opinions
Off the Wall Speculation
Panama
Pervasive Computing
Reference
SaaS
SOA
The DISCLAIMER
The Sneaky Runarounds
TIMELINE
VCSY
VCSY / Baseline
VCSY / Bashed
VCSY / Infotech
VCSY / MLE (Emily)
VCSY / NOW Solutions
VCSY - A Laughing Place #2
Friday, 20 April 2007
'Happy Hockina', Leon. So you'll be hockina jewels and hockina watches and ... what this?
Mood:  caffeinated
Now Playing: 'Once You Were Mine' Lost love resurfaces as a bowling ball in a bag. Vic Duhmoan / Westley Cripes (Unseen Korean Ware footage)
Topic: Microsoft and VCSY

The attached article below details some of the more complex system interconnects IBM is able to do using XML and a combination of home-grown, partner-owned and somewhat acquired intellectual properties detailing the gluing, shaping and actuating that can be done with a 'pure XML' approach. And by 'pure XML' I mean your middleware between your proprietary new and legacy systems does nothing amongst themselves that is not an XML-based functional activity. And I don't mean just transporting XML as RSS does.

I think it's probably unfair for me to insert this IBM information to compare Microsoft's XML position (and then we go to that ridiculous Ballmer blather about 'workng in the cloud'. He better hope that cloud of obfuscation deceit and delusion doesn't blow away. Cheez Whiz, I hope the cloud around Microsoft's current efforts and non-efforts of the past don't blow away or I will be forced to see 'dos steveos con nada pero los conkachitas y pickelo' as they say south of the border. Well, at least that's how my relatives say it.) as some may argue IBM is a software eveloper and service provider.

The argument will continue that Microsoft let's the developer come up with his interconnections because there's no way to know all the possible things he would need in each disconnect so it's better to give him general purpose parts and he can make his own.

And THAT view of joins between datastores is precisely the 'glue' or 'goo' approach businesses must spend millions on. The developers make the interconnects.

IBM provides the interconnects out of a box. Think this all through and I am confident you will come to the same conclusion: 'Out of the box is better for the user than re-invented wheels'

So we know Microsoft XML tools to their developers are fairly primitive given Microsoft hasn't produced any significant XML-based products since 2001 and they are only now making said tools available to developers (they must think a semantic distinction such as designer/developer will convince a judge a 'designer' works with content and form and a 'developer' works function). LOL

Maybe six years ago Steverino. Today there are XML experts like Charles Goldfarb and his colleagues who will explain quite simply to the court what's going on here with demonstrated capability and vacuously offensive brain-gas.

Oh I know the argument. Microsoft builds software and their independent developers do the actual 'integration'. That's great. Mind footing the bill for some advertising for some of those top-flight developers using Microsoft tools to pull off anything comparable to what IBM is showing in hardware under software controls for server farm energy management?

Using XML technology properly, it no longer takes a rocket scientist to actuate graphic form's and content. That is what Adobe Apollo demonstrates to us... another example of a company that made their R&D budget count instead of letting the 'partners' count on the R&D budget for jobs.

Do I say Microsoft doesn't use XML? Absolutely not. I am saying they do not use XML properly in the most optimum and empowering ways demonstrated easily (any 14 year old kid can grasp what XML can do between applications if the kid is allowed to read that kind of stuff. Parental control can be so stiffling. It's usually exerted to make sure the kid doesn't do something to embarrass the family or bring on a liability in the form of a lucky lawyer lottery... if there are IP pitfalls in the mix, SOMEbody is going to fall in the hole. Then you have to find some wrecker service to pull his obviously gophered can out of there. Phew. Better have big hambones to be able to hold the whole developer community when it isn't just one but hundreds and thousands that find themselves at the receiving end of a paper shotgun loaded with thousands of little spitballs:

Dear __(Insert name of company here__ . According to __(Insert Affidavit Here)__ , you got what we thought AND you loan what we own. Therefore to wit: 'cease' 'desist' and 'turn it all over' 'Sincerely IP Owner's Counsel, Thus, Thus and Fiddlywits.) 

So Somewhere out there is a land where some companies are able to put XML based systems together easily and easily achieve the kind of' wow' type advances hinted at within XML-based information theory.

And then Somewhere out there are caves situated next to a volcano somewhere where folks work with XML and they work on it years and years and they still can't do any better than cutting a rock into a circle and poking a hole through it.

'Mmmm. Call Wheel. Latest. Best. Big money develop. No make XML. XML too hard. Hit head bleed. Make wheel. Mmmm.'

The problem with some teams is they never update their common knowledge base. Oh, they become educated as individuals and as a group they grow in knowing but they never inculcate said new knowledge into the team culture. At least, I say 'never' because it appears many of the tenets of XML theory have only recently bonked Microsoft leadership in the head after all kinds of happy hosre$#!@ swinging around over their heads since at least 2001. That's a long time to have your fuzzy funnies sat on in the colddead seat while the rest of the club is bebopping and hopping all over the XML dancefloor.

 

 

Complex Event Processing with DB2 for Linux, UNIX, and Windows and Coral8

High-speed XML event processing requires a "pure" approach

Level: Introductory

John Morrell (johnm@coral8.com), Director of Product Marketing, Coral8, Inc.

19 Apr 2007

Complex Event Processing (CEP) is a new approach for building applications that process and analyze high-speed event streams. Learn how the pureXML™ capabilities in IBM® DB2® work together with the Coral8 engine for high-performance processing of high-speed event streams. This article also includes an FIXML example.

Introduction

CEP engines are being used to drive a new breed of applications, such as low-latency financial market data analysis for algorithmic trading and trade compliance monitoring, radio frequency identification (RFID) and sensor network analysis for asset tracking and supply chain logistics, and Web click-stream analysis for customer experience management and process optimization.

CEP applications are rarely stand-alone components. They often involve a combination of infrastructure components including a CEP engine, database, and messaging software. Effective implementation of a CEP application requires seamless integration between these components in both the development environment and run-time platform.

 

MORE AT URL

Posted by Portuno Diamo at 12:57 PM EDT
Updated: Friday, 20 April 2007 12:59 PM EDT
Post Comment | Permalink

View Latest Entries