[via Roland Tanglaos and Globeblogger] HBR has an article about Syndication:

What makes feeds so powerful? Say a consumer is a Thomas Pynchon fan and would like to know when any first editions of Gravity’s Rainbow go up for auction on eBay. If she’s not subscribing to syndication feeds, she might bookmark a search and then make a note to herself to do that search regularly. And if there were other items she wanted to troll for on eBay, she would have to bookmark those searches, too. In addition, if she wanted to know when she’d accumulated enough frequent flyer miles to book a free trip to Delhi, and when a new job was posted by a certain company, she could add those bookmarks to her list and try to remember to check them. It’s a cumbersome and unreliable system.

But, if she were to subscribe to syndication feeds, the information she’s after would instantaneously flow to her with virtually no effort on her part. She’d be alerted the moment Gravity’s Rainbow appeared, the moment more frequent flyer miles hit her account, the moment the job was posted, and so on.

What sort of information should companies syndicate? The better question is perhaps, What sort shouldn’t they syndicate? Countless data-generating events in your organization are candidates for syndication. Corporate news is an obvious place to start. But syndication should not stop with press releases.

If your organization is a shipping company, for example, why not turn order status into a feed? If it’s a manufacturer, why not turn shop-floor flow into a feed? Disney already uses feeds to distribute news content, but it also uses them internally to share information about ongoing projects. Status updates and information on project workflow stream out to team members and managers who subscribe to the feed.

Dina Mehta points to an InfoWorld article about NearTime's Flow and Learning Management Solutions' KnowledgeWorkshop.

Near-Time last week launched Flow, its peer-to-peer CM (content management) and KM software that allows users to access, manage, and repurpose content using a range of standards. Support for XML, HTML, RSS, Atom FTP, WebDAV, and SMTP allows Flow to target the full information lifecycle, said Reid Conrad, president and CEO of Near-Time.

This life cycle includes gathering, authoring, organizing and publishing content. "Through the [Flow] authoring environment, users can access the Internet, bring in RSS feeds, use contextual capabilities, and publish content as e-mail," Conrad said. "Flow provides collaborative content and knowledge management at the client level."

Also approaching KM from the user's perspective, Learning Management Solutions last week introduced its company and its KnowledgeWorkshop software. The software allows users to create personally relevant associations and connections between information drawn from a variety of sources, including Web pages, e-mail, documents, PowerPoint slides, databases, and spreadsheets. These connections form an information map, called a knowledge base, that is packed down into a single XML file that can be e-mailed or exchange online, said Graham Glynn, CEO of Learning Management Solutions.

The New York Times Magazine has a cover story on China:

China is everywhere these days, influencing our lives as consumers, providers, citizens. It has by far the world's most rapidly changing large economy, and our reactions to it shift just as quickly. China is at one moment our greatest threat, the next our friend. It siphons off American jobs; it is essential to our competitive edge. China is the world's factory floor, and it is the world's greatest market opportunity. China's industrial might steals opportunities from the developing world, even as its booming economy pulls poorer countries up (lately it has been getting credit for helping Japan out of its slump too). China exports deflation; it stokes soaring prices. China will boom; it will bust. Or perhaps the country's economy is feeling its way right now to the soft landing that will prevent another Asian economic crash, and all the recent record numbers on trade, industrial output, consumer spending and debt are simply now in scale with China's size. The truth about China is that, like all big countries, it is full of real contradictions.

Another truth is that the current feelings about China do not fully reflect today's reality. The U.S. economy is about eight times the size of China's. Our manufacturing sector is bigger than the entire Chinese economy. Americans, per capita, earn 36 times what the Chinese do. And there is no shortage of potential roadblocks in China's path, either. Its banks may collapse. Its poor and its minorities may rebel. Uppity Taiwan and lunatic North Korea may push China to war. The U.S. could slap taxes on everything China ships to us.

Still, barring Mao's resurrection or nuclear cataclysm, nothing is likely to keep China down for long. Since 1978, its gross domestic product has risen fourfold; in straight dollar terms, China's economy is the world's sixth-largest, with a G.D.P. of around $1.4 trillion. It has gone from being virtually absent in international trade to the world's third-most-active trading nation, behind the U.S. and Germany and ahead of Japan. Tom Saler, a financial journalist, has pointed out that 21 recessions, a depression, two stock-market crashes and two world wars were not able to stop the U.S. economy's growth, over the last century, from $18 billion ($367 billion in 2000 dollars) to $10 trillion. In constant dollars, that is a 27-fold increase.

China is poised for similar growth in this century. Even if China's people do not, on average, have the wealth Americans do, and even if the United States continues to play a strong economic game and to lead in technology, China will still be an ever more formidable competitor. If any country is going to supplant the U.S. in the world marketplace, China is it.

Amaretto is Nokia's Python for Series 60. Russell Beattie has been playing around with it and has some thoughts:

You can run Python files that are on your phone in regular .py format (this you've seen from the public demos of the app), or you can wrap up the .py files into a .SIS Symbian installation file with its own icon, so that the user never knows that it's Python. Very cool - I mean, obvious, but cool. In terms of development, the SDK comes with both Windows and phone versions of the application and core libraries, so you can do testing in the emulator before sending to your phone. Again, this is great - as the command line intepreter may not be all that useful with a phone's keypad, on the emulator it's vital.

What I've been looking at doing is creating an RSS news aggregator. Of course! If you think about it, this would take networking and xml parsing, UI integration and also things like browser integration or at least some sort of rich text. (The latter bits aren't supported right now). An aggregator is a great sample app for Amaretto because it mimics real-world enterprise usage: client-server communication via XML with forms and offline storage. Getting a good aggregator working on Python would go a long way to proving it's capabilities in the corporate world, IMHO. So as I explore the language and libraries, this is something I'm concentrating on.

Another cool part of Amaretto that most people won't know just from hearing about the project, is that it supports Python's standard C wrapper interface! This is cool because in theory, you could have heads-down developers crank out the really intense parts of your Symbian application in C++, then they can simply create a wrapper for the Python guys, who use that as a base and then develop UIs and interactivity from there. This could reduce development times substantially. In some respects it does harken back to the bad-old OCX days of VB, but honestly, I think this is a really good model for mobile apps because of the resource constraints. Actually it could inspire an OCX-like tools market, or if not, it'll at least allow the developer community to start quickly adding functionality that may not be in the basic Nokia libraries at launch. Nokia is concentrating on just getting the basics down right now, so there will be lots of gaps that can be filled in by creative developers, I'm sure.

The reason I'm so concerned about the enterprise market is because that's where I see Microsoft making its play in to mobile world: selling to large corporations with applications developed in .Net Compact, touting their rapid VB-like development and tight integration with Outlook/Exchange. Nokia can pre-empt this move by providing Series 60 with a compelling RAD language which does much of the same, but has the cachet of being from the Open Source world, and fits in great with all those new Linux boxen that more and more companies are installing on their intranet. Nokia could even publish custom libraries itself for integration with it's NokiaOne enterprise products, and expand the functionality and applicability of Amaretto to the enterprise even more.

WSJ has an article by Technology Review:

Right now, the first cellphones featuring 3-D graphics are appearing in Japan and Korea. In the coming months, we'll start to see the first numbers to indicate how well Asian consumers take to the new phones. And starting at the end of this year, we'll likely see the first 3-D phones hit the U.S.

Three-dimensional games will enter a U.S. cellphone market primed for their arrival, with two main factors driving the desire for more full-featured games. First, hundreds of cellphone game titles are now available from companies such as Sorrent, JamDat and THQ's wireless division, and the sector is growing fast. Research firm IDC projects the U.S. cellphone game market will grow from $394 million today to $1.7 billion in 2008. Moreover, phones have upped their storage capacities. And color screens, once available only for high-end phones, are now showing up even in inexpensive models.

3-D graphics technology in cellphones will allow games to evolve from the flat, simple facsimiles of popular titles of today to more exact replicas of these games. And with the promise of better, network-ready games comes the prospect of additional revenues for wireless carriers and phone manufacturers. "[Cellular companies] are recognizing that people like games," says Schelley Olhava, a videogame analyst at IDC.

When we talk about 3-D technology on cellphones, we're not talking about displays that require funny-looking glasses to appreciate, but rather, the visual style that requires more processing power than today's cellphone engines provide. And three-dimensional games -- first-person shooters such as Doom and Quake, role-playing titles such as The Sims, and flight simulators -- have proven their popularity with the public. The cellphone industry is rightfully excited about what 3-D games on phones portend. "The more compelling the game, the more time the user will play them," says Alex Slawsby, a cellphone analyst with IDC. "If the games have an online component, it means more time spent on data services."

XML.com provides an overview:

SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners.

This sounds a bit too abstract, but SOA is actually everywhere. Let's look at an example of SOA which is likely to be found in your living room. Take a CD for instance. If you want to play it, you put your CD into a CD player and the player plays it for you. The CD player offers a CD playing service. Which is nice because you can replace one CD player with another. You can play the same CD on a portable player or on your expensive stereo. They both offer the same CD playing service, but the quality of service is different.

The idea of SOA departs significantly from that of object oriented programming, which strongly suggests that you should bind data and its processing together. So, in object oriented programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it's the way we have built many software systems.

The results of a service are usually the change of state for the consumer but can also be a change of state for the provider or for both. After listening to the music played by your CD player, your mood has changed, say, from "depressed" to "happy". If you want an example that involves the change of states for both, dining out in a restaurant is a good one.

The reason that we want someone else to do the work for us is that they are experts. Consuming a service is usually cheaper and more effective than doing the work ourselves. Most of us are smart enough to realize that we are not smart enough to be expert in everything. The same rule applies to building software systems. We call it "separation of concerns", and it is regarded as a principle of software engineering.

How does SOA achieve loose coupling among interacting software agents? It does so by employing two architectural constraints:
1. A small set of simple and ubiquitous interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers.
2. Descriptive messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services.

As illustrated in the power adapter example, interfacing is fundamentally important. If interfaces do not work, systems do not work. Interfacing is also expensive and error-prone for distributed applications. An interface needs to prescribe system behavior, and this is very difficult to implement correctly across different platforms and languages. Remote interfaces are also the slowest part of most distributed applications. Instead of building new interfaces for each application, it makes sense to reuse a few generic ones for all applications.

Tomorrow: ASPs