innoQ

Hartmut's BoxHartmut Wilms’s Weblog

« Januar 2005 | Main | April 2005 »

22.02.05

Tim Ewald on (Indigo) contracts

Why is it Tim Ewald expresses my thoughts so much better than I do ;-) ?

Here is what Tim Ewald says about tool support und why simply relying on tools to generate your contract is not enough:

“The problem today, as I see it, is that tools aren’t actually very good at that, as evidenced by the problems people have getting their tools to emit contracts that actually express their desires and that their clients can consume. The reality today is that if you care about your client being able to EASILY consume your service, independent of toolkit or platform, you have to care about your contact. If you author it indirectly using source code, you need to not only know how XSD and WSDL work, but how your tool maps to them as well.”

His thoughts about WSDL/XML/XSD contracts concerning loose coupling pretty much summarize what I’ve been trying to get across:

“There is another orthogonal aspect to this as well. Real loose-coupling between services will come when people actually leverage the composibility and open content model aspects of XML. If you start from OO code to generate your contract, you are unlikely to do that. How many loosely-coupled OO models have you seen? Translating them to XSD won’t give you loose-coupling, it will give you tight-coupling in another language.”

OO simply isn’t SOA. You may use OO languages to implement a SOA but you have to adhere to the message/document-based paradigm!

Posted by Hartmut Wilms at 21:02

18.02.05

About Indigo, typed and untyped messages, and right or wrong

Clemens Vasters and I have a discussion about Indigo and web service implementations. At first I am happy to be discussing this topic with him, and my “Wrong^4” post was both a way to express my concern and a way of gaining attention. At least the latter was successful ;-).

To get things straight. I think that Indigo is or will be one of the most sophisticated communication stacks around. It provides all the flexibility a developer or architect could want. Maybe I’m exaggerating a little bit, but only a little. Indigo provides support for contract and implementation first development which is a good thing. Please don’t get me wrong, CLR typed messages and types are one possible way of implementing web services, WSDL based development is another. The same applies for typed messages, i.e. serialized XML, and untyped messages. Both have their place in a SOA.

I got the impression that Clemens Vaster was pushing the CLR typed messages and the implementation first approach too much. There are reasons for untyped messages.

In a perfect world I would like to define messages and typed in a contract. Typed would have mandatory and optional attributes, simple or complex. The message would contain the required data (at least the mandatory attributes) and the requested service (operation). The defined endpoint would then choose the appropriate implementation. That’s message-based communication to me. Non-braking changes could easily be implemented in the service without the need to change the consumers. This is loose coupling at its best. Hm, exaggerating again. I understood that Indigo provides the means for implementing such services.

Again: I want both or better all the ways of developing message-based systems provided by Indigo. I don’t want to loose possibilities by sticking to the simple solution which hides the (sometimes) important details. As I already pointed out before, I’m not sure that making everything as simple as possible is the right way. Maybe complex programming models will be difficult to grasp for the every day developer. But making things too simple might lead to a naive and error-prone , hard to maintain implementation. I’ve seen so many system which contained tons of diverse simple approaches which ended up in a highly entangled chaos. Maybe that’s something completely different but making things sooooo simple often sounds toooooo good ;-).

Posted by Hartmut Wilms at 21:13 | TrackBack

Clemens Vasters on my "Wrong" post ;-)

Clemens Vasters comments on my answer to his post:

“Everyone writing DCOM apps must write and understand MIDL and NDR. Everyone writing CORBA apps must understand IIOP on a protocol level. Everyone who codes in C must understand x86 assembly. Correct?”

No, that’s not correct. There is a very, very important difference. The difference is about “logical” and “physical” protocols. or even better between contracts/interfaces and hard-wire protocols. On the other hand Clemens Vasters is right. Every model is passed through a transformation chain until it reaches “its final destination”. C is an abstraction of x86 assembly which in turn is an abstraction of “1001101001001…”. The trick is to decide when further transformation are of no importance to the developer.

Let’s take his example of CORBA and IIOP. Is IIOP important to the developer. No! Oh, I can hear your screams. I know about “IIOP Complete” by William Ruh et. al. This is surely a book worth reading. But I would like to reduce the required knowledge level to that of an application developer. Then, is IDL important to the CORBA developer? Well, yes and no. It is certainly helpful to know about IDL but IDL and C++, Java, and Smalltalk interfaces share a common paradigm: objects and OOP. Therefore the contract described by a C++ class is equivalent to the IDL contract.

Now, here’s my concrete answer: SOA is a paradigm based on messages/documents passed between participants. This is something completely different than invoking methods on a remote object by an RPC call. Indigo’s implementation first programming model resembles RPC calls. This may be applicable in certain contexts. And sometimes it is certainly preferable. But when SOAs are concerned stick to messages and documents, please. There is an Indigo contract first programming model. Use it by all means. But do care about the message-based SOA programming model, even if it is a little bit more, hm …, clumsy.

Maybe this has been a misunderstanding? Indigo has it all. Indigo rocks (when put to correct use) :-)!

Posted by Hartmut Wilms at 13:48 | Comments (4)

Wrong, wrong, wrong, and again: Wrong!

Clemens Vasters hasn’t given up on his anti-angle-brackets thing. It is useless to repeat all the arguments against his position, because so many people already did. Although he is right when he says that no one really enjoys authoring XSD, WSDL or policy files manually, it’s completely wrong to “start asking for tools that hide all those details”.

Never do this! Start asking for tools which help authoring XSD, WSDL, or policy files. Tools which don’t hide your contracts but help to understand them. This is not to say that APIs are bad. There are contexts which demand for APIs, even APIs which hide the contract details. But in most cases, especially when taking SOAs into account there is a great demand for APIs which closely resemble the contracts of the world you want to participate in.

I don’t want to annoy people with the details of XSD, WSDL or even worse WS-Policy. But everyone implementing a SOA MUST understand the basics and the paradigm!

Posted by Hartmut Wilms at 11:53 | Comments (3) | TrackBack

Today and tomorrow: Will Indigo heal...? Powerful object model for contract-first glue

After my dark musings about wether Indigo is a gift or a dangerous thing, Christian Weyer lights up my day with wonderful insights. Due to the fact that ICF (Indigo Contract First) :-) will be very easy to implement, I’m really curious about the many additional (free) features of this tool ;-).

Posted by Hartmut Wilms at 11:17 | TrackBack

The many faces of Indigo

Tim Ewald is commenting on Indigo, again.

“What you’re doing may be ‘service oriented’ (whatever that actually means), but is it Web services? And if it’s not, will the fact that Indigo is using the same APIs to do very different things with very different implications going to help or hurt people?”

Actually I’ve been thinking about this question for a long time. Does making things as easy as possible really help people? This reminds me of Niklaus Wirth and his famous saying “Make it as simple as possible, but not simpler.”. Maybe Indigo is pushing the line too far, too simple that is. Providing a single means for doing very different things seems to be making development very easy and maintainable. But on the other hand developers and architects must not loose their grip on the underlying technologies and especially the paradigms. Service-oriented architecture is nothing you can buy but rather something you have to do and “live up to”. It is a software development paradigm with certain constraints and best practices which should ever be present when developing distributed systems. Hiding these facts from the developer may be a dangerous thing.

We will have to wait until the final release. Many things may still change and we will have to see how things work out. After all software development isn’t a black or white thing but a field of many, many shades of gray.

Posted by Hartmut Wilms at 11:00 | TrackBack

17.02.05

SharpMT

Today I was looking for a decent desktop blog editor. I experimented with eco for Windows, Zempt, w.blogger, and WB Editor 2. Either the configuration of these tools, or the restricted functionality during the test period made me look for another alternative. Now I found SharpMT. This tools is a nice addition to SharpReader which I actually use as a feed reader.

What’s nice about SharpMT:

cons:

I’m quite content with SharpMT so far. I will try it a little longer and hopefully SharpMT will fulfill my requirements …

Posted by Hartmut Wilms at 16:46 | TrackBack

16.02.05

Basta 2005! Resume

I haven’t had much time listening to sessions today. Instead I talked to many visitors and speakers of the conference. The gist of what I heard is that .NET is gaining ground in the IT landscape of Germany. However only few people are experimenting with the .NET Framework 2.0 or Visual Studio .NET 2005. Generics and the other new language features are foreign to many developers and seemingly hard to grasp.

Seems like .NET still has a long way to go, at least in Germany.

Nevertheless Basta! 2005 was a success. The speakers were obviously more competent and eloquent than last year. SOA was a topic in many sessions which is a good thing. It is no proof that developers have adopted the concepts, yet. But they are at least willing to listen to new architectures and trying to comprehend all this fancy stuff.

In my opinion Microsoft is in its infancy concerning enterprise development. Although the .NET Framework, the web service support including WSE, and the plans (Indigo) for the future are solid implementations and concepts, Microsoft still has to proof that they are able to provide business solutions or technologies to implement enterprise business solutions. Simply put they have to catch up and time may be running short …

Posted by Hartmut Wilms at 20:20

Basta! 2005 Web Sicherheit

Ich wollte mich ein wenig bremsen, was die blog Frequenz von der Basta! aus angeht, aber der Vortrag von Christian Wenz & Tobias Hauser war einfach der unterhaltsamste bisher. Leider hat Herr Hauser (wunderbar, einfach schon der Name ;-)) ein wenig die Statistenrolle �bernommen. Vom trockenen Humor des letzten Jahres klebt mir immer noch die Zunge am Gaumen :-).

Viel mu� man zum Inhalt nicht sagen, au�er, dass er allen Entwicklern schon l�ngst klar sein sollte, aber eben nicht ist. Ich schlie�e mich da nicht g�nzlich aus.

Die Seite von Hauser & Wenz ist sicherlich ein Anlaufpunkt f�r Fragen im Bereich Webentwicklung und Security!

Danke f�r den tollen Vortrag. Jetzt in ich wach genug, um die letzten Sessions zu genie�en.

Posted by Hartmut Wilms at 11:32 | TrackBack

Basta! 2005 Visual Studio .NET 2005 Team System

At the end of my first day at Basta! 2005 Scott Guthrie gave an overview of Visual Studio .NET 2005 Team System. The session was divided into some slides showing Team System features and a live demo.

Team System extends Visual Studio by providing tools which span the whole software development lifecycle:

I will elaborate on the Modeling Tools. Team System provides a set of tools for modelling all aspects of a distributed software system, such as the design of the architecture and services to implement as well as the modelling of the existing hardware infrastructure the system shall be deployed to. All tools are integrated into VS.NET and use a uniform set of views, such as toolbox, modeling area, explorer, properties view, and messages.
Two designers are used by developers or architects for modeling the system architecture and the services to be implemented, the Application Connection Designer, and the Class Designer. Both tools include support for code generation and roundtrip-engineering, i.e. bidirectional code and model synchronization. The Application Connection Designer allows to model web services, service endpoints, clients (Windows Forms & Web Application), and databases. The Class Designer is used to model classes, properties, methods, and relationships between classes. In contrast to UML class diagrams the elements of the Class Designer resemble the visualized language elements as close as possible. The Logical Infrastructure Designer and the Deployment Designer support the (test) deployment of architecture models and services. They support the tasks of operators. The Deployment Designer allows to virtually deploying a model defined in the Application Designer. The tools are promesing. However they lack important features in the current release. The designers generate code according to Microsoft’s still propagated Code First web service development. There is no way to influence code generation which is bad reagrdless of Code or Contract First development. According to Christian Weyer this won’t change until version 2, i.e. they won’t be included in the final VS.NET 2005 Team System release.

I really enjoyed the first day of the Basta!. The sessions I attended were pretty cool and I was impressed by the new features of VS.NET. However I still have some second thoughts about all the visual editors, especially in the field of ASP.NET development. It’s quite simple to impress an audience with the powerful point & click features, but developing a hudge software system based on point & click programming scares me to death…

Posted by Hartmut Wilms at 08:25 | TrackBack

15.02.05

Basta! 2005 SOA and Web Services with VS.NET 2005

I spend some hours listening to session by Christian Weyer. Christian talked about SOA, Software Factories & DSLs (in the context of modeling web services), and web service development with .NET Framework 2.0.

He mentioned the 4 (Microsoft) tenets and gave some general advice for distributed systems based on a SOA. His evaluation of the state of web service technologies today was, well, less than sobering. The general tenor was that after more than 5 years web services have reached at a common understanding of the transport level (mostly reduced to SOAP over Http), and the vocabulary (XML including SOAP & WSDL). The ever evolving WS-Standards which provide required means of implementing enterprise application based on web services hinder vendors developing final implementations. But he gave us a ray of hope, too, Indigo. At least the Microsoft community will in some (or some more) months be able to develop enterprise web services ;-). Well I’m very impressed by Indigo’s programming model and its features. But the core problem won’t be solved, though …

Concerning modeling of web services he presented the “Whitehorse” tools of Visual Studio .NET 2005 Team System. I skip this part, because I’ll comment on Scott Guthries evening key note which was targeted at this topic in another entry to come. The gist of Christian’s talk is compatible with Scott’s.

Finally he talked about ASP.NET 2.0 Web Service features:

ASP.NET 2.0 allows for configuring the workings of the XMLSerializer by implementing the now official IXMLSerializable interface in combination with the XMLSchemaProvider attribute.

Developers may influence the generation of proxy classes, too. SchemaImporterExtensions provide the necessary means of doing so. Extensions are configured in the application or machine confihuration.

The network API offers means of controlling and monitoring network state. Developers can check if the network is available which is of some worth when dealing with web services. Applications are notified of changes in the network state and automatic proxy detection is possible.

No real contract first development, but code based contract first at least. The WSDL.EXE tool supports the generation of interfaces instead of abstract classes for server stubs with the /serverInterface switch.

Christian’s talk was a lot of fun. Next time his demo will work, I’m sure ;-). I agree with his views concerning the state of web services and his opinions in general. Thanks for these two great sessions!

Posted by Hartmut Wilms at 21:36 | TrackBack

Basta! 2005 Spring Edition first impressions

Today I’m attending the Basta! 2005 Spring Edition. Basta! is a german .NET and Visual Studio .NET conference. This is a first impression of the sessions I visited.

One of the top sessions is certainly Scott Guthrie’s introduction to ASP.NET 2.0. Scott is a very eloquent speaker and gave a great performance. It is beyond the scope of this blog entry to even summarize all the topics he addressed. Therefore I’m picking the ones which I found most impressive.

The most interesting concept is the ASP.NET Developer Stack. The stack consists of

What’s so interesting? Every layer builds upon the one below. Nothing special about that. The interesting stuff begins at the building block, the API respectively. For every aspect of a web application an API exists. The API gives programmatic access to these aspects. The framework and its components use this abstract framework. Abstract means that nothing is hard wired. Every aspect is customizable by the provider model. Every API uses a provider (adapter) to access the concrete implementation of an aspect. Imagine roles within your web application. There are controls which address security and role management features. These controls use the underlying API to access role data. The API uses a provider to eventually collect the requested information. The default provider for instance fetches the data from the web app configuration. If you want the data to be fetched from a database, i.e. use the database roles for example, just configure another provider which accesses your database. Providers are configured within the web.config file of your web site. Providers enable the developer to use any controls and a consistent API to access any logic, data source or backend. If your data source changes, just configure the corresponding provider. No code has to changed. Pretty slick!

Another great improvement is code generation. It is a very good example that less or even nothing is often better than much. With VS.NET 2005 if you create a new project or solution a single directory is created - nothing more! VS.NET has changed its strategy. Instead of generating tons of default code which was a pain in the a.. to change, it just does nothing. This strategy is used throughout VS.NET. For instance HTML code isn’t changed by the designer anymore. Strike! This applies to the formatting, too. Any change to properties within the designer will only add corresponding source code and use the formatting applied in the source.

Designers and configuration have been greatly improved. For instance formatting is highly configurable. A very interesting configuration topic is the configuration of your web site via IIS console. The providers I mentioned above maybe configured at runtime, deploy time respectively. The web site may also be configured by an ASP.NET application, i.e. a web frontend.

There’s lots of more stuff, but the topics I mentioned are my favourites. I’ll continue blogging about other sessions pretty soon. Stay tuned!

Posted by Hartmut Wilms at 16:24 | TrackBack

14.02.05

Indigo Programming Model

Don Box has given us another glimpse of Indigo.

He is talking about untyped and typed implementation interfaces and Indigo channels. The presented programming model is one of the most sophisticated I’ve ever seen concerning web service development. I can’t wait to get my hands on Indigo. Although Don Box does not vote for the untyped or typed approach, I hope Clemens Vasters will change his mind on angle brackets, now. I think that I’m going to blog on the benefits of untyped messages/implementations, again pretty soon.

Another great thing about Indigo is the channel concept. As demonstrated by Don Box channels could be used to implement SOA intermediaries within a consistent programming model. Because channels can be created at runtime, Indigo allows for a very flexible intermediary chaining. Great!

Posted by Hartmut Wilms at 10:11