Tuesday, November 05, 2002

From the Rotor List: On behalf of the entire Rotor team, I am pleased to announce the 1.0 release of Rotor. This release is available at the usual place http://msdn.microsoft.com/net/sscli. The 1.0 release builds and runs on Windows XP, the FreeBSD operating system, and Mac OS X 10.2. In addition, the release contains many bug fixes, more documentation, new samples and additional test suites. Please download it and let us know what you think. Geoff Shilling Rotor Project 7:38:12 PM

Just entered chat below and right off start getting messages from all sorts of bloggers-) Ethan Brown, Greg, Matt Griffith, Ingo, Simon, Alexis, Jim Don's talking about the overall architecture right now and putting in place all the pieces that other middleware stacks have had, and going for adoption...SOAP Preliminaries: SOAP message format described by envelope is pretty straightforward...In general, SOAP fairly silent about what goes on in body, some to say about header...exists so 3rd parties can augment. SOAP has always had this extensibility mechanism. AS SOAP has evolved more rigor has been applied to headers and thats what we rely heavily on in GXA specs... Two roles Ultimate Reciever and Next (predefined). Drill into WS_ROUTING - gives transport independent way of sending SOAP. HTTP wonderful, until end of time but lot of people want to send over other transports. Tried to abstract away transport details. Yikes! So many messages from bloggers, can't keep track of talk...WS_ROUTING - Action, Id, relatesTo, To, Source Routing in form of Foward and Reverse Paths...We need Intermediaries for things likes firewalls, proxies, may want to smear message over several locations. Another aspect is hard to build IP Router...Idea rebuilding IP Routing in User Mode...Application aware routing...All of specs are layered on SOAP 1.1 and 1.2 not replacement for. Though probably end of line for SOAP in 1.2, if we don't hold constant, pretty hard to get Interop. Move on to WS-Coordination, Released as same time as WS-Tx, so didn't get a lot of attention - bizare to me. The real interesting innovation, unknown stuff in WS-Coordination. 3 people of 75 have read it. WS-c igives us lot of functionality that people expected when moved from classic RPC. Look at Corba, COM. Tended to want to build things that lasted more than one msg - COM+ - Contexts. Want to establish temporal, spatial relationship. Take bunch of messages and make sure the context has an id. Spec is org in most peculair way - two most interesting things in 2 appendicies. Context = collection of messages over time that share at least one property - identifier. May share others. When 2 or more WS are doing work together they may want to establish shared context. Basic Header Type - Context Header Block - Contains at least ID and maybe more info. Header blocks have distinct URIs.  WS-C pre-defines a Cordination Context. 2nd thing in Appendix - PortRef - contains bare minimum of address. <CoordinationContext>     <Identifier>uri</Identifier>      <CoordinationType>uri</CordinationType>       <RegistrationService>             <Address>http://foo.com/mycoordinator.jsp<;/Address> <PortReference>     <Address>http://www.microsoft.com/foo.asmx<;/Address> </PortReference> WS-Tx really two specs - Part 1 2 Phase Commit and ACID. Part 2 Business Activities. ACID Txs - no one who worked on spec expected it to be used across trust boundaries. Part 1 exists to allow existing Tx apps to be able to do 2PC in a web context. Never intended to go across web sites and firewalls - across org boundaries. Tried to make that clear in the spec. Don't read Part 1 unless building Tx plumbing - codification of work done last 10-20 years in Tx. Part 2 really long-running transactions. Not strong isolation...No expectation of isolation or stability...BA is much simpler to understand - combine with WS-C an app dev could grok...So don''t wory about ACID, BA more interesting... Reliable Messaging in next couple of months...Lots of plans... Wow, I have to clean this up and get it in a story tonight... 3:33:20 PM

Project Mono Does SQL / Windows / ASP.NET. Project Mono can now execute SQL statements on MS SQL Server through TDS and has a bit of Windows.Forms code running on both Linux and Windows as well as a good deal of ASP.NET support. Looks like things are coming along at a decent rate. [sellsbrothers.com: Windows Developer News] COOL!!!! 2:21:55 PM