Mood:
brightNow Playing: Fry Daddy Bisque - Chef washes socks in the bouillabaisse (much egg many faces)
Topic: Ultrasounds
If you ever want to work semantically on the internet, you have to be able to, first; interoperate with data situated between your own process desires and some other processing demand.
If you can do that, congratulations. That was the first step. You now need to make interoperation data perform in a data portable way and you then have the wheels for functionality.
Functionality is what we call any active processing a software body (an "application") can do as touching a body of data being considered as content. If all the application does is contained in that one body of functionality as dealing with an exclusive content and doesn't go outside the present application except to direct the user elsewhere to do something else, the application is a monolith and indicative of traditional "object" oriented architecture.
Our quest here is to describe what is appearing in the industry; spotting those attributes that will allow us to track to determine whether and where technology may go in the seen and unseen landscape.
Interoperability is necessary when discussing the functionality of two or more applications as relates to a common body of data.
Interoperation is fundamental to the distribution of functionality.
The entire issue of interoperability is the core argument in the controversy surrounding the standardization of Microsoft's OOXML Office document XML formats (>6000 pages) as opposed to a more simple XML standard in ODF (measured in hundreds of pages).
We see Microsoft apparently does not want other applications working intimately with their document and programming files. They therefore drag their feet on meeting open-ness standards.
We do not see Microsoft putting energy into interoperation because interoperation opens up the probability the outside application interacting with Microsoft's own data domain will only bring diffusion of user's market view and dilution of client lock-in.
Interoperation fundamentally demands the data be in a universal form so the content can be differentiated from non-content data.
Having that interoperability provides for two adjacent methods to operate on the data between them, thus providing a foundation for a movement of data from one processing node to another.
The basic terminology would then describe the movement of data from one processing node to another (thus an interoperation between a pair of connected nodes may be transported further by allowing one of the nodes to perform a similar interoperative process with another adjacent node.) This is a sophisticated form of data portability called transactioning and is fundamental to various mainframe operating systems.
Transactioning begins with one node performing a process which triggers transport of data to facilitate a collaborative exchange of meaning and ownership to another node. Just like humans do their workflows.
This "event processing" and "transactioning" are fundamental activities necessary to provide software functionality to a mass of data.
Most "event processing" is commonly pictured in manufacturing process automation.
Most "transactioning" is thought to be performed in financial systems automation.
But, without event processing AND transactioning, neither system automations are possible.
If you intend to work in that direction, you first need to "tag" (XML markup is applied around the text or image to instruct the machine as to the "name" and other properties of that particular text or image) each significant word and image of content to provide the machine with a way to apply industry specific meaning to bodies of content.
That's what Yahoo announced back in March 2008.
"Yahoo’s support for semantic web standards like RDF and microformats is exactly the incentive websites need to adopt them. Instead of semantic silos scattered across the Web (think Twine), Yahoo will be pulling all the semantic information together when available, as a search engine should. Until now, there were few applications that demanded properly structured data from third parties. That changes today."
This is a baby step to bring the available data throughout the "known" world to a machine "knowable" state. It's the "seamless" nature of a virtualized mass of data that makes discovering unknown relationships embedded within the data mass a matter of course and very valuable.
Bringing data into that state allows different applications from various platforms to work with the same data amongst all uses. That's interoperability.
Interoperability allows for virtualization of the interface between two interoperating machines.
The next baby step to perform is data portability. Yahoo announced that step the other day.
Where to next?
We are advancing toward a point where processing of any desired amount may be done within the objects doing the event processing + transactioning local to the data storage and protection, allowing for secure granular functionality at any data point.
This removes tremendous burdens off the centralized infrastructures and makes the distributed processing devices more valuable to the overall ecology.
Thus, I commend this article to your reading for your edification toward the future conversations we'll be having.
I know this stuff is pretty heavy for a snookywookums to read but you gotta grow up fast in this world, bucky.
http://blogs.zdnet.com/service-oriented/?p=1102
May 11th, 2008
Is anyone ready to process a trillion events per day?
A typical company deals with millions, if not billions, of events in a single day, and most, if not all, of these events are still handled manually, by people.
"he value of complex event processing, overall, can be summarized as improving situation awareness,” Schulte said. “Simply put, that is just knowing what is going on, so you can figure out what to do.” The benefits of complex event processing, Schulte said, include better decision quality, faster response times, reduced information glut, and reduced costs.
(more at URL)
-------------
I don't think you need much more than that to be said to help you attempt to grasp how pervasive the need is for event handling technology and transactionary technology to track the events handled. The potential for innovation in the ability to provide real-time metrics, quantization and qualification of business processes and the impact on business design is enormous.
And that's just the first step executable without touching the legacy code or the work flows. It's the simple virtual fitting of a sensing and control feedback system to the existing electronic interfaces making data available in some form (any form because the known content has been semanticized and the search efforts have further extended knowledge) to the machine.
No control actuation is available without further outfitting at this point in describing the architecture, but this already described simple process can put a corporation or community electronic world in a semantically knowable state worth fortunes.
The first half necessary in learning to do the automation walk.
And that is achieved by simply outfitting the various data points with local processing resources to be aware of event triggering and capable of transaction processing and audit history. That is a foundation for true trusted-but-verified human interaction as measured at the point of contact with the human... not buried in a remote server-farm.
Where possible, measure closest to the point of use and provide service local to your event. If you have the capability to process in that way, you can press on. Without that, you will stumble in the effort to execute distributed processes in a deterministic control state.
Once (and not before) that control feedback framework is available/applied to the various data points in a business, functional activities may then be applied to each data local to perform activities needed. That processing has the opportunity to provide true parallel processing across many distributed clients and revolutionize workflow process for a productivity leap similar to the OLE/COM age. I believe the impace will be more quickly deployed and more quickly adopted at a much larger scale.
At the most fundamental incarnation, the processing nodes allow for the building of metric systems to allow for proper critique and assessment of human-actuated business processes. That capability alone is of huge value in business immediately, even if the automation of these business work practices is years away.
But the immense value lies in learning to create software services to enhance, elevate or replace the human task while applying processing resources local to the person executing the transaction both on the "consumer" side and the "supplier side".
Another phrase from the above article: "Most of these events are not captured or automated in enterprises"
This means enabling all these new data points opens up dimensions of stratified association and relationships. In many ways these formerly unseen assets will provide useful feedback, viable new methods, and potentially new business aptitudes and direction for the automating business process.
So why do we need to do this? “We have to record events using event objects so computers can receive them and do computations on those events,”
Precisely. They do those things much more reliably and accurately.
celebratory
caffeinated
accident prone
party time!
suave
don't ask
lazy
hug me
P. Douglas :
One thing I would like to know: does the author prefer using web apps over comparable desktop apps? E.g. does the author prefer using a web email app over a desktop email client? Doesn't he realize that most people who use Windows Live Writer, prefer using the desktop client over in-browser editors? Doesn't he realize that most people prefer using MS Office over Google Apps by a gigantic margin? The author needs to compare connected desktop apps (vs. regular desktop apps) to browser apps, to gauge the viability of the former. There is no indication that connected desktop apps are going to fade over time, as they can be far richer, and more versatile than the browser. In fact, these types of apps appear to be growing in popularity.
Besides, who wants to go back to the horrible days of thin client of computing? In those days, users were totally at the mercy of sys admins. They did not have the empowerment that fat PCs brought. I just don't understand why pundits keep pushing for the re-emergence of thin client compputing, when it is fat PCs which democratized computing, and allowed them to write the very criticisms about the PC they are now doing.
Posted by P. Douglas | April 30, 2008 3:50 PM
portuno :
"I just don't understand why pundits keep pushing for the re-emergence of thin client compputing, when it is fat PCs which democratized computing, and allowed them to write the very criticisms about the PC they are now doing."
Because business and consumerism sees the move toward offloading the computing burdens from the client to other resources as a smart move. That's why.
Pundits are only reporting what the trends tell them is happening.
Posted by portuno | April 30, 2008 3:59 PM
P. Douglas :
"Because business and consumerism sees the move toward offloading the computing burdens from the client to other resources as a smart move. That's why."
Why is this a smart move? If the PC can provide apps with far richer interfaces that have more versatile utilities, how is the move to be absolutely dependent on computing resources in the cloud (and an Internet connection) better? It is one thing to augment desktop apps with services to enable users to get the best of both (the desktop and Internet) worlds, it is another thing to forgo all the advantages of the PC, and take several steps back to cloud computing of old (the mainframe). Quite frankly, if we kept on pursuing cloud computing from the 70s, there would be no consumer market for computing, and the few who would 'enjoy' it, would probably be confined to manipulating text data on green screen monitors.
"Pundits are only reporting what the trends tell them is happening."
Pundits are ignoring the trends towards connected desktop applications (away from regular desktop apps) which is proving to be more appealing than regular desktop apps and browser based apps.
Posted by P. Douglas | April 30, 2008 4:21 PM
portuno :
Why is this a smart move?
"If the PC can provide apps with far richer interfaces that have more versatile utilities, how is the move to be absolutely dependent on computing resources in the cloud (and an Internet connection) better?"
The PC can't provide apps with richer processing. The interfaces SHOULD be on the client, but, the processing resources needed to address any particular problem does not need to be on the client.
The kind of processing that can be done on a client doesn't need the entire library of functions available on the client.
If your hardware could bring in processing capabilities as they became necessary, the infrastructural footprint would be much smaller.
The amount of juggling the kernel would have to do to keep all things computational ready for just that moment when you might want to fold a protein or run an explosives simulation, would be reduced to the things the user really wants and uses.
An OS like Vista carries far too much burden in terms of memory used and processing speeds needed. THAT is the problem and THAT is why Vista will become the poster child for dividing up content and format and putting that on the client with whatever functionality is appropriate for local computing.
This isn't your grandfather's thin client.
"It is one thing to augment desktop apps with services to enable users to get the best of both (the desktop and Internet) worlds, it is another thing to forgo all the advantages of the PC, and take several steps back to cloud computing of old (the mainframe)."
Why does everyone always expect the extremes whenever they confront the oncoming wave of a disruption event? What is being made available is the proper delegation of processing power and resource burden.
You rightly care about a fast user interface experience. But, you assume the local client is always the best place to do the processing of the content that your UI is formatting.
The amount of processing necessary to accomplish building or providing the content that will be displayed by your formatting resources can be small or large. It is better to balance your checkbook on your client. It is better to fold a protein on a server, then pass the necessary interface data and you get to see how the protein folding is done in only a few megabytes... instead of terabytes.
"Quite frankly, if we kept on pursuing cloud computing from the 70s, there would be no consumer market for computing, and the few who would 'enjoy' it, would probably be confined to manipulating text data on green screen monitors."
We couldn't continue mainframing from that time because there was not a ubiquitous transport able to pass the kind of interface data needed outside of the corporate infrastructure.
Local PCs gave small businesses the ability to get the computing power in their mainframe sessions locally. And, until Windows, we had exactly that thin client experience on the "PC".
Windows gave us an improved "experience" but at the cost of a race in keeping hardware current with a kind of planned obsolescence schedule.
We are STILL chasing the "experience" on computers that can do everything else BUT formatting content well is STILL being chased - it's why "Glass" is the key improvement in Vista, is it not? It's why the "ribbon" is an "enhancement" and not just another effort to pack more functionality into an application interface...
THE INTERFACE. Not the computing. The interface; a particular amount of content formatted and displayed. Functionality is what the computer actually does when you press that pretty button or sweep over that pretty video.
Mainframes that are thirty years old connected to a beautiful modern interface can make modern thin client stations sing... and THAT is what everyone has missed in this entire equation.
Web platforming allows a modernization of legacy hardware AND legacy software without having to touch the client. When you understand how that happens, you will quickly see precisely what the pundits are seeing. That's why I said: 'Pundits are only reporting what the trends tell them is happening.'
"Pundits are ignoring the trends towards connected desktop applications (away from regular desktop apps) which is proving to be more appealing than regular desktop apps and browser based apps."
Do you know WHY "Pundits are ignoring the trends towards connected desktop applications"? Because there aren't any you can get to across the internet! At least until very recently.
If you're on your corporate intranet, fine. But, tell me please, just how many "connected desktop applications" there are? Microsoft certainly has little and THAT's even on their own network protocols.
THAT is what's ridiculous.
XML allows applications to connect. Microsoft invented SOAP to do it (and SOAP is an RPC system using XML as the conduit) and they can't do that very well. Only on the most stable and private networks.
DO IT ON THE INTERNET and the world might respect MSFT.
The result of Microsoft not being on the internet is their own operating system is being forced into islandhood and the rest of the industry takes the internet as their territory.
It's an architectural thing and there's no getting around those. It's the same thing you get when you build a highway interchange. It's set in concrete and that's the way the cars are going to have to go, so get used to it.
Lamenting the death of a dinosaur is always unbecoming. IBM did it when The Mainframe met the end of its limits in throughput and and reach. The PC applied what the mainframe could do on the desk.
Now, you need a desktop with literally the computing power of many not-so-old mainframes to send email, shop for shoes, and write letters to granny. Who's idea of proper usage is this? Those who want a megalith to prop up their monopoly.
The world wants different.
Since there are broadband leaps being carved out in the telecommunications industry, the server can do much more with what we all really want to do than a costly stranded processor unable to reach out and touch even those of its own kind much less the rest of the world's applications.
The mentality is technological bunkerism and is what happens in the later stages of disruption. It took years for this to play out on IBM.
It's taken only six months to play out on Microsoft and it's only just begun. We haven't even reached the tipping point and we can see the effect accelerating from week to week.
It's due to the nature of the media through which the change is happening. With PC's the adoption period was years. With internet services and applications, the adoption period is extremely fast.
Posted by portuno | April 30, 2008 11:55 PM
P. Douglas :
"The kind of processing that can be done on a client doesn't need the entire library of functions available on the client.
If your hardware could bring in processing capabilities as they became necessary, the infrastructural footprint would be much smaller.
The amount of juggling the kernel would have to do to keep all things computational ready for just that moment when you might want to fold a protein or run an explosives simulation, would be reduced to the things the user really wants and uses."
How then do you expect to work offline? I have nothing against augmenting local processing with cloud processing, but part of the appeal of the client is being able to do substantial work offline during no connection or imperfect / limited network / Internet connection scenarios. Believe me, for most people, limited network / Internet connection scenarios occur all the time. Also, the software + software services architecture minimizes bandwidth demands allowing more applications and more people to benefit from an Internet connection at a particular node. In other words, the above architecture is much more efficient than a dumb terminal architecture, or the one that you are advocating. This means that e.g. in a scenario where you have a movie being downloaded to your Xbox 360, several podcasts automatically being downloaded to your iTunes or Zune client software, your TV schedule being updated in Media Center, your using a browser, etc., and the above being multiplied for several users and several devices at a particular Internet connection, the software + software services architecture is seen to be far better and more practical than a dumb terminal architecture.
Posted by P. Douglas | May 1, 2008 8:04 AM
portuno :
@ P. Douglas,
"How then do you expect to work offline?"
Offline work can be done by a kernel dedicated to the kind of work needed at the time. In other words, instead of a megalith kernel (Vistas is 200MB+) running all functions, you place a kernel (an agent can be ~400KB) optimized for the specific kind of work to tbe done. This kernel can be very small (because it won't be doing ALL processing - only the processing necessary for the tasks selected - it can be only one of multiple kernels interconnected for state determinism) and the resources available online or offline (downloaded when the task is selected).
The big "bugaboo" during the AJAX development efforts in 2005 and 2006 was "how do you work offline"? The agent method places an operational kernel on the client which is a mirror (if necessary) of the processing capability on the remote server. When the system is "online", the kernel cooperates with the server for tasking and processing. When the client is "offline", the local agent does the work, then synchs up the local state with the server when online returns.
No online-offline bugaboo. Just a proper architecture. That's what was needed and AJAX doesn't provide that processing capability. All AJAX was originally intended to do was to reduce that latency between client button push, server response and client update..
"...part of the appeal of the client is being able to do substantial work offline during no connection or imperfect / limited network / Internet connection scenarios."
Correct. And you don't need a megalithic operating system to do that. What you DO need is an architecture that's fitted to take care of both kinds of processing with the most efficient resources AT THE TIME. Not packaged and lugged around waiting for the moment.
"...limited network / Internet connection scenarios occur all the time."
Agreed. So the traditional solution is to load everything that may ever be used on the client? Why don't we use that on-line time to pre-process what can be done and load the client with post processing that is most likely for that task set?
"Also, the software + software services architecture minimizes bandwidth demands allowing more applications and more people to benefit from an Internet connection at a particular node. In other words, the above architecture is much more efficient than a dumb terminal architecture, or the one that you are advocating."
"More efficient" at the cost of much larger demands on local computing resources. Much larger demands on memory (both storage and runtime). Much larger demands on processor speed (the chip has to run the background load of the OS plus any additional support apps running to care for the larger processing load you've accepted).
You will find there will be no "dumb terminals" in the new age. A mix of resources is what the next age requires and a prejudice against a system that was limited by communications constraints 20 years ago doesn't address the problems brought forward by crammed clients.
"This means that e.g. in a scenario where you have a movie being downloaded to your Xbox 360, several podcasts automatically being downloaded to your iTunes or Zune client software, your TV schedule being updated in Media Center, your using a browser, etc., and the above being multiplied for several users and several devices at a particular Internet connection, the software + software services architecture is seen to be far better and more practical than a dumb terminal architecture."
At a much higher cost in hardware, software, maintenance and governance.
Companies are not going to accept your argument when a fit client method is available. The fat client days are spelled out by economics and usefulness.
Because applications can't interoperate (Microsoft's own Office XML format defies interoperation for Microsoft - how is the rest of the world supposed to interoperate?) they are limited in what pre-processing, parallel processing or component processing can be done. The only model most users have any experience with is the fat client model... and the inefficiencies of that model are precisely what all the complaining is about today.
Instead of trying to justify that out-moded model, the industry is accepting a proper mix of capabilities and Microsoft has to face the fact (along with Apple and Linux) that a very large part of their user base can get along just fine with a much more efficient, effective and economical model - being either thin client or fit client.
It's a done deal and the fat client people chose to argue the issues far too late because the megaliths that advocate fat client to maintain their monopolies and legacies no longer have a compelling story.
The remote resources and offloaded burdens tell a much more desirable story.
People listen.
Posted by portuno | May 1, 2008 12:07 PM
P. Douglas :
"Offline work can be done by a kernel dedicated to the kind of work needed at the time. In other words, instead of a megalith kernel (Vistas is 200MB+) running all functions, you place a kernel (an agent can be ~400KB) optimized for the specific kind of work to tbe done. This kernel can be very small (because it won't be doing ALL processing - only the processing necessary for the tasks selected - it can be only one of multiple kernels interconnected for state determinism) and the resources available online or offline (downloaded when the task is selected)."
I don't quite understand what you are saying. Are you saying computers should come with multiple, small, dedicated Operating Systems (OSs)? What do you do then when a user wants to run an application that uses a range of resources spanning the services provided by these multiple OSs? Do you understand the headache this will cause developers? Instead of having to deal with a single coherent set of APIs, they will have deal with multiple overlapping APIs? Also it seems to me that if an application spans multiple OSs, there will be significant latency issues. E.g. if OS A is servicing 3 applications, and one of the applications (App 2) is being serviced by OS B, App 2 will have to wait until OS A is finished servicing requests made by 2 other applications. What you are suggesting would result in unnecessary complexity, and would wind up being overall more resource intensive than a general purpose OS - like the kinds you find in Windows, Mac, and Linux.
"The agent method places an operational kernel on the client which is a mirror (if necessary) of the processing capability on the remote server. When the system is "online", the kernel cooperates with the server for tasking and processing. When the client is "offline", the local agent does the work, then synchs up the local state with the server when online returns."
The software + services architecture is better because: of the reasons I indicated above; a user can reliably do his work on the client (i.e. he is not at the mercy of an Internet connection); data can be synched up just like in your model.
""More efficient" at the cost of much larger demands on local computing resources. Much larger demands on memory (both storage and runtime). Much larger demands on processor speed (the chip has to run the background load of the OS plus any additional support apps running to care for the larger processing load you've accepted)."
Local computing resources are cheap enough and are far more dependable than the bandwidth requirements under your architecture.
"At a much higher cost in hardware, software, maintenance and governance.
Companies are not going to accept your argument when a fit client method is available. The fat client days are spelled out by economics and usefulness."
Thin client advocates have been saying this for decades. The market has replied that the empowerment, and versatility advantages of the PC, outweigh whatever maintenance savings there are in thin client solutions. In other words, it is a user's overall productivity which matters (given the resources he has), and users are overall much more productive and satisfied with PCs, than they are with thin clients.
Posted by P. Douglas | May 1, 2008 2:27 PM
portuno :
P. Douglas:
"I don't quite understand what you are saying. Are you saying computers should come with multiple, small, dedicated Operating Systems (OSs)? "
What would you think Windows 7 will be? More of the same aggregated functionality packaged into a shrinkwrapped package? Would you not make the OS an assembly of interoperable components that could be distributed and deployed when and where needed, freeing the user's machine to use the hardware resources for the user experience rather than as a hot box for holding every dll ever made?
"unnecessary complexity"????
Explain to me how a single OS instance running many threads is less complex than multiple OS functions running their own single threads and passing results and state to downstream (or upstream if you need recursion) processes.
What I've just described is a fundmental structure in higher end operating systems for mainframes. IBM is replacing a system with thousands of servers with only 33 mainframes. What do you think is going on inside those mainframes? And why can't that kind of process work just as well in a single client or a client connected to a server or a client connected to many servers AND many clients fashioned into an ad hoc supercomputer for the period needed?
"Thin client advocates have been saying this for decades."
The most dangerous thing to say is "this road has been this way for years" and driving into the future with your eyes closed.
If your position were correct, we would never be having this conversation. But, we ARE having this conversation because the industry is moving forward and upward and leaving behind those who say "...advocates have been saying this for decades...".
Yada Yada Yada
Posted by portuno | May 1, 2008 3:48 PM