February 2005 - Posts
Haben Sie am 7.4. schon was vor? Nein?
Na, dann ab nach München an den Flughafen. Dort werden Dariusz Parys von Microsoft Deutschland und ich einen ganzen Tag lang Indigo zeigen - und erzählen, was wie und warum funktioniert. Vor allem möchte ich Ihre Aufmerksamkeit auf das "Zeigen" legen... denn gesprochen und zugehört haben wir nun schon lange genug.
Also, nicht zögern, wenn Sie Web Services, Remoting, Sockets, MSMQ, COM+, Enterprise Services oder ähnliche Kommunikationstechnologien und Laufzeitumgebungen bereits einsetzen oder sich fragen, wie Sie künftig handeln, entwerfen und entwickeln sollen.
Verleihen wir gemeinsam dem Schlagwort "Service-orientierte Programmierung" ein Gesicht: Indigo.
Ich freue mich.
This is good news - maybe a more important announcement for all the interop-afarians out there than the advent of Indigo.
Axis 2.0 - Tech Preview / Milestone
Axis2 is an effort to re-design and totally re-implement both Axis/Java and (eventually) Axis/C++ on a new architecture. Evolving from the now standard "handler chain" model which Axis1 pioneered, Axis2 is developing a more flexible pipeline architecture which can yet be managed and packaged in a more organized manner. This new design acknowledges the maturing of the Web services space in terms of new protocols such as WS-ReliableMessaging, WS-Security and WS-Addressing that are built on top of the base SOAP system.
At the time Axis1 was designed, while it was fully expected that other protocols such as WS-ReliableMessaging would be built on top of it, there was no proper extension architecture defined to enable clean composition of such layers. Thus, one of the key motivations for Axis2 is to provide a clean and simple environment for extensions like Apache Sandesha and Apache WSS4J to layer on top of the base SOAP system.
Another driving force for Axis2 is to move away from RPC oriented Web services towards more document-oriented, message style asynchronous service interactions. The Axis2 project is centered on a new representation for SOAP messages called AXIOM (AXIs Object Model). AXIOM consists of two parts: a complete XML Infoset representation and a SOAP Infoset representation on top of that. The XML Infoset representation provides a JDOM-like simple API but is built on a deferred model via a StAX-based (Streaming API for XML) pull parsing API. A key feature of AXIOM is that it allows one to stop building the XML tree and just access the pull stream directly; thus enabling both maximum flexibility and maximum performance. This approach allows us to support multiple levels of abstraction for consuming and offering Web services: using plain AXIOM, using generated code and statically data-bound data types and so on.
We are just finishing 0.5 of WSCF and try to figure out the feature set for 0.6 already.
One thing we want to add is a visualization component for WSDL interface descriptions - because a picture tells more than a thousand words. And everybody should be able to grok the e.g. Google WSDL more easily when looking at an (interactive) graphical representation instead of staring at angle brackets.
Here is our question:
which kind of diagram do you think would be most appropriate to visualize a WSDL inside Visual Studio .NET (i.e. the essence of WSDL, not every single detail of WSDL - but this should be an obvious fact)?
You can leave your comments here or contact us directly - and maybe send in some hand drawings ;)
So, the first stormy Indigo days are gone... Just want make my point clear: Indigo rocks, I love Indigo.
Anyway, with the current development of this 'contract' discussion, I thought I might leave the Hello World samples (like "Basic Hello World', 'Queued Hello World' over MSMQ, and 'Hello World v.Duplex') to my Indigo friends.
What I want to deal with here today is how a developer who believes in the very one approach to service and Web service design, can also use and embrace it with Indigo - or at least thoroughly understand any implications.
Until now, I have never written much about code generation from XSD and WSDL for the ASMX (or WSE) stacks. Maybe this would make a nice in-depth hardcore article for MSDN. But now with the rise of Indigo, I think people should see the light of the extremely clever and powerful Indigo platform. Indigo has not only the overall cool and sexy ServiceModel programming model which gets manifested at the surface at least by a number of .NET attributes. No.
Indigo also has (although currently still a bit rough) a powerful means to transform your XSD and WSDL and Policy metadata into a CLS-compliant representation. Yes, sure. There is a command line tool called svcutil.exe. But I intend to dive a bit deeper and show how the guts of such a tool work.
Using the following code you can easily imagine how you can build your own tools (if you are an alien called 'plumber' or 'tool vendor') in order to provide some functionality for schema-based contract-first design and development which serves Indigo as the runtime. Obviously, this is nothing more than some demo code.
public static void ImportMetadataAndGenerateCode()
WsdlImporter importer = new WsdlImporter();
// Load metadata documents from current directory
foreach(string xsdFile in Directory.GetFiles(".", "*.xsd", SearchOption.TopDirectoryOnly))
foreach(string wsdlFile in Directory.GetFiles(".", "*.wsdl", SearchOption.TopDirectoryOnly))
foreach (string policyFile in Directory.GetFiles(".", "*.wsp", SearchOption.TopDirectoryOnly))
XmlDocument doc = new XmlDocument();
ServiceContractGenerator generator = new ServiceContractGenerator();
// Generate code from contracts
foreach (ContractDescription contract in importer.ImportAllContracts())
// Here we have the abstract CLS CodeDom in 'our hands'... (in generator.TargetCompileUnit)
using (StreamWriter writer = new StreamWriter(File.Create("firststeps.cs")))
Compared to today's available APIs when it comes to code generation based on metadata, the new Indigo API is much more powerful, feature-rich, and - most important to me - elegant to program. Any of them, whether old or new, are spitting out a CodeDom tree representation. This is perfect for applying code enhancements through a decorator pattern-oriented approach. Once you have the CodeDom in place, you can literally do anything with it.
Note: AFAIK, WSE has no official, 'native' approach to get at the code/CodeDom from any XSD and/or WSDL. At least, I could not manage to hack it up in a reasonable amount of time.
Voila. This is the very first rough starting point for adding Indigo code-gen support to tools like WSCF. Sorry for no square brackets being present in above's snippet ;)
So, this is just one small piece of the big, big world of Indigo. Maybe next time, we will dive again into the deep areas of distributed applications programmer's new baby... there is enough to cover for everybody.
Here is the sixth new feature of WSCF 0.5 - thanks to a number of feedback messages from our users:
Improved WSDL Wizard - Various enhancements
-We enabled WSDL round-tripping: loading the wizard from an existing WSDL and being able to add and remove operations et. al. I.e. you can now visually edit your service interface description safely inside the WS-I boundaries. Currently only supports WSDLs we have created through WSCF.
-We can now have any number of headers for a given message, not just one, which is the limitation in WSCF 0.4.
-We can now import additional XSD files, not just the one initially selected to start from in the IDE.
Enhanced code generation - ASMX Web Service help & doc page
We now provide a working Web Service help page that the user can use when going to the .asmx endpoint with his browser. Currently we just disable this ‘documentation’ feature. This documentation page provides the same test and documentation features as the original one; but it intrinsically disallows calling ‘?wsdl’ on the endpoint (returning a 404). Because we start from the WSDL we do not want to have the WSDL available through the endpoint (although it would be possible technically).
Here is the fourth new feature of WSCF 0.5 - thanks to a number of feedback messages from our users:
Enhanced code generation - Misc improvements
-Enhanced properties: we now check for null references when we generate properties for private fields.
-Constructors: we now generate some default ctor code for data classes so that you can set up your DTOs with one single line.
-Collections: we now validate input parameters (i.e. nullity) for Add, IndexOf, Insert, Remove, and Contains.
-Generated Web Service methods throw NotImplementedException by default.
-XML documentation in /description/schema/.../element/annotation/documentation will be persisted in "<remarks>" XML docs in code for generated type.
Here is the third new feature of WSCF 0.5 - thanks to a number of feedback messages from our users:
Enhanced WSDL generation - Adding <service> element for better interop
We now optionally generate a <service> element into the WSDL. Actually, we think that we just should create a 'service-less' WSDL as an abstract interface description. And indeed, the service element is spec-wise not needed. But Mr. Interop discovered several problems when testing WSCF-generated WSDLs with some Java stacks.
So this is for interop reasons, primarily.
I can't stand. After the first few days of Indigo hype, we are back to business.
Now that Indigo is here (well, at least in the shape of code snippets in blog posts) people start to wonder about 'best practices' - funny, isn't it? One of the main concerns a lot of bright people are currently musing about is the contract story. And this absoutely does not just count for Indigo, that's for sure. And Indigo is still far away, especially for the most part of our customers.
Alas, here is my 2 cents on it.
It is all about being explicit.
The current discussions are revolving around whether to write your 'contract' in native .NET through writing down interfaces - or by starting with something different, like XSD and WSDL. Well, nothing new so far ;)
No. The world is not black or white. We all know this. So nobody might recommend just only one approach, or the way.
We should be frank and admit that there are actually good reasons for starting with a non-CLS representaion (i.e. C#, VB, or whatever) - at least just for sake of explicitness. Sometimes it is actually better to turn around and see the world through different eyes. Therefore we need 'this other approach'. We do not want to solely rely on XmlSerializer (or any other evolved magic ser./deser. instance, for that matter... XmlFormatter).
What really annoys me is that nearly everybody seems to ignore the interoperability aspect of services (and Web Services...) nowadays. If you (try to) do serious interop in your daily work, you won't even bother starting with C# or VB or Java... and yes: I know that you might want to see C# interfaces and some square-bracketed attributes as one valid way to write down your service's interface description. But then, I want to cite Steve Vinovski who hits the nail:
When you start with the code rather than the contract, you are almost certainly going to slip up and allow style or notions or idioms particular to that programming language into your service contract. You might not notice it, or you might notice it but not care. However, the guy on the other side trying to consume your service from a different implementation language for which your style or notions or idioms don't work so well will care.
... and Indigo won't heal those wounds. Sorry.
Let me throw in another aspect. This point supports my vision of being explicit.
With every new day I think about those contracts more and more in a way of DSLs (domain specific languages).
Just as the Windows Forms designer in VS.NET is kind of a graphical DSL for our GUI in Windows Forms applications, we could have a (graphical or not) notation of service contracts. The user controls on our forms are the interface into our client side GUI. I surely do not want to start designing my GUIs by hacking up .NET code, no. And I surely do not want to hack up XAML code one day, no.
Obviously, I do not want to design my service interface by typing .NET code annotated with attributes - neither do I want to hack up angle bracketed XML/XSD and WSDL, no. So we need an abstraction on top of it - a DSL which models our service interface contract and which is also executable.
Or for the more XML-infected guys out there: it is about the WS-I BP 1.x WSDL InfoSet (a term which does not exist, AFAIK). And the best means to write it in a hardcore fashion would be to write down XSD and WSDL, but nobody wants to do this. Then you better have a DSL and tool support to help you out.
As Tim mentions, there is a small tool which tries to abstract away all the nitty-gritty details of WSDL and people seem to love this approach. Once you have your service contract in place (as WSDL which you do not need to understand, but you have the one valid and interoperable serialization format of the WSDL InfoSet), you can generate code from it - and one day even for Indigo, it's just another stack or platform. This tool is in a very basic sense DSL-ish, although there is a long road to go.
BTW: maybe we want to compare the last part of this discussion with the religious war revolving Binary XML... just pops up in my brain...
"We are still not there." (tm)
More Posts Next page »