All posts by : XML Eye for the Object Guy

1 of 74 | ROA vs GET/POST - Bill deHora has a great response to one of my (somewhat) recent REST posts. The timing is perfect, because I've been thinking a lot about what I said in those posts. I've also just finished reading the RESTful Web Services book, which is the most useful technical book I've read in a while, and have been thinking a lot about what it says too (and talking about it with Craig). I've been mulling over a post for a couple of days, and Bill's post is the impetus I needed to share what I've been thinking. In RESTful Web Services, the authors define and argue the merits of Resource Oriented Architecture. ROA maps directly to the REST-as-CRUD model for thinking of the world, where interaction with ......

2 of 74 | Don asked for input... - I haven't been reading or writing much lately - too heads down getting to 1.0. But I did happen across Don's recent post about retiring the four tenets of SOA and asking for input on what we'd like to write when we implement services. Let me take these topics in order. First, the four tenets of SOA... What people are trying to build are loosely-coupled systems where pieces can be changed without breaking other pieces. I've built a couple of systems that meet that goal to a reasonable degree, so I don't think it's unreasonable for me to say that it's possible but hard and it takes a long time. In fact, it's just like building reusable components, which is also possible, hard and takes a lon......

3 of 74 | What's in a name? - My recent posts are my attempt to describe how I think about the Web and how it can be leveraged to integrate systems independent of the browser. I got a ton of feedback in comments and email, which was all great. I’ve been away for a bit, so I thought it would be good to come back and summarize, and to ask a question about what to call the model I’ve adopted. Specifically, some worry that the term REST means too many things to too many people to have any real meaning at all. But before I get to that, let me summarize and respond to some of the key points people made.   Most of the feedback I got can be divided into a couple of bins...   First, that it’s jus......

4 of 74 | What's in a name? - My recent posts are my attempt to describe how I think about the Web and how it can be leveraged to integrate systems independent of the browser. I got a ton of feedback in comments and email, which was all great. I’ve been away for a bit, so I thought it would be good to come back and summarize, and to ask a question about what to call the model I’ve adopted. Specifically, some worry that the term REST means too many things to too many people to have any real meaning at all. But before I get to that, let me summarize and respond to some of the key points people made.   Most of the feedback I got can be divided into a couple of bins...   First, that it’s jus......

5 of 74 | Three reasons that REST is not RPC - I've gotten several comments saying that, at the end of the day, REST is just RPC. That's wrong, for at least 3 very reasons: 1) Each unique state in your protocol state machine has its own URI. That's different from an RPC endpoint that maintains a black-boxed state machine at a single endpoint. Being able to do state transition processing at disparate locations is hugely powerful. Watch the URLs you are navigating through as you browse, shop and checkout at Amazon. A single process can span machines offering differing levels of scalability, reliability and security. RPC doesn't do that. You could conceivably build an RPC system that did do that, but if that happens it is a very rar......

6 of 74 | An example might help... - I got a lot of great comments on last nights post, including a couple about REST being no different from xml-based RPC. I used to think so too, which is why my recent epiphany was so eye opening. Consider a protocol for finding and reserving a flight between two cities. The client is in one of these states: <ready>- searched- retrieved details- reserved These states map to URIs: <none>- http://quuxTravel.com/searched- ??? depends on previous state- ??? depends on previous stateA client begins by navigating to the searched state by GETting http://quuxTravel.com/searched?src=London&dest=NYC. The client gets back some XML like this: <itineraries>  <itinerary ......

7 of 74 | On programming models... - Ittay commented on my REST post: the thing is, when you write software, you use an RPC model. what bothers me about REST is that it is not only an API. it enforces you to change your programming model. that is not to say i don't like it. i do, for its simplicity and self documentation (e.g., provide all moves as links), but there is a price you pay. When you write software, you use a programming model that works. And sometimes you have to change models. We changed them for the Web: we moved to the notion of pages. It wasn't RPC, it wasn't even objects (at least from most developers perspectives originally). But it was simple and did what it was supposed to do. I've done RPC, CORBA, DCOM,......

8 of 74 | I finally get REST. Wow. - Yeah, I'm alive. And I remember the password to my blog. I've been away for a bit, working on something very cool involving the TV. If all goes well, you'll hear about it in a big way. Anyway, I'm still having a ball out here in reality. Building something real has a way of focusing your decisions about technology. My app is a distributed system, some of which runs in a cable plant head-end or telco office (whatever's on the other end of the wire in your living room), and some of which runs elsewhere. We also connect to some things on the Web. These connections have to be extremely flexible and the bar to adoption has to be low. The thing I finally realized (some of you will say “Duh!......

9 of 74 | Are Excel Services the way to bring developers and business people together? - I heard about Excel Services a while ago, but hadn't had any time to look at them even briefly until now. Basically, it's a server-side system that lets you access data and calculations in Excel spreadsheets via Web services. Think about how much business data and calculation is done with Excel. Now imagine being able to leverage the directly. Want to change the algorithm you use to compute some key financial data? Let the analyst modify the spreadsheet and copy the update to your server and you're done. Now *this* is the way to align technology and business. Of course, that assumes it all actually works well - I haven't done anything yet. But still, it has *tons* of potential. Very cool id......

10 of 74 | Are Excel Services the way to bring developers and business people together? - I heard about Excel Services a while ago, but hadn't had any time to look at them even briefly until now. Basically, it's a server-side system that lets you access data and calculations in Excel spreadsheets via Web services. Think about how much business data and calculation is done with Excel. Now imagine being able to leverage the directly. Want to change the algorithm you use to compute some key financial data? Let the analyst modify the spreadsheet and copy the update to your server and you're done. Now *this* is the way to align technology and business. Of course, that assumes it all actually works well - I haven't done anything yet. But still, it has *tons* of potential. Very cool id......

11 of 74 | MSDN Content Web Services online... - One of the last things I did before leaving the MSDN team was to prototype a Web service for retrieving content programmatically. It's been a while since then, but a production version is now live. Craig provides an excellent introduction here. The prototype client we always talked about was msdnman - a command line tool like the Unix man command. Craig was the lucky one - he got to build it. It will be interesting to see what people do with these services. Off the top of my head, I can imagine including actual docs in a technology site, integrating with tools (a la' Reflector), and building a team level doc repository on TFS that allows you to annotate, add your own docs, etc. Anyway, cong......

12 of 74 | MSDN Content Web Services online... - One of the last things I did before leaving the MSDN team was to prototype a Web service for retrieving content programmatically. It's been a while since then, but a production version is now live. Craig provides an excellent introduction here. The prototype client we always talked about was msdnman - a command line tool like the Unix man command. Craig was the lucky one - he got to build it. It will be interesting to see what people do with these services. Off the top of my head, I can imagine including actual docs in a technology site, integrating with tools (a la' Reflector), and building a team level doc repository on TFS that allows you to annotate, add your own docs, etc. Anyway, cong......

13 of 74 | Two articles, one good and one bad... - I ran into two Web service related articles recently. One really resonated with me: Enable the Service Oriented Enterprise, in the MS Architecture Journal. It presents the Enterprise Service Orientation Maturity Model, or ESOMM. Okay, I know what you're thinking: eeeeeeeewwww, a maturity model! But it's a lot more interesting and useful than you think (and they distance themselves from that other MM in a sidebar). Lots of developers and some architects think about service orientation in terms of the famous four tenets. They are good guiding principles and very useful, but not what a lot of people mean when they talk about SOA, all caps. Sure, there's a lot of hype around SOA, but ......

14 of 74 | Two articles, one good and one bad... - I ran into two Web service related articles recently. One really resonated with me: Enable the Service Oriented Enterprise, in the MS Architecture Journal. It presents the Enterprise Service Orientation Maturity Model, or ESOMM. Okay, I know what you're thinking: eeeeeeeewwww, a maturity model! But it's a lot more interesting and useful than you think (and they distance themselves from that other MM in a sidebar). Lots of developers and some architects think about service orientation in terms of the famous four tenets. They are good guiding principles and very useful, but not what a lot of people mean when they talk about SOA, all caps. Sure, there's a lot of hype around SOA, but ......

15 of 74 | Attempting to address Rajesh's concerns about optionality... - My last post on optional content triggered a conversation between Rajesh and Jon. Rajesh's main concern is that making almost everything in your schema optional may give you flexibility, but if occurence requirements aren't captured somewhere, then its hard to consume a service (or other XML). That's true - you need to know what's required. The problem is that if you put that info in your schema, and then you need to change it and that requires changing your namespace, then you have a problem. I can see two possible solutions. One is to include occurence info in your schema but make it clear to everyone that you feel free to change it without changing your target namespace. The bi......

16 of 74 | Attempting to address Rajesh's concerns about optionality... - My last post on optional content triggered a conversation between Rajesh and Jon. Rajesh's main concern is that making almost everything in your schema optional may give you flexibility, but if occurence requirements aren't captured somewhere, then its hard to consume a service (or other XML). That's true - you need to know what's required. The problem is that if you put that info in your schema, and then you need to change it and that requires changing your namespace, then you have a problem. I can see two possible solutions. One is to include occurence info in your schema but make it clear to everyone that you feel free to change it without changing your target namespace. The bi......

17 of 74 | Initial code for version-aware schema validation - When I wrote my initial post on my new approach to XSD versioning, I promised that I'd post code. Here's the first cut: class Program{  static void OriginalMain(string[] args)  {    FileStream xml = new FileStream(args[0], FileMode.Open);    FileStream xsd = new FileStream(args[1], FileMode.Open);    XmlReader reader = null;    XmlReaderSettings settings = new XmlReaderSettings();    settings.IgnoreWhitespace = true;    settings.ValidationFlags = XmlSchemaValidationFlags.None; //ReportValidationWarnings;    settings.ValidationType = ValidationType.Schema;    set......

18 of 74 | Initial code for version-aware schema validation - When I wrote my initial post on my new approach to XSD versioning, I promised that I'd post code. Here's the first cut: class Program{  static void OriginalMain(string[] args)  {    FileStream xml = new FileStream(args[0], FileMode.Open);    FileStream xsd = new FileStream(args[1], FileMode.Open);    XmlReader reader = null;    XmlReaderSettings settings = new XmlReaderSettings();    settings.IgnoreWhitespace = true;    settings.ValidationFlags = XmlSchemaValidationFlags.None; //ReportValidationWarnings;    settings.ValidationType = ValidationType.Schema;    set......

19 of 74 | Slogging - Now matter which way you tackle contract evolution, you need to have a system in place to notify your service consumers. I envision a system based on “service blogs”, or “slogs”. A slog conveys information about the state of a service. As a consumer, I want to subscribe to a slog for each service I use. My aggregator becomes a “dependency dashboard” that tells me about upcoming service news. One thing I’d catch this way is upcoming service revisions. Optimally, the revision notification would include a pointer to a test environment and a time frame for testing. I would run my system against the new endpoint in order to test the functionality. If it ......

20 of 74 | Slogging - Now matter which way you tackle contract evolution, you need to have a system in place to notify your service consumers. I envision a system based on “service blogs”, or “slogs”. A slog conveys information about the state of a service. As a consumer, I want to subscribe to a slog for each service I use. My aggregator becomes a “dependency dashboard” that tells me about upcoming service news. One thing I’d catch this way is upcoming service revisions. Optimally, the revision notification would include a pointer to a test environment and a time frame for testing. I would run my system against the new endpoint in order to test the functionality. If it ......

21 of 74 | Okay, Craig and I are done with this topic... - Craig's last post makes me think we've have come to the same place. The way I see it, people simply can't have everything they want: A flexible system that can evolve A system that's easy to build without knowing anything about the XML layer that we're all relying on Code that is easy to write and hard to break So choose your preferred approach, but understand what tradeoffs you're making (I focus on the first point, skip the second, and try to keep the third one under control). If you proceed without understanding that, you do so at your peril....

22 of 74 | Craig remains jumpy about XmlSerializer and element order... - Craig posted a rebuttal to my earlier post. I maintain that his original advice to implement IXmlSerializable is overkill. His argument is that you're in trouble unless you “explicitly control the order of serialization of [your] web service visible types“. I agree, except that I substitute “implicit“ for “explicit“. In either .NET 1.x or 2.0, you exercise implicit control by controlling the order of the properties or fields in your type. In .NET 2.0, you can also “explicitly“ control this using the XmlElementAttribute.Order property, which is clearly a good idea. So the only thing we disagree on is whether the implicit control available in .N......

23 of 74 | Back from my break... - In case you can't tell, I took the spring off from posting. Now that I have no regular readers (by definition ;-), I figure it's time for me to start posting again. What better place to start than with my change in job. I woke up at the New Year and realized that, one way or another, I'd been involved with Web services since the earliest drafts of the SOAP spec (I remember hanging out in a hotel suite in Santa Clara trying to use a buggy stack Don was working on - he wouldn't share the code to debug, a view point he stands by still ;-). That was eight years ago. Yikes! The best part of all of that was my work at MSDN. Despite the political issues, I loved that project because we were......

24 of 74 | Craig urges overkill, XmlSerializer sky is not falling - It's almost always Craig who coaxes me back into posting after a long absence. This time, it was this post about the perils of contract first and XmlSerializer. He was talking about the possibility of building types that serializer incorrectly and violate your contract definition. He concludes (among other things) that in .NET 1.x you should implement IXmlSerializable on every return type that you build when you start from a WSDL. That's a tall order, because when you implement IXmlSerializable, you have to build not just the emitter (which solves the problem he ran into) but also the parser. This is extreme overkill. Craig got caught in a very particular set of circumstances. First, ......

25 of 74 | Solving the XSD versioning problem - The single biggest problem in the WS space today is data and service versioning. I've been thinking about this problem for years now, and I finally came to an answer that is simple, straight-forward and plays by all the rules. The inspiration came from Henry Thompson's presentation at the XSD workshop that happend last year. I also reread some pieces of the XSD spec, where he dropped some hints about this model. My current, and I hope final, solution to this problem grew from there. Most OO folks assume that an XML instance is associated with a single XSD. Most XML people do not. Rather an XML instance may be valid according to a whole range of XSDs. In the case of versioning, those XSDs a......

26 of 74 | PaulD`s new XSD data binding WG - Paul responded to yesterday`s post to explain the need for the new W3C XML Schema Patterns for Databinding Working Group, which he chairs. He points out that the move by the WS-I to deprecate encoding in favor of literal schema was based on a reasonable argument (that there is no spec for how to translate an XSD in a WSDL - which describes a tree of named structural types - into an input to SOAP encoding - which acts on a graph of unnamed structural types) but that the end result made interop harder because it opened up the door to using all of XSD. I disagree. The WSDL spec opened the door to using all of XSD for both encoded and literal bindings. The work that SOAPbuilders did provided a ......

27 of 74 | On Jon on Eric on RPC and XML - I just read Jon`s post on Eric`s appearance on a recent Sys-Con panel. Eric raised made an interesting point about the challenge in thinking about distributed systems from an XML document perspective instead of an RPC perspective. Jon agreed that RPC vs. doc/lit was an interesting issue, but I don`t think it`s the right one. You have to be careful with the term doc/literal. It`s really a WSDL detail meaning simply that the message payload is accurately described by the referenced XSD (as opposed to encoded, where that is not the case). Doc/literal is orthogonal to the issue of whether the architecture or programming model is focused on RPC, async messaging or document transfer. In the MS sp......

28 of 74 | 4 quadrants of Indigo - I just read John`s recent post about Indigo, in which he refers to my last post. His real issue with the platform is that it does too much to hide the underlying asynchronous messaging that is really the core of the system. I feel the same way, about the async messaging but more strongly about the XML inside every message. John, in contrast, wants the XML hidden, arguing that Morts like him (his assertion not mine) don`t want to see angle brackets, they should be left to Einsteins like me (again, his assertion not mine!). All of this made me realize very clearly that Indigo is striving to satisfy a broad range of requirements from a broad range of developers. I`m starting to think of those ......

29 of 74 | A transport of delight - When I saw Steve Vinoski`s recent pointer to his colleague`s article about “Where HTTP Fails SOAP“, I immediately thought of a song from the 60`s by the English satirists Flanders and Swann. It`s about the London Routemaster double-decker bus and titled “A Transport of Delight”. In the introduction on their album At the Drop of a Hat, they describe it as being about the omnibus, which they loosely translate from the Latin as meaning by, with or for, everybody. People often criticize HTTP`s use for Web services. Beyond the REST argument, which I don`t want to go into here, people worry about its ability to scale to handle the style of processing in back-end business systems. Basically, becau......

30 of 74 | On messaging and distributed system design - It`s been 2 months since I last wrote a post. I moved out of my turn-of-the-century Victorian house quite abruptly about then because we discovered that my little boy had elevated lead levels in his blood. We were on the road staying with family and friends until last week, when we closed on our new home and moved in. With all that behind us and Gus getting treatment, it`s finally time to start again. I can`t think of a better way to jump back in than to respond to this recent post from John about advice on distributed system design. He was rebutting Richard Turner`s MSDN article, which offered the official MS advice on the same topic. I figured I`d weigh in with a bunch of thoughts in no p......

31 of 74 | The siren song of Biztalk - Biztalk seems increasingly attractive to me. I believe XML is an incredibly powerful tool for building loosely-coupled dynamic systems (like MSDN2). Biztalk embraces XML messaging directly and so appears to be a very welcoming place, at least for people like me. Of course Indigo also offers XML messaging, but it is hidden behind RPC-style invocations and object marshaling layers. When I talk to members of the Indigo team about this, they`re always quick to point out that the system is layered such that I could strip away the object layer and deal with XML messages if I want to (but who would want to). Somehow, I always leave those discussions feeling like an angle-bracket loving freak. Yes,......

32 of 74 | Contracts start with documentation - I just got back from TechEd and had a chance to catch up on posts, including Dare`s recent follow up to my last post about contracts and metadata. He points out that WSDL/XSD is no substitute for good documentation and I totally agree. In fact, this was kind of a theme at the BOF on contracts that Aaron and I hosted in Orlando. A contract is an agreement expressed in a number of ways. First and foremost, there is at least a prose document - “the Word doc” - for want of a better term. Some aspects of what the Word doc says are captured in machine-consumable form (XSD, WSDL, WS-Policy, XSLT, etc), but many are not. We should never mistake those expressions of our contract for the contract its......

33 of 74 | Dare responds re: open and closed systems - Dare commented on yesterday`s post (it`s nice to see I`m back in the thick of things - thanks Dare :-). Responding to my statement: Dare was quick to blame WSDL and XSD, noting that POX/REST/AJAX systems don`t have this problem. Certainly the customers I talk to who have done POX/REST systems are moving toward WSDL and XSD because they want metadata about services in order to facilitate reuse. Without it, they don`t have a clear picture of what their systems are doing - or how to reuse them in other contexts. For a closed system, lack of descriptive metadata is fine. But if you want something open and reusable across apps, it really helps to have it he called me on my description open and c......

34 of 74 | Starting up again... - I`ve been away for a while - traveling, working on product, celebrating my little boy`s first birthday, and loosing my Outlook .pst file. But it`s time to start again and Don`s post about Steve Loughran and Edmund Smith`s Alpine work is the perfect motivation. Alpine is a new Java WS kit that doesn`t bother with JAXRPC`s standard object mapping layer. Don noticed I was mentioned in the Alpine paper`s acknowledgements and felt my fingerprints on some of the thinking, including his favorite quote: My favorite quote (that channels a certain New Hampshire native who shows up in the acknowledgements):   We believe that only two categories of web service developer exist: those who are comfortabl......

35 of 74 | DaveO on protocol abstraction - I spent 3 days last week hanging out with Ed Pinto from EDS. We had a great time jamming on a whole bunch of SO/WS topics. Ed urged me to read DaveO`s post on problems inherent in transport protocol abstraction. It`s an excellent read, reflecting Dave`s typical extremely deep analysis of a problem. The story is actually extremely confusing, not because he didn`t explain it well, but because of how complex and hideous the problem is. In essence (correct me if I get this wrong Dave) the problem is that the message exchange patterns in WSDL and SOAP do not adequately encapsulate the different behaviors exhibited by different transport protocols, especially with regard to faults, and far from r......

36 of 74 | Indigo, WS-* and the WS-I Basic Profile - The Indigo bindings that support the WS-* protocols use SOAP 1.2, not SOAP 1.1. That makes them incompatible with the WS-I Basic Profile, a standard that many companies require services to comply with. The WS-I Basic Profile was specifically designed to be not restrict either message header or body content, specifically because we knew that WS-* was going to be a big deal. So what should happen here Should Indigo support using WS-* with SOAP 1.1, or is there a reason it has to use SOAP 1.2 If the latter, should the WS-I BP be updated to support SOAP 1.2 or should companies move away from the BP If the latter, does that open the door for the return of SOAP encoding What`s the right thing to ......

37 of 74 | Dare argues that code-first is better for interop - Here we go again... I just read Dare`s new post claiming that code-first WS contract development is better for interoperability. His argument is that not all tools support all of XSD, so if you design Web services contracts directly using XSD/WSDL, your chance of interoperability is actually lower than if you do code-first and let your tools map your classes to XSD/WSDL. Here`s my favorite part: Every XML Web Service toolkit that consumes WSDL/XSD and generates objects has different parts of the XSD spec that they either fail to handle or handle inadequately. Many of the folks encouraging contract first development are refusing to acknowledge that if developers build schemas by hand for use......

38 of 74 | Dare argues that code-first is better for interop - Here we go again... I just read Dare`s new post claiming that code-first WS contract development is better for interoperability. His argument is that not all tools support all of XSD, so if you design Web services contracts directly using XSD/WSDL, your chance of interoperability is actually lower than if you do code-first and let your tools map your classes to XSD/WSDL. Here`s my favorite part: Every XML Web Service toolkit that consumes WSDL/XSD and generates objects has different parts of the XSD spec that they either fail to handle or handle inadequately. Many of the folks encouraging contract first development are refusing to acknowledge that if developers build schemas by hand for use......

39 of 74 | Neward on XSLTO and aspects - Imagine my shock when I read Ted`s post explaining that my recent XLSTO work meant I was embracing aspect-oriented programming, something I walked away from after spending years with COM+. He argues that: But the brutal truth is, what he`s done--the execution of code in response to what amounts to a pointcut (through an XML document instead of through a programming model)--is quintessentially an AOP concept. I`m not up on my aspect terminology, so I don`t know if it`s me unknowingly adopting aspects or Ted knowingly adapting aspects to make them more useful. In any case, I built XSLTO because I had an XML language for scripting SQL server. I was taking XML input documents, transforming them......

40 of 74 | Sagas vs. protocols - The basic WS protocols sprang out of a real concrete need for a simpler way to make two applications talk across the network. The lessons learned from DCOM, RMI, and CORBA have been learned and now, functionality wise, it provides what I had with sockets, similar to RPC but (preferrably) with a very different programming model). This is a great tool for integration. Now I wonder about the WS-ReliableMessaging (+ queuing) and WS-AtomicTransaction protocols. They are designed to detect and recover from the problems you encounter in any distributed system. The goal is to hide a whole bunch of possible weird failure modes from the application programmer. This has been attempted before, most rec......

41 of 74 | Contract First BOF at TechEd - Aaron posted about the Contract First BOF session we proposed for TechEd in Orlando. If you`re interested in talking about practical guidance for this style of WS development, vote for this session here....

42 of 74 | Risks to the success of Web services - I spent last week at DevWeek in the UK. This is probably my favorite conference. It`s small and independent, gets great attendees, and is just generally a great time. I got to see and talk to lots of friends. Web services were a theme throughout the week (what a surprise ;-). Jon already posted about our dinner at Veeraswamy with Simon Horrell and Dominik Baier. Before we got to the important stuff, we dealt with Simon`s assertion that Web services had failed. What he really meant was that a lot of the big visions people have for orchestration, all kinds of advanced protocols, etc. seem less likely to him. For the most part, I agree; but I don`t think that means that WS have failed, just th......

43 of 74 | XSLT objects ported to Java - Chris posted the XSLT Object model stuff I did at MSDN. I see from a comment on his blog that it`s been ported to Java. This is one of a couple of ideas I have for simpler XML programming models. I hope to share more on this in the relatively near future. :-)...

44 of 74 | Clemens responds, and I think maybe we actually agree - Clemens posted a response to my original post about his position on Indigo contracts. In it, he says: WSDL and XSD and Policy are interoperable metadata exchange formats. That’s just about it. I agree. It`s the information you exchange in these files and in documentation that forms the contract. He also says: But WSDL/XSD/Policy isn’t the contract. If you do ASMX, you can create server and client without you or any of the tools ever looking at or generating WSDL. And it works. The fact that it just works doesn`t mean that WSDL/XSD/Policy is not the contract. It means that you don`t care to see the contract and deal with it directly. The part that Clemens and I agree on is this: I do care ab......

45 of 74 | Gurus in the street - I just read Clemens` post responding to Aaron`s piece on what WS developers need to know about contracts. I agree with Clemens that most developers “on the street“ do not know XSD and WSDL very well. But I also agree with Aaron that they need to be aware of and think about their contracts. That doesn`t mean that they need to type angle-brackets in notepad. But it does mean that they can`t treat contracts as something that just happen as a side effect of creating a service implementation. The problems with that approach are well known....

46 of 74 | The many faces of Indigo - Sometimes getting away from the keyboard can really help you get your thoughts in order. I just got back from NYC, where I spent a long weekend with my family. I left the laptop at home (my 9 month old seems to occupy all my vacation time ;-), but I still had time to think about Indigo and how it will fit into and change the Web services world. Just before I left, I read David`s Indigo intro piece on the MSDN Longhorn site. It lays out the basics and, among other things, talks about the different types of channels that an endpoint can use, including: BasicProfileHttpBinding BasicProfileHttpsBinding WsHttpBinding WsDualHttpBinding NetTcpBinding NetNamedPipeBinding NetMsmqBinding My first re......

47 of 74 | Dare comments on service reach - Dare just posted this comment to my post on the business value of services being reach: It seems your assumption is that everyone building distributed applications is placing them on the public Internet with the goal that every Perl kiddie and Javascript junkie should be able to call it. This is simply not true. I work on designing web services that impact hundreds of millions of people and the least of my concerns is reach. I am not assuming that everyone is building services that will be exposed on the Internet. I am assuming that in many companies there is not only one toolkit to use. Dare`s employer, Microsoft, is probably one of the only companies where that is not true. :-) Or is it ......

48 of 74 | Indigo is going to rock! - In the last couple of days, I`ve been posting a lot about the need to be deliberate in designing service contracts. I believe in that very strongly, and I don`t think it will change if you are adopting Indigo in order to build interoperable Web services. If you are adopting Indigo for some other reason, like Windows-only cross-machine process communication using named pipes, for instance, feel free to ignore my view which really doesn`t apply. It`s clear from everything coming out of Indigo day at VSLive and the latest paper at MSDN, that Indigo is going to rock! I`m sure that will make it even harder for me to win this argument. :-) That said, you can count on me to focus on contract first......

49 of 74 | MEST is already omni-present, if you look for it - Dilip pointed me to recent posts from Savas and Jim about “message transfer”, or MEST. It`s an interesting idea and I told him I`d post my thoughts (sorry for the delay Dilip :-). As far as I can tell, the basic idea behind MEST is that web services developers should be thinking about message passing instead of RPC calls. I completely agree. But I disagree with the idea that that means there should be one WSDL interface with one operation “ProcessMessage”. There`s no need to go there, because we`re there already. WSDL 1.1 has four generic message exchange patterns (MEPs), only two of which have meaning over HTTP: request/response and oneway. Request/response means “process this message and ......

50 of 74 | Savas tells me I misunderstood MEST - Savas commented on my MEST post and pointed out that I`d missed something because neither he nor Jim was arguing that WSDL portTypes contain a single ProcessMessage operation. Okay, I admit, I missed something. He further explained that the point of MEST - I`ll try to get it right this time - is to focus developers on message processing as the abstract operation all web services support and then on building more complex message patterns. I still think that`s already in place. We have the generic request/response and oneway patterns (ignoring the non-HTTP ones). When we write an interface we bind those to concrete messages. Each WSDL portType describes a node in a possibly more complex messa......