Archive for September, 2005

You can’t always get what you want

Sunday, September 25th, 2005

And in this case I got something I didn’t know I wanted. Tickets to a Rolling Stones concert in Columbus, OH. It was awesome. _Miss(ed) you._ But thats how the _tumbling dice_ fall.

Did you know that Mick Jagger can move better than I can? And he’s at the ripe age of 62.

Mossberg blasts GMail

Wednesday, September 21st, 2005
I’m sure Gmail will get better and better, and will eventually adopt the new programming techniques that allow desktop-like ease of use. But I’m not sure Google’s arrogance will ever make room for user preferences on things like folders or ads, or how emails are grouped. Yahoo’s new email program would blow Gmail away if it were widely released today. That’s partly due to its features, but also to its respect for user choice.

Full WSJ text here.

WS-JustRight, Two Way RSS

Wednesday, September 21st, 2005

Jon Udell posted a lengthy article about WS-JustRight which is unnervingly relavent for my post yesterday.

For Grossman and others, WS-JustRight means using SOAP and WSDL to strike a balance between formal contracts and agile interoperability, while laying a foundation for future use of more advanced SOA features. PGP’s Brodbeck agrees that WSDL is the key enabler of reusable business transactions and processes. He also extends the definition of WS-JustRight, however, to include enterprise-enabled RSS as the key enabler of reusable content.

I’m interested in learning more about RSS in the enterprise. Right now I associate RSS with polling and uni directional. What will be the enabler of two way RSS on a larger scale? I’m thinking it would be cool to make a little publish subscribe application via SOAP over XMPP which pushes out RSS/Atom data. Maybe I have a weekend project on my hands.

Coordination, SOA, and control

Tuesday, September 20th, 2005

I’ve been putting a lot of thought lately into coordination as it relates software, people and organizations.

On one end we have email, RSS/Atom, and web. All very loosely coordinated. Nearly everyone has email (hey Warren Buffet, you listening?), nearly everyone uses the web, and more and more people are aware of RSS/Atom. People can go out and start sharing information in a very loosely coordinated fashion. This comes at the expense of the ability to capture domain specific data or provide high security. When you move into the enterprise things fall apart.

Which brings me to the other end of the spectrum – I’ll loosely refer to it as SOA for now. With web services industry, groups, organizations, and even individuals can create domain specific languages. We have a broad basis of web service specs now (SOAP, WSDL, WS-Addressing, WS-Security, WS-….). On top of this people are developing specs like the Physical Markup Language which is a way to share RFID data. While RSS could embed this data, it isn’t really suited for it. There a couple problems with the SOA approach though…

Thought

When embarking on the SOA approach it requires a lot of up front thought. One must develop schemas, wsdls, etc. One must get every department to agree on a schema. One must worry about extensibility and versioning. And then there is scalability. And then there is choosing the right software platforms.

Coordination

If you do anything outside your organization it requires a lot coordination. For instance in a very fragmented industry (i.e. logistics), no one player can establish The Standard for everyone else. Getting everyone on board for a standard can take years. And there are huge benefits to sharing the data NOW.

Agility

Of course once you’ve decided on a standard, its already nearly worthless. But you’ve probably already committed to the software as well for the forseeable future. What happens when you need to extend? Or even worse – you need somethign radically different?

Data Control

All the above are issues, but one concerns me more than the others. Data control. Lets take the example of RFID. This page says it all, but let me describe. An item tagged via RFID will pass from a supplier, to a warehouse, to a distributor, to a retailer. Each one of these people contains a piece of information about the product as it passes through the suppline chain.

Who owns this data? How do we get at it?

Central storage? As a manufacturer you going to require every warehouse that you work with to send their data to your database?

What about distributed query of all the partners? Will every warehouse that you use be willing to adopt the same interfaces so you can query the particular tag? Will you have to write software against each partner’s interface?

What about security? Limiting subsets of data to specific people is hard, but not insurmountable. But a twist is that there may be an implicit trust relationship involved. If I am a manufacturer, my transportation provider may be partnering with a warehouser. Since my transportation provider trusts me, can I access the warehouse database?

Does the manufacturer have an implicit ownership right to the rfid data generated at the warehouse? Even if they have a right to it, how do we get at it and do we share it in a meaninful fashion? Can the warehouser charge extra for the data?

Data ownership and control brings up a lot more questions than it answers. Will SOA, ESBs, ERPs, middleware, and a host of technologies save us from data hell? I feel there must be a better way, but I have no real answers.

Virtual Earth Commercial License

Friday, September 9th, 2005

Following up on my recent post on mapping APIs, it appears Microsoft has straightened out its licensing and you can use Virtual Earth for commercial usage. Chandu writes

You can use the Virtual Earth APIs for free as long as you use the What/Where search boxes on your map. This is also makes sense from a revenue stand point since you will have the opportunity to make money by placing advertisements on your site in a revenue sharing model (more details to be announced at a later date)

Chandu also says that if you don’t want to abide by the above you can get a MapPoint.NET license and that will cover your usage. This is great news!

Mapping Deathmatch

Tuesday, September 6th, 2005

Doing some map hacking today. However, I’m coming up frustrated at the lack of solutions which have good answers to all of the following.

  Google Yahoo Virtual Earth MapPoint.NET
Embeddable Yes No. Must embed a frame of Yahoo’s web page Yes Must write SOAP client
Commercial Use Yes, but you can’t charge to see the map. Yes Not yet. Yes
Geocoding No. Can use geocoder.us Yes Yes Yes
Routing No No No Yes
Cost Free Free Free A lot

VirtualEarth has the coolest Javascript API. Its killer flaw is that it can’t be used commercially yet. Google Maps looks good, but lack of geocoding is sucky. geocoder.us costs money for commercial use, although cheap. I may just write my own geocoder using the Tiger data. I’d like to have Canadian geocoding though too. Yahoo Maps would really rock if I didn’t have to embed their stupid web page in mine. Last, the MapPoint web service rocks, but startup is really expensive. I’d gladly pay $100/mo but I think its roughly $8K/yr minimum with MapPoint.

sigh