TechEd!
So.... I just got the word that I am confirmed as speaker at TechEd Dallas (my first major U.S. Microsoft conference) Of course I'll be at TechEd Barcelona, too. I may even go to TechEd South Africa in Sun City. We'll see.
Anyways, the title of my session ".NET Web Services Internals: I didn't know you could do that!" promises more whacky demos, more attributes, more WSDL hacking (I use while it lasts ;) and more black magic done by the ASMX runtime. The other session is about AOP and may come with some surprises as well ;)
Me, with big time jet lag, on video, talking about SOA and AOP.
I listened to "Service-Oriented Architectures", presented by Clemens Vasters at the EMEA Architects Tour. Its a great description of SOAs and Clemens makes several thought-provoking points. Thanks to Harry Pierson for the link.
Best line of the presentation:
We owe XML to our children.
True. True.
MS Finland actually put the whole Architect's Tour event up on this site. Very interesting talks in general. The "politically" most amazing is the J2EE/.NET interop talk where Arvindra Sehmi and Gianpaolo Carraro ("Architecting an Interoperability Framework") show a JBoss app interopping with the exact same app written on .NET -- being MS people. Their design allows it to cut the app at several points and have the slices run on either side of the "technology fence". Web services rock.
A truly priceless gem is Rafal Lukawiecki's talk on the Microsoft Operations Framework and his Security talk is just as good. Rafal was "best speaker" at the last two runs of TechEd Europe for good reasons. We've run this event 8 times now and I believe that I haven't beaten him even once in the evals. I get reasonably close, but he's always ahead. No envy here -- only deepest respect for the European master of tech speech.
Take two days off and listen ;)
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.
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).
There's an interesting comment on Ted Neward's blog which is related to what I've been saying here:
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.
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.
A place for UDDI after all?. [...] I can understand the desire to see WSDL die--Lord knows, after having experienced firsthand the complications of building a truly interoperable web service using WSDL, I share his desire entirely--but I still don't see the relevance of UDDI in the service-oriented architecture. In many ways, it feels like Don and Clemens want UDDI to turn into some kind of centralized "workflow" (although I hate using that word in this context, since it clashes with what I consider workflow to be) repository, acting as a router from service to service, a layer of indirection to keep processing nodes in the chain from having to know the next and previous nodes in the chain. And it just feels to me like UDDI, having not really been designed for that, won't be the best choice for doing that--perhaps we'd be better off with a new implementation with less baggage? Or am I just missing something somewhere? [The Mountain of Worthless Information]
The answer is: It's the yellow pages. No, it's actually the yellow pages plus custom, extensible, and queryable metadata. You walk up to your enterprise UDDI registry and say (the formal equivalent of) "I have a bunch of packages here, all between 5kg and 20kg and I would like to have a truck in front of my building at 4pm this afternoon which will pick them up and I want them to be sent overnight to several places in Europe". UDDI answers: "Here are the service references for FedEx, UPS and Deutsche Post".
Then you say to UDDI: "Please give me the WSDLs for those services and a reference to the XSLT mappings that I have stored in the registry to map my internal XML Schema for shipping requests and shipping cost inquiries to the XML Schema for the respective messages in those WSDLs". UDDI says: "Here you go".
Then you make "give me today's shipping prices for those packages" calls to a local endpoint which takes a request using a Schema you defined, the local endpoint maps your internal schema to one of the remote service's schema, and then routes the call to the remote services. One to FedEx, one to UPS, one to Deutsche Post. You get back three prices, pick the lowest one and make a similar "come pick up the packages" call to the winner. At 4pm there'll be a truck.
The shorter answer: UDDI powers business logic driven "class factories".
Steve and Clemens all over Europe.
This going to be great fun! I will be doing a speaking tour with my friend Steve Swartz (who was/is the architect of most of the new things in Windows Server 2003's COM+ 1.5). The topic is scalable application architectures and we have given it the unmarketable title "Scale, extend, stay running and don't forget to lock the door".
It's 7 cities (Warsaw, Bukarest, Moscow, Copenhagen, Oslo, Paris, Lisbon) in two weeks. The party starts April 22 in Warsaw. At most Microsoft subsidiaries the event will unfortunately be "invite only" due to organizational (space) constraints, but at least in Denmark, everyone can apparently sign up.
Expect us talking, discussing, agreeing and disagreeing about layers, tiers, process models, transactions, patterns, anti-patterns, security, Enterprise Services and other interesting things and expect the one or the other hint at the future of Web Services....
Dear W2K, dear WXP. Thanks. You both served me well. This week I will be switching to the next generation for good.
AOP demo.
MS Finland put up a (long, 30min.) Windows Media 9 series stream of the demo that I did in my AOP talk over in Helsinki. And Matt Powell from MSDN is so nice to mention the things I demo there in his MSDN TV episode on SoapExtensionReflectors/Importers. My demo code is here.
Reconsidering UDDI
For the record: I was wrong when I said this here. When I started to look into and think about service oriented architectures*, I understood the relevance of UDDI.
To cite Don (more than half a year ago): "If WSDL and UDDI were both hanging from a cliff and I could only save one of them, it would be UDDI." And in case someone didn't notice, yet, I really, really want WSDL to go very near that cliff.
[*this is the most current deck for the SOA talk I do on the Microsoft EMEA Architect's Tour 2003. Check out slide 20 for an illustration of how WS-Routing, WS-Addressing, WS-Policy, message contracts and UDDI fit into a single picture]
Messaging rules.
I haven't blogged or even read blogs for almost two weeks. Too much time on the road. Reading (UK), Zürich, Hannover, Bled (Slovenia), Amsterdam, Budapest. Next week it's Bad Ems and then it'll be Athens, Madrid and Milano in the following two weeks.
Anyways... I find it very interesting that more and more people are seeing the light in regards to the true potential of Web Services (could someone please drop the "Web" term from that?): Messaging. We're getting there ...
IIS 6.0 process model in a nutshell
Sam Gentile has blogged a compact overview on the IIS 6.0 process model. Because pictures say more than a thousand words, I recommend that you get this PPT file from Bill Staples (Group Program Manager for IIS at MS) in addition to reading what Sam has to say.
The bigger language problem
C#? C++? VB? Java? English! Whenever I speak at conferences across Europe (right now that's about twice a week), every other attendee's first comment when talking to me after any speech will not be a technical one. Instead they say "your English is fantastic". People seem indeed surprised s'at mei englesh iss not vot s'ey vutt expeckt.
I don't think that it is a "fantastic skill", but rather just part of doing my job right. Having reasonable control of the language that is the "one and only" of the IT business -- and that happens to be (American) English -- is essential. I was lucky enough that my former employer sent me on a two year assignment to New York City in '95/'96 and that was the time where I got a sobering reality check on my "school English", picked up all the idioms that let me understand what the Americans are saying between the lines, and (somewhat unfortunately) had all my English teachers' efforts to provide me with a polished "British" spoiled for good.
There is a huge problem here. There are unknown (but large) numbers of very bright people out there, who simply cannot make themselves heard to a broader, world-wide audience just because they don't write and speak English "well enough". Also, English language skills are essential to understand anything happening on the "cutting edge" of computing, because there is always a considerable lag for specifications, books and white papers to appear in any other language than English.
Right now, it's more important for my company that people know English than knowing specifically Java, C#, VB, C++ or SmallTalk. If they have a good understanding of programming as such, it's a tiny step to switch between languages. However, even if they are fabulously eloquent and well read in German, they still may not be able to get a single understandable English sentence together and, just as bad, may miss implied statements in English material they read.
Can we fix this? The answer is certainly not to lament about "language imperialism". The answer is to deal with the facts as they present themselves today and for the future as far as we can see ahead. Being "proudly European", I think that in order to be able to successfully compete with America in this industry, the Europeans, especially the French and the Germans, will have to start to understand that technical degrees must come with proper education in English on a level that's far beyond current "school English" and that a good deal of technical material should indeed be taught and tested in English. Likewise, students need to understand that it's not enough to be a German or French tech-geek. "My English is not very good" is unfortunately not a valid excuse if you are in the IT industry -- it's indeed even worse than saying "my C++ is not very good" when you apply for a systems programmer job.
What's really bad is that I am writing this in English. Sorry, I can't write it in all the languages in which it would matter to say this. Therefore I have to opt for a somewhat neutral choice.....
Sam has a new essay on nouns vs. verbs. Thank you, Sam. All roads lead to Rome. Rome doesn't care. ;)
W3C Web Services Description Group makes a good move.
While they are yet not as far as to they drop the ball, go home and call WSDL dead ;) but there's a noteworthy action item on the activity's task list as per their most recent teleconf call: "2003-03-13: Don [presumably Don Mullen from TIBCO and not Don Box from Microsoft] will write a proposal for annotating schema with part information.", which is an action item apparently added when they were talking about killing the <wsdl:message/> element. I am all for that.
When we get to the point that WSDL's job becomes not to describe a "Web Service", but rather only the applicable message exchange patterns (MEP) for a conversation between two points (which both may engage in other conversations following different MEP's), would kill the <wsdl:service/> binding (see WS-Addressing), and would then be appropriately renamed, I will be fairly happy with it.
Yet, looking at it that way, there should probably be only one WG for this instead of two. There's a Web services description and a Web services choreography WG and that's somewhat like one language designer designing "method" and another guy designing "interface" and looking at it as if they were only loosely related. Of course I may be entirely off base...
newtelligence should probably really join W3C and WS-I, so that I am not just a loud, complaining troublemaker, but an active, constructive troublemaker.
|