|
>
 Monday, May 31, 2004
 Friday, May 28, 2004
 |
|
 |
|
|
|
|
|
Thanks to everyone for getting up so early (two days in a row, some of you!) to attend this session! The resources for this talk are here:
The latest code is up there now!
|
|
|
 |
|
 |
 Wednesday, May 26, 2004
 |
|
 |
|
|
|
|
|
Thanks to everyone for getting up so early to attend this session! Wow, what a turn out! The resources for this talk are here:
The latest code is already uploaded to the site, and more samples are bound to be there soon...
|
|
|
 |
|
 |
 Tuesday, May 25, 2004
 |
|
 |
|
|
|
|
|
This talk started out with a bang as Don and Doug collected a list of questions from the audience that they planned to answer throughout. The best part about this was that the questions were really great. For example: When should you use .NET Remoting vs. Enterprise Services? What will happen to COM+? When does COM matter? Should we use ASMX?.
After this, they proceeded to go through exactly 3 slides. Cool bullets…
- There is only one program and it is still being written.
- Choice is an illusion.
- Objective interpretation is an oxymoron.
The question is, what do the bullets really mean? Clearly, Don and Doug are great philosophers who enjoy abstracting the meaning of technology, where have we been, where are we going, how do we get there…all that. So, I’ll give you my interpretation (which we know from the bulleted list will not be shared by everyone).
First of all, the meaning of SOA (something the masses struggle with big time) is that we need to design systems (or, services) as well encapsulated, autonomous chunks of functionality that can be consumed by other systems, across departmental, enterprise, and possibly industry boundaries. This is one big program (the matrix anyone?)…metaphorically speaking…although of course not literally. If we design systems with the expectation that we cannot control where and who consumes them, we will fit within the SOA model. Contracts for these services, once published, must remain constant…because we have no idea who is consuming them, nor when.
In a related topic of discussion regarding the definition of service interfaces, we must consider that there can be many interpretations of a service schema. For example, if an industry like ACORD (for insurance) defines what XML looks like for a certificate of insurance, does that mean all systems following that standard will interpret EVERY element of the schema in the same way? Or, might there be different (valid) renditions of this schema? For example, could an xsd:int value be delivered as an xsd:string instead and still be meaningful? Sure it can. Could a subset of the schema be used by the destination endpoint? Absolutely. Thus, by definition we need extensibility and we need to be prepared for variant interpretations. In addition, the object model behind a service will rarely look exactly like xsd-generated classes. Services must be able to interpret XML payloads in their own way, and process them according to the needs of the system. What all of these competing Web service vendor platforms can agree on is the goals of SOA and the protocols (WS*) that are required to interoperate. Proof of this of course is in my recent experience with the Web Services Interoperability Education Day. This is exciting stuff, to see emerging standards work across platforms…we will continue on our quest there.
I enjoyed the philosophy shared during the talk, but must admit that the questions asked at the beginning were so compelling that I was really looking forward to their answer. I almost think they could have done two complete presentations. One for the philosophy, another for the Q&A. So, although there wasn’t a lot of time for answers at the end, here’s a summary of what I captured:
- COM will not disappear, it will be part of hybrid solutions, and transparent to the service interface.
- Remoting is useful for crossing app domains, but not for crossing machine boundaries. Use it for fault tolerance within a process (one app domain goes down, the main process stays alive).
- Crossing machines and processes, DCOM is fastest binary protocol, and can be secured, which means EnterpriseServices (ES). This also facilitates DTC transactions. Oh, and MSMQ is integrated here so you can also guarantee message delivery.
- On ASMX serialization vs. binary serialization with remoting, ASMX will be faster than .NET remoting, short term performance gains using remoting today will not position your applications for future releases (I.e., Indigo). You can expect better performance with ASMX in future as programming models change, and frankly what impacts performance most is usually bad architecture, including hardware choices and physical tier distribution. One thing that will also support performance improvement at a more granular level is also XML parsers…something the team is working on.
- How many WS* protocols do we need? Less. SOAP/XML is a great start. WS-Security is critical for end to end message integrity. We need standard protocols for interoperability, thus we need tools to assist with serialization, such as WSE 2.0.
- WSE 2.0 gives us a chance to work with WS* protocols now, while waiting for Indigo. The important thing is to realize it is taking you in the right direction. It keeps you in the game. These standards move fast, so does the WSE team. Indigo will just swallow it all making it even easier once standards are more stable.
- MTOM is the future of DIME.
- SAML will be supported, because WSE is extensible. Actually, Benjamin Mitchell and I worked on a SAML sample for our interoperability demonstration with Axis/SourceID…so we kinda already have a start on that!
- Your ES investment with COM+, MSMQ will be supported by the world of Indigo. Of course!
|
|
|
 |
|
 |
 |
|
 |
|
|
|
|
|
Get it here
Rebecca Dias hung out with keynote Steve Ballmer and announced the release of WSE 2.0, the successor to 1.0 component libraries with support for OASIS WS-Security protocols in addition to several features of WS-Policy (specifically WS-SecurityPolicy) and WS-Trust/WS-SecureConversation. This is truly an attribute to .NET’s extensibility model that the WSE team can build support for emerging standards (as they emerge) through use of HTTP handlers and SOAP extensions. The WSE team has one of the fastest release cycles at Microsoft, and I expect they will continue to plung forward to support more of the WS* standards so that we can have tools at our fingertips to interact with these protocols with a lot less pain (or, WS-Pain as I call it).
NOTE: If you’re at Tech Ed, come see my talk on HTTP handlers, modules and SOAP extensions. DEV410: Inside the ASP.NET Runtime: Intercepting HTTP Requests, Wednesday 8:30am in Room 8.
This release gives developers a simple way to use Web services security protocols that enable:
- Passing security tokens
- Authenticating callers
- Ensuring message integrity
- Ensuring message confidentiality
This tool has the best support out there today for generating WS-Security and WS-Policy XML, and help you see the value of the actual standard.
Becky, can I have a WSE T-shirt now?
|
|
|
 |
|
 |
 Monday, May 24, 2004
 |
|
 |
|
|
|
|
|
After a long week trouble-shooting last minute issues between .NET, WSE 2.0, BEA Workshop 8.1, Apache Axis and SourceID...we pulled off our Web services event without a hitch! What does that mean? Well...for one, all the demos worked. This is significant because although we each had our own test plans hitting remote and local endpoints...the first we were able to get together and test on the actual machines for the demo was Friday when each speaker arrived to San Diego. Here's how Friday played out:
- Heinrich arrives at San Diego airport at 1pm, we head to my technology palace to hook our machines up to the NAT router and have his BEA code hit the token issuer on my machine (which would be Ben's machine later that night), and the Axis web service on Chris' remote server.
- Anant meets Heinrich and myself at UCSD to test the configuration at the event venue, and we switch to Anant running the Axis service. This didn't quite work (configuration was fragile, too many settings to modify each time we moved service endpoints) so I left them (and my machine) to figure it out while I was off to pick Ben up at the airport
- Ben's plane is late, I call Anant and Heinrich, they come to the airport so we can trouble-shoot the configuration issues while we wait. We can't afford to lose time...it's already 7pm
- Ben arrives and immediately spots us. We were sitting at the airport, connected machines via router, people staring (what the?)...as they walked by. It's 8:30pm
- We head back to my place, call for pizza on the way, Adam Cogan waiting on us (he wanted to see our demo...give us feedback). We work on configuration with Ben's machine, then proceed to run through the demos and discussions. By 2am we were ready...a few hours of sleep later and we were setting up at UCSD!
Ted Neward gave an incredible keynote, not only educating us on interesting historical facts while explaining that we are destined to repeat the same mistakes over and over again if we don't approach SOA, Web services and enterprise component architectures incorporating lessons learned from the failure of past architectures such as CORBA and DCOM. He is a phenomenal speaker, and great philosopher, and what I really like about Ted is that he backs up every statement he makes with cold hard facts and reasoning.
We ended up spending some time describing Web services, and what the purpose of WS-Security and WS-Policy were, before we got to demos...however the audience truly seemed to appreciate the overview, as much as they enjoyed the demonstrations to follow. I'll get some links up soon that make reference to resources. In the meantime, some detailed discussions of the event went are already up on John and Benjamin's respective blogs. Benjamin writes about the panel discussion that followed the code demonstrations. He also summarized Ted's keynote.
I plan to summarize some of the interesting things I noticed while trouble-shooting the code as our human interoperability tester...stay tuned...
|
|
|
 |
|
 |
 Thursday, May 20, 2004
 Sunday, May 16, 2004
 |
|
 |
|
|
|
|
|
Well, I couldn't be more thrilled today...after rebuilding my machine on Friday (sun shining outside, 80 degrees) and following Chris Haddad's flawless instructions to set up my machine with the latest JDK, Ant, Tomcat, and Axis yesterday (sun shining outside, 80 degrees)...we were ready to start testing Ben's .NET SAML implementation. Setup was time consuming, yet surprisingly painless... a far cry from the hell I went through several years ago when Axis was in its infancy ...back then it took me 3 days to get HelloDuke() to run properly...mind you that could have been related to my J2EE container, ATG Dynamo.
Yesterday Anant and I both set up our machines to run Axis demos and between phone calls and IM Chris and I tested his remote Axis endpoint with Ben's SAML token issuer. We discovered a few things related to how Axis handles SOAP messages, for example you have to manually indicate understanding for *mustUnderstand* headers like wsse:Security (a good one to understand wouldn't you say?).
Today we continue (sun shining...80 degrees...sigh)...
|
|
|
 |
|
 |
 |
|
 |
|
|
|
|
|
As I mentioned earlier a bunch of us are pulling together some *wicked* demos (that's Canadian for *awesome*) for first ever Web Services Interoperability Education Day.
We crafted a plan for the tiered demonstration in late February and everyone broke off into their respective coding frenzy. Benjamin Mitchell took on extending .NET WSE 2.0 to create a SAML token issuer. Heinrich Gantenbein is extending the existing interop example he already created between .NET WSE and BEA Workshop 8.1/WebLogic Server. And Chris Haddad stepped up big time to build us an Apache Axis/Source ID Web service to receive SAML token signed messages and verify with the token issuer. (We switched to open source since we discovered it was VERY difficult to get our hands on a trial version of Tivoli to support our IBM WebSphere example...and the clock was ticking...).
Throughout all of this, John Bristowe and myself have been waving pom poms (John's term) and supporting the group either by testing code, discussing issues, and general coordination. In addition, Anant Kadiyala (run's the local BEA user group in San Diego, and teaches Web Services at UCSD Extension with me) stepped up to support the open source side, working with me configuring machines for the demos, and we'll be trouble-shooting the entire system here in San Diego before our esteemed speakers arrive.
Now, I have to admit that it was really very difficult for me NOT to *own* a specific part of the code for this event...given that I work with WSE 2.0, have a past with Axis and also know enough BEA to be dangerous :)... and I'm sure John and Anant may have similar feelings despite bandwidth issues we all have...however, this couldn't be a better display of teamwork in action. As issues come up, there is a support team to research issues, test code and find solutions...fast. We're running into x.509 certificate serialization issues, Web service specification implementation issues, and other configuration bottlenecks. Not to mention that coordinating all of this with the actual presentation is just a ton of work since we will be networked through a NAT router and hitting each others machines...good things...so, in short, this is a really great experience.
It is a honor to work with all of these guys...really.
|
|
|
 |
|
 |
 Saturday, May 08, 2004
|
|
ON THIS PAGE
|
|
|
|
SEARCH
|
|
|
|
CATEGORIES
|
|
|
|
ARCHIVES
|
| | Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|
| 25 | 26 | 27 | 28 | 29 | 30 | 1 | | 2 | 3 | 4 | 5 | 6 | 7 | 8 | | 9 | 10 | 11 | 12 | 13 | 14 | 15 | | 16 | 17 | 18 | 19 | 20 | 21 | 22 | | 23 | 24 | 25 | 26 | 27 | 28 | 29 | | 30 | 31 | 1 | 2 | 3 | 4 | 5 |
|
|
BLOGROLL
|
|
|
|
|
 |
|