Monday, June 02, 2003

INETA Booth (Tomorrow) Come by the INETA booth tomorrow from 12 PM to 1 PM. Chris Goldfarb (Intel) and I will be there to answer your questions! :-) 6:02:35 PM    comment []

WEB 400: Loose Coupling and Serialization Patterns: The Holy Grail of Service Design WEB 400: Loose Coupling and Serialization Patterns: The Holy Grail of Service Design Doug Purdy, Microsoft - XML Web Services Abstract Loose-coupling is an ultimate benefit of Service Oriented Architecture.  See how to build and design loose coupling into your web services.  Drill into the impacts of serialization technologies in the .NET Framework, effects of schema design in relation to object model design, parsing performance and versioning. Notes Macro vs. Micro loose coupling. Smart contract & schema design in the solution. A tale of two development approaches; code first (i.e. CLR) vs. schema first (i.e. XSD). "To achieve loose coupling you must understand XSD - code or schema first." (Good point.) Use the SoapDocumentMethod for code-first development. Useful settings: ParameterStyle=SoapParameterStyle.Bare and Use=SoapBindingUse.Literal. And, examine the induced contract often. (Another good point.) Best practice for schema first development: Develop schema & contract separately. Use WSDL import to associate them. (Yet another good point.) Utilize wsdl.exe /server to create stub. (IMO, the unsung hero of the .NET Framework.) xsd:any: completely open String <--> xsd:string (AKA, "XML as string") Microsoft parlance now defines UDTs; what is (de)serialized across the wire. Optional data via XmlIgnoreAttribute helps the programmatic model. Union support via XmlChoiceIdentifierAttribute for a choice. (Very good tip!) Doug showed an example of serialization using an octet stream of a HashTable. (Not recommended.) This example simply demonstrates how open your programming model can be. Some of the points made by Doug will sound true with the INETA Web Services (which we hope to ship sometime soon). Resiliency is maintained by "changing without breaking"; clients work with recompile and data is not lost on a round-trip. Important note: Resiliency requires forethought. Namespacing versioning is not versioning - an interesting point. I never thought about this. I always assumed that namespace versioning was sufficient. Interesting... Doug showed additional code examples showing how to define loosely-coupled ASMX-based services. Most utilize XmlElement types in the parameter lists. Loosely-coupled XSD schemas utilize xsd:any for element and attribute array. (This style of schema model is evidenced by the WS-Security specification, which is highly extensible.) Yet another very good talk. Certainly, there are a lot of things to think about when designing loosely-coupled Web service-based systems. 5:06:14 PM    comment []

Drew @ TechEd Drew is also blogging TechEd '03: http://drewby.net/. 4:05:10 PM    comment []

OT: Damien Watkins I ran into Damien Watkins at the INETA booth earlier today. (Way cool!) The man from Project 42! Damien was kind enough to give a talk at one of MDNUG's first meetings (back-in-the-day). 4:01:13 PM    comment []

WEB 302: An End-to-End Web Services Application: Architecture, Clients, Security, and Analysis WEB 302: An End-to-End Web Services Application: Architecture, Clients, Security, and Analysis Eric Schmidt and Ray Stephenson (Platform Strategy & Partner Group, Microsoft) Abstract Where do Web Services live and why?  Should I adopt Web Services just on the client?  This session is dedicated to drilling into the usage scenarios of Web Services.  Walk through a logical end-to-end application (smart-clients, devices, portals, application servers and integration servers) examining the impact and architectural considerations for each service.  See products and technologies mapped to usage scenarios in order to answer questions like What really makes a smart client, How do I handle identity and security and How do I push value back to the business.  If you are interested in traditional B2B, A2A, B2C, P2P concepts this session is for you.  This talk is a concentrated primer focusing architecture, building the right client, understanding security implications and driving business processes in the context of Web Services. Notes Goals of the talk include: "Enable you to implement realistic Web service-based applications" and "Enable you to think holistically about the application of Web services". First question asked: "Where does your business make money?" Eric asks some important questions regarding Web services from a developer's prespective DEMO: Your standard PO type of application. It features WSE v2.0 with TCP listener. (Neat.) It also uses InfoPath as a client. Side note: It seems as though TechEd is buzzing about WSE v2.0. Appartently, it rocks. BizTalk 2004 has a schema tool that compiles XSD schemas into .NET assemblies. (Hmm. Isn't this xsd.exe?) Tip: Use XmlNode for I/O parameters for WebMethods to be completely loosely-coupled. WSE v2.0 UsernameToken appears unchanged from an API perspective. SoapContext still a fundamental construct for WebMethods. Demo integrates with Authorization Manager (AZMAN). (Cool.) Side note: AZMAN looks super cool. WSE v2.0: Supports listening on a TCP channel (TCPListener). WSE v2.0: New type; Microsoft.Web.Services.Messaging.SoapService (a factored base type). WSE v2.0: New type; SoapReceivers. (A collection of "receiving" types.) WSE v2.0: Much more support for services outside of IIS. Demo featuring some nice Excel features. 8 Artifacts to Burn Into Your Head When Modeling: Business Processes, Services, Schemas, Policies, Rules, Users, Roles, Views. Recommended book: Application Architecture for .NET: Designing Applications and Services Service-oriented architectures (SOAs) must promote interoperability and federation. SOA: A development and management architecture for loosely-coupled applications. "SOA is goodness." Veneers are an effective way of shielding legacy systems. Intermediaries provide virtualization of the ultimate [receiver]. Overall, a very good talk. A lot of things worth revisiting again. 3:12:46 PM    comment []

WEB 300: The 'Don' of Web Services Abstract Web Services architecture has made tremendous strides over the past year. A myriad of new specifications have been released including WS-Security, WS-ReliableMessasing, WS-Transactions and WS-Policy. New programming models like the Web Services Enhancements for Microsoft .NET were born. BizTalk Server has evolved to become a native Web Service message bus. The client has gotten smarter with XML Schema driven documents via InfoPath. Go beyond the marketing hype hear what really happened and where Microsoft is headed. Don Box educates you on why XML Infoset usage will bring about world peace, why WS-Policy is so important, what composeable really means and what the future looks like for Web Services. Note: Don will be fully clothed for this session. Notes Bill Evjen and Marcie Robillard - "DataGrid Girl" - have joined the fray. Don is providing a "stabilization talk"; talking about past, present, and future WS goo. Axiom #1: The XML data model is here, get used to it. Axiom #1 Corollary 1: Simple, three-layer stack: XML 1.0 -> Infoset -> Typed Infoset Side note: Don is using graph paper with an overhead projector for diagrams. He's calls it his own tablet PC. Too funny. Don is providing a perverbial stack walk for XML; XML v1.0, the Infoset, typed Infoset. Don provides a simple type to explain the type mapping from XML to the CLR typing system. Showing how attributes control the serialization process. Don is showing InfoPath. Using xsd.exe to extract a schema definition. He's importing the type definition into InfoPath. Showing how to create a basic form in InfoPath, based on the imported schema. Now, he's pushing data into a little console application he's written. Bottom line: "XML is here, get used to it." Axiom #1 Corollary #2: XML Schema is infinitely complex, but obvious subset is emerging. Nice quote: "XML Schema makes COM look like VB." Axiom #1 Corollary #3: Tools and plumbing abound. Axiom #2: URIs are queries, learn to love them. Axiom #2 Corollary #1: Simple three-layer hierarchy: Identifier -> Address -> Query "Be aware of URIs" because they're important. Don's writing another simple ASP.NET page (simple.aspx) to show another mapping. He's generating a Word document in XML. SQLXML re-enforces the notion that a URI is just a query. He's demonstrating some queries via a URI against a back-end SQL Server data store. Axiom #2 Corollary #2: Core (lone?) tenet of web architecture. Axiom #2 Corollary #3: Ideal for read-only applications. Don's now showing some features in MS Word 2003, using the field capability to query a URL as its properties. "I embed queries in Word as URIs." Axiom #3: SOAP is for Services We need SOAP because the world isn't read-only. Axiom #3 Corollary #1: Ideal for read/write applications. Axiom #3 Corollary #2: Model-neutral protocol: S/F, RPC, MOM, HTTP-POST. The object mapping made the SOAP v1.1 specification complex. Now, we're moving away from this. Unfortunately, most of the tools are targeting a RPC-esc. Axiom #3 Corollary #3: Most baked (and understood) of "the big three". Axiom #4: The Message is the Medium. The message is a pretty powerful thing. If you program (abstractly) in terms of the message, it makes it a lot easier a variety of difficult architectures (i.e. processing pipeline). Most of the time we spend massaging the XML (transform). Axiom #4 Corollary #1: SOAP designed for future expansion. Side note: There are approximately 200 developers on the Web services team. Wow. SOAP was kept super simple. "We didn't want to impose anything." "SOAP consists of two bags; a header bag and a body bag." ;-) Don is talking about the role of SOAP intermediaries. He is also talking about how particular elements can be targeted towards particular roles. Axiom #4 Corollary #2: Data model designed for composability. Axiom #4 Corollary #3: Processing model designed for distributed processing. Axiom #4 Corollary #4: Industry trend back towards MOM (messaging-oriented middleware). Axiom #5: WS-* is for Plumbers "Unless you're a plumber, you can largely ignore [WS-* specifications]." Axiom #5 Corollary #1: WS-Addressing frees us from HTTP. Axiom #5 Corollary #2: WS-Policy frees us from telephones, e-mail, and code. The easiest was to think about WS-Policy is that it's a pseudo CLR attribute for Web services. Axiom #5 Corollary #3: WS-Security et al. secures us independent from transport. Axiom #5 Corollary #4: WS-ReliableMessaging gives us lightweight, long-running monologues, and dialogues. Axiom #5 Corollary #5: WS-Transaction enables a single enterprise's CICS/Tuxedo/DTC apps to play together. Axiom #6: WSE is for Enthusiasts Axiom #6 Corollary #1: The "Conversational" platform. Axiom #6 Corollary #2: Vehicle for us to support "churnful" WS-* specs. Axiom #6 Corollary #3: Vehicle for you to see where we're headed with .NET. Axiom #6 Corollary #4: Real, supported technology. Side note: WSE v2.0 sounds incredible. Don mentioned it briefly. Axiom #7: The XML Wave hasn't even begun. "We're at the beginning of another change." "I strongly believe we're at the front of another wave." Exciting stuff. 1:34:05 PM    comment []