Mittwoch, 2. April 2003

Even more on UDDI UDDI provides the opportunity for metadata to describe the services, and the likely response here will be that "This will be one of the constraints you can establish when querying UPS, FedEx and DeutschePost for the service", but that presumes that I don't have some kind of partner-based relationship with one or the other; in short, it doesn't reflect the larger business concern that I want to cut deals with companies to give them exclusive access to my business in exchange for price breaks, priority service, and whatnot.  [The Mountain of Worthless Information]

That's just why I distinguish between global and local registries. You'll only dispatch from you local UDDI registry. That will only have services registered that you trust and that you have an estalished relationship (and SLA) with. The power is that you can add and remove services from there without having to change anything in your code and it is a consistent place and a consistent model to do so for any service. The global UDDI registries are yellow pages, the local UDDI registry (yours) is a Rolodex(tm).


11:14:16 PM      comments []

Microsoft sets Office bundling terms. Microsoft will not include InfoPath and OneNote as part of the Office suite sold at retail or installed on new computers. [CNET News.com]

There are things I will probably never understand. The Office bundling is one of them. I have a hard time figuring out why InfoPath shall only be an "Enterprise" thing.


6:09:15 PM      comments []

There's an interesting comment on Ted Neward's blog which is related to what I've been saying here:

Ian Fairman wrote:
This whole approach of munging your own shipping request schema to the parcel company's schema reminds me of how some people would tout entity beans as reusable simply by using object-relational mapping tools to map them to 3rd party database schemas. Unfortunately the "magic" in these mapping tools can be quite easily fooled by extra fields in either the bean or the database table - what do you do with them? And that is probably the simplest problem you'd meet. This mapping magic is a pipe dream. The real solution is to define standard schemas. Getting everyone to agree on these schemas may be a pain in the arse but at least it will work when you've done it.

The problem with the standardization and agreement dream is that it is indeed much less realistic than doing all the mapping work. What we need are stable schemas that we can rely on and map from and to, but not necessarily standardized ones. Until you get people from all state-owned postal services around the world and all the private courier and parcel services to agree on a set of schemas to use in unmodified form (or all banks, or all whatever-you-choose-industry), XML has likely already been replaced by the next thing. 

Message standards are hard to agree on. If you look at EDIFACT or ANSI X.12, you'll find that neither really defines something like a schema. Both standards define "dictionaries" of segments which you can choose from when you assemble/trim message definitions. An EDIFACT ORDERS message is never caught in the wild as specified in the EDIFACT dictionaries. In fact, it's already a messy manual task to go from one user's ORDERS to another user's ORDERS, because the precise implementations of ORDERS may differ wildly.

Even worse ... what if industry A agrees on a standard format for exchanging purchase orders and industry B does the same for themselves and now a company from industry A wants to purchase something from a company in industry B. Poof!

The moment the first company came up with a graphical, easy-to-understand editor for XML Schema, the whole standardization hope was gone out the window already. Everyone can define schema and if they can, they will. Now with stuff like InfoPath, my Dad can even define schema. It's not going to be pretty, but it is schema.

If one out of 500 companies doesn't support a "standard schema" or even augments it with their own idea of certain things and that one company happens to be a big fish, forget standardization. You will have to understand what they mean and you will have to map between schemas. Schema standardization won't work on a grand scale and it will just not happen.

At the same time, "generic mapping" won't work, unless we take metadata much further than we do now and start to formalize semantics. The "semantic web" efforts go into that direction, but there's plenty of work to be done. In the absence of standardization, mapping between schemas is a growing necessity and while it seems like an ugly job -- it is a job. It's a manual job. There's no magic here. And it surely will create jobs. It's simply a necessary new field in programming and it's begging for better tools.


4:01:35 PM      comments []

More on UDDI. [...] OK, UDDI-as-the-yellow-pages I'll buy, but this idea of "give me the WSDLs for those services" implies that I'm going to dynamically invoke a web service, meaning now essentially you're tying me into a loose-binding situation similar to writing Java or .NET Reflection code. Quite frankly, I don't buy this argument whatsoever--I *need* to have some idea of the service I'm trying to invoke, otherwise, how can I know what to pass where? I recognize this idea of "dynamic glue" is an attractive one, allowing me to walk up to any web service at runtime and consume it without any a priori knowledge whatsoever, but this is akin to suggesting that I can write a generic Java user interface that can gather any sort of data from the user without any sort of a priori knowledge whatsoever, driven by an XML file--you can do it, but boy will the UI suck. I'm still not convinced that UDDI is worth saving from the cliff; essentially we're talking about a naming/directory server (remember I can always attach attributes to an entry in an LDAP-like environment), coupled with dynamic binding at runtime of the endpoints. I still don't see the value here. [The Mountain of Worthless Information]

Get over RPC. Think messages. Get over coding and programming models. Think data.  

When you have a choice of three different services to call -- I will stick with my previous example -- one at UPS, one at FedEx and one at Deutsche Post, you will always know what data you have to give them and you know what you want from them. The challenge is to find those services by meaningful criteria and to map from your internal representation of data to their representation and back. Precisely, it's about mapping their idea of representing well-understood and agreed semantics into your representation of the same semantics. The global UDDI space (public registries) is the place where you can locate those services in general, the local UDDI space (enterprise registry) is where you can augment this information with your own metadata and mapping information.

All of this and Web services in general are not about taking someone's WSDL, code-generating a proxy and calling that proxy via reflection. That's RPC or Automation. That's last century's technology. That's old programming. The center of programming is shifting towards messaging. Enjoy.


11:37:12 AM      comments []

Don points out that "IBM" is a recursive acronym.
11:24:20 AM      comments []