innoQ

Hartmut's BoxHartmut Wilms’s Weblog

SOA | Main

06.02.08

REST & SOAP/WS-* - two different views

For a very long time I’ve been promoting the SOAP/WS-* way of developing web services. After many discussions, articles and posts on the REST/SOAP war and some experimenting on my own I finally tend to prefer the REST way. The main reason for doing so are the advantages of loosely coupling services when going the REST way.

The most important difference when designing RESTful and SOAP/WS-* web services is their view on models and processes. In my opinion REST demands a complete new way of designing services. Stefan provides a nice example of RESTful design on InfoQ.

Ganesh Prasad delves in the differences (or similarities) by setting up a Namespace-Time continuum, which should unify both approaches.  Mark Baker responds and Ganesh updates his view.

Mark argues that “WS-* fails to separate interface from implementation, while REST does”. He provides an example task of changing the implementation of an interface and asks the question: “if I change the implementation of a component from a stock quote service to a weather report, does the interface have to change? If yes, then prima facie you haven’t decoupled interface from implementation, have you?”.

Ganesh responds:

Now, as an architect, I am rather sensitive to issues of tight coupling, and have often railed against examples of this, such as the SOAP-RPC style itself and the generation of WSDL files from Java implementation classes. But Mark goes much further. He would like to change the implementation of a service from a Stock Quote service to a Weather Report, and he would like to see his interface unchanged! To my mind, this goes beyond the reasonable.

I especially like and agree with his statement that Mark’s change is like “changing from pasta to soup, and expecting to continue using a fork”. It appears to me that both are talking about the same thing from a different perspective. Mark refers to the “technical” generic interface provided by REST only, whereas Ganesh concerns himself with the service design.

The RESTful approach demands a mapping of service design logic to a combination of HTTP/REST verb and URI. Every combination has to be interpreted in order to get its meaning. In most cases the meaning is obvious, in some it isn’t. Thus the RESTful service design has to put a strong emphasis on a very slick choice of meaningful URIs, especially when setting aside a service definition, such as WADL.

Posted by Hartmut Wilms at 12:17

19.08.07

The Four Tenets and XML Messaging with WCF

Don Box has responded to my post on Harry Pierson’s discussion about retiring the four tenets. I would like to respond to some of  his statements:

Harmut states “WCF Contracts are still CLR-Classes, not Schema or Contract.” This isn’t quite right. The in-memory representation for WCF contracts is a DOM-ish tree that can be cons’ed up using any number of techniques, not just writing C# interfaces with [ServiceContract] (go look at Sys.SvcModel.Description.ContractDescription if you care to spelunk). ContractDesc is neither CLR reflection data nor WSDL – rather it’s the optimized in-memory rep used throughout our runtime. FWIW, we’re actively investing in other ways to write ContractDescs down (honestly I’m not a big fan of CLR interfaces or WSDL – please God tell me we can do better).

I know about WCF’s representation of Service Contracts. What I meant was that concerning the Service Design WCF Contracts are still CLR classes annotated with WCF attributes. As a service developer or designer I don’t care about the internal representation, I’m using the “API” representation. In the WCF case this is - at least in the Service Model - a CLR interface or class.

Before continuing I want to express my deep respect for the design of WCF, especially its channel model layer and XML messaging framework.  The service model layer serves as a mapping between the XML (WSDL, XSD) world and the CLR world. In some cases this is the right approach, in the case of service-oriented principles it’s not. WCF serves two main purposes: a) consolidating the former .NET APIs  for distributed computing and b) providing a web service stack for implementing services according to service-oriented tenets (here we go again).

Doesn’t WCF live up to the second purpose, then? Well, no and yes. As Ben Kloosterman points out in the comments to Don’s post “the biggest problems is people have no experience with SOA so they fall back on remote object tecniques but using an SOA tool like WCF”. I would change this to “SOA tool like the WCF service model”. That’s the first and maybe most important argument against the service model (when implementing SOA services!):

  1. Developers and designers tend to fall back to traditional remote object techniques.
  2. The “schema and contract” mentioned in the four tenets are reduced to generated artifacts, which aren’t even part of your code basis. A contract has to be designed, not generated!
  3. X-O-Mapping will never satisfy all your needs. WCF Contracts and XML Serialization won’t either.
  4. Loose coupling is what all tenets (to some extend) are all about. The need to (re)generate proxies when a provider or consumer changes even in the smallest degree is not what I would call loosely coupled. This is a weak argument, which should be examined in greater detail. Granted.
  5. Mark Seeman states in the comments to Don’s post: “It’s easy to understand”. I would say that C# interfaces that are cluttered with C# attributes are as easy to understand as XSD schemas or even more difficult.

Let’s have a look at this example of a data contract taken from “Designing Service Contracts with WCF:

[DataContract(Namespace = "http://schemas.thatindigogirl.com/2005/12/LinkItems", Name = "LinkItem")]
    public class LinkItem {
        [DataMember(Name = "Id", IsRequired = false, Order = 0)]
        private long id;
        [DataMember(Name = "Title", IsRequired = true, Order = 1)]
        private string title;
        [DataMember(Name = "Description", IsRequired = true, Order = 2)]
        private string description;
        [DataMember(Name = "DateStart", IsRequired = true, Order = 3)]
        private DateTime dateStart;
        [DataMember(Name = "DateEnd", IsRequired = false, Order = 4)]
        private Nullable<DateTime> dateEnd;
        [DataMember(Name = "Url", IsRequired = false, Order = 5)]
        private string url;
        [DataMember(Name = "LinkType", IsRequired = false, Order = 6)]
        private string linkType;
    }

The corresponding XSD schema looks like this:

<xs:schema elementFormDefault="qualified" 
           targetNamespace="http://schemas.thatindigogirl.com/2005/12/LinkItems" 
           xmlns:xs="http://www.w3.org/2001/XMLSchema" 
           xmlns:tns="http://schemas.thatindigogirl.com/2005/12/LinkItems">
  <xs:complexType name="LinkItem">
    <xs:sequence>
      <xs:element minOccurs="0" name="Id" type="xs:long"/>
      <xs:element name="Title" nillable="true" type="xs:string"/>
      <xs:element name="Description" nillable="true" type="xs:string"/>
      <xs:element name="DateStart" type="xs:dateTime"/>
      <xs:element minOccurs="0" name="DateEnd" nillable="true" type="xs:dateTime"/>
      <xs:element minOccurs="0" name="Url" nillable="true" type="xs:string"/>
      <xs:element minOccurs="0" name="LinkType" nillable="true" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>

</xs:schema>

The namespace declarations within the schema element are a little bit confusing when you’re not accustomed to XML. But all the rest isn’t really more difficult than the C# interface, is it?  In my opinion every service designer and developer has to have a profound understanding of XML. Hey, you are developing SOAP Web Services. You should have a basic understanding of your published contracts/interfaces, don’t you?? When you do have a good understanding of XML, XSD isn’t that difficult anymore (regarding interoperability you should stick to simple type definitions).

But what do you gain from incorporating XSD (and WSDL) as first-class citizens into your implementations?

  1. A good understanding of your published interfaces. This is a must!
  2. Very expressive contracts. For instance if you include a zip code in your type definitions, its contents should be of type string and limited to the zip code format of your country. This restriction could easily be integrated in your human- and machine-readable contract by the XSD concept of “inheritance by restriction”. A concept unknown to the CLR (type system). When using WCF contracts these restrictions have to be written down in a separate API docs that are likely to be ignored by the majority of developers. Contracts cannot be ignored, they are validated by your service (at least they should be - see below).
  3. We could implement a very forgiving validation thereby enhancing the loose coupling of our services. We’ll come to that in a moment. 
  4. Flexibility.

The sad thing about WCF is, that it doesn’t provide real schema validation. It provides XML Serialization, which partly does the same. Luckily there is a nice way of adding schema validation to WCF. The good thing is that WCF supports XML messaging out-of-the box.

Don asks me (and others) to “sketch out a concrete example of what they would rather write assuming a “traditional” imperative programming language (static or dynamically typed)”. Here is my answer:

1. Model your data types with XSD and your contracts with WSDL. It is no fun to write a complete WSDL on your own, but there are ways of simplifying this task. You might use a modeling tool (such as the one to be published with v3 of the Web Service Software Factory) or you might model your messages in your schema and generate the WSDL with a template based code generation approach.  

2. Register and publish your contract (WSDL & XSD) in your service registry/repository. There isn’t any real (or state of the art) repository/registry solution provided by Microsoft. But there are other solutions, which might be used. After all we are living in a service world, which is independent of vendors and platforms …

3. Take the “untyped services” approach of WCF:

[OperationContract(Action = "CreateLink")]
Message CreateLinkItem(Message aLink);

The Message objects represents the SOAP envelope and provides access to its headers and the complete XML contents. Although this approach is called “untyped”, your contracts are strictly typed. So “untyped” only refers to the generic CLR interface. Type-checking is provided by:

4. Validate incoming messages via the custom Behavior/Inspector mentioned above or even better via Schematron. This approach is beyond the scope of this post. I’ll cover this topic in one of my future posts. There is no Schematron implementation for .NET (save an abandoned project)? No problem, just revert to the reference implementation :-).

Schematron allows your services to be very forgiving concerning changes in your consumer’s logic. Your service might expect a purchase order. This purchase order has to conform to a certain structure. If your consumer extends this structure, you’re not supposed to break! After all, everything you request is still provided. As already mentioned above, I’ll provide an example for this approach in one of my future posts. 

5. Access the payload of the message by using XPath expressions. You might also use the XmlDictionaryReader or LINQ to XML (or LINQ to XSD).

So, I don’t want an alternative to WCF. I only want to use what’s already there. It is either incorporated into WCF already or can be added via WCF extension points. In my opinion XML messaging with WCF is the best approach for developing services that adhere to the four tenets.

Posted by Hartmut Wilms at 19:18

14.08.07

Retire the Tenets?

Harry Pierson states: “Retire the Tenets”.  John Heintz agrees by dismissing the Four Tenets as useless:

There is one other thing about SOA that drives me bonkers. I’m hooked on architecture by constraint - limit the system in certain key areas to promote certain use and benefits. The four tenets of SOA don’t do it to me at all.

Well, tenets are just that: tenets. Don Box and many others explained these tenets. Just “google” for the “four tenets” and see for yourself. Principles, guidelines and best practices might be drawn from the tenets. Granted the tenets may not be used as a map to solid service oriented design, but they started a different way of looking at distributed computing (in the MS world and in others, too). They started a discussion about service oriented principles, which all to some extend are based on the ideas expressed by the tenets.

Harry Pierson concludes that the four tenets had been “designed to help the Windows developer community wrap their heads around some of the implications of messaging and service orientation”. In a way the four tenets just expressed, what “almost” everybody outside the MS world knew already. Their only use was to impress that single truth in the brains of “DCOM, MTS and VB” developers. Now, that’s been done:

I would say that the tenets’ job is done and it’s time to retire them. Once you accept the service-oriented paradigm, what further guidance do the tenets provide? Not much, if any.

In a perfect (service oriented) world maybe I would agree. But has this paradigm shift taken place? Are “Platform vendors […] falling over themselves to ship service/messaging stacks like WCF” and do “most developers […] look at these stacks for the next systems they build”? Most important: do these platforms and stacks (fully) adhere to the principles, which are based on a truth almost everybody knew already?

I don’t think so! WCF might be used in a fully service-oriented way: message-oriented, document-based, contract and policy driven. The common guidance looks different, though. Have a look at ASMX, WCF, Axis 2 and all other SOAP stacks:

Just write the classes, we’ll generate your contract and policy and throw in some XML (De)Serialization for good.

WCF Contracts are still CLR-Classes, not Schema or Contract. There isn’t even a standard procedure for validating the message against the schema (just an XML Deserialization, which does the job, well, at least for the most simple cases).

John and Harry, do you really think that every developer has adopted to the message-oriented paradigm and that “service orientation is mainstream”? I’m afraid not. As long as the CLR/JVM/…-First approach is proclaimed by the vendors and the masses listen and follow, the four tenets are far from retirement!

Posted by Hartmut Wilms at 20:36 | TrackBack

04.08.07

John Devadoss about Big SOA, Little SOA

John Devadoss wrote a post on “Big SOA, little SOA”. He is advocating a - what Microsoft calls the middle-out approach - instead of a top-down or bottom-up approach.

This middle-out approach starts on a small business case and “build out the entire use case end-to-end, from the data through to the consumption”. All the time you should have “the big picture” in mind, as if you were building a “Big SOA”, i.e. stick to the right tenets, build highly adaptable and reusable services and start to setup a SOA Governance  along the way:

You don’t learn by planning – you learn by doing. Partitioning your functionality helps you track changing business needs much more effectively.

I’m especially fond of his “snowball” metaphor:

Last, but not the least, successful customers use what we call a “snowball” approach. How do you build a big snowball? You start with a small snowball.

Posted by Hartmut Wilms at 21:23 | TrackBack

14.06.07

SOA-Expertenwissen

Endlich ist es soweit! Das Mammut-Werk zu Service-orientierten Architekturen, herausgegeben von Gernot Starke und Stefan Tilkov, steht in den Regalen der Buchhändler und ist natürlich auch hier erhältlich. In fast 50 einzelnen Beiträgen schreiben viele renommierte Experten über Themen wie SOA-Grundlagen, betriebswirtschaftliche Aspekte, Prozess- und Methodenansätze, Governance, Architektur und Technik sowie Betrieb von SOA-Infrastrukturen.

Ich habe einen Beitrag mit dem Titel “WCF als Basis einer SOA” verfasst.

Posted by Hartmut Wilms at 14:46 | TrackBack

14.05.07

SOA.NET news on InfoQ

I completely forgot about announcing my activities on InfoQ as a news contributor. So here I go:

 

Since February 2007 I’m contributing news to the .NET and SOA community on InfoQ. Please have a look at these and all other InfoQ  communities for news, articles, interviews, presentations, and books on Enterprise IT matters.

 

I will continue to state my personal opinions (on these and other matters) in this blog.

Posted by Hartmut Wilms at 16:35 | TrackBack

01.03.07

BASTA 2007 Spring Edition - Vortragsfolien

Es war wieder einmal eine sehr interessante BASTA in Frankfurt. Viele neue Gesichter waren zu sehen und ebenso viele Neuigkeiten von den Kollegen zu hören.

Hier wie versprochen die Folien und die Solution zu meinem Vortrag:

Dokumenten- und Schema-basierte Services mit WCF

Vielen Dank für drei spannende und informative Tage!

Posted by Hartmut Wilms at 21:55 | TrackBack

03.02.07

Dokumenten- und Schema-basierte Services mit WCF

Ich werde auf der BASTA! Spring Edition 2007 auf dem Enterprise Architecture Management Day am 26.02.2007 einen Vortrag zum Thema

Dokumenten- und Schema-basierte Services mit WCF

halten. Ich würde mich freuen, Sie auf der Konferenz zu treffen und über WCF, SOA und Services zu diskutieren.

Posted by Hartmut Wilms at 15:50 | TrackBack

29.01.07

OOP 2007: Services - Prinzipien und Taxonomie

Vielen Dank für Ihr Interesse an meinem Vortrag auf der OOP 2007 in München. Wie versprochen hier die Folien: Services - Prinzipien und Taxonomie.

Posted by Hartmut Wilms at 22:21 | TrackBack

13.06.06

Reasoning about SOA statements - 2 Services

This is the second issue of a five part series.

Today I would like to elaborate on Services. In the first issue I described Services as little as being part of the Service-oriented paradigm. But what are Services after all?

Services are what we are confronted with each day. Take for instance the postal service. If you want to sent a parcel from A to B, you go to the postal service office, fill out a form including the sender (you) and the receiver. You hand over the parcel with the form to the clerk. You will surely greet the clerk, maybe talk about the weather and you might even tell him what service you ask of him, although it isn’t really necessary. Why isn’t it necessary? Because by receiving the parcel along with the form the clerk simply knows what to do. He might not know about the whole process, but he knows everything about his task in the process chain. The best thing is, that you don’t need to know anything about the clerk’s job nor the process at all. You are asking for a service, which will (hopefully) be performed by the postal service’s service capabilities. And all you need to do is to send the service a message containing the payload (the parcel) and some infrastructure information (the form containing the sender’s and receiver’s addresses). But I’m getting ahead of things.

This example shows that a Service is represented by:

The first two points may be combined into “a measurable capability”. It is important to note, that a service is not defined by its process! The process is interchangeable and merely provides a means for implementing the service’s capabilities. Today business processes are changed continuously - they are optimized, outsourced, replaced by more efficient alternatives and so on. By representing a service by its capabilities these changes may be realized in time and IT departments will be able to keep pace with the ever changing demands of todays business.

There are two other important aspects of a service: first a service is triggered by a message and second, a service responds with a message. Both messages are abstract representations of actions and deliverables. A request message may request a certain service or service operation and at the same time provide data, which are necessary for processing the request. A response message contains the service result and may also trigger certain actions within the consumer. In both cases the message captures data at a certain moment of time. The data is also most probably a transformed, refined or customized version of the data representation within the service boundaries suitable for the consumer’s needs.

In the next issue I will use these observations for describing the relationship between SOA and Web Services.

Posted by Hartmut Wilms at 22:25

31.05.06

Reasoning about SOA statements - 1 Service-oriented architecture

As announced here I (will) comment and elaborate on Stefan’s 10 SOA statements. In this issue I start with an examination of the concept of SOA.

I will not try to give a concrete definition of SOA or Service. Others have failed miserably and I don’t intend to join the club ;-). I will rather present my view of these concepts and the conclusions I’ve drawn.

In order to arrive at a definition or understanding of a complex term it is advisable to decompose it. I start with breaking up “Service-oriented architecture” (SOA) into “Service-oriented” and “architecture”. Wikipedia give a good enough definition of “Software architecture”:

Software architecture or software systems architecture can best be thought of as a representation of an engineered (or To Be Engineered) software system, and the process and discipline for effectively implementing the design(s) for such a system. Such a software system is generally part of a larger system encompassing information and general and/or special purpose computer hardware.

It is a representation because it is used to convey the information content of the related elements comprising a system, the relationships among those elements, and the rules governing those relationships.

It is a process because a sequence of steps is prescribed to produce or change the architecture, and/or a design from that architecture, of a system within a set of constraints.

It is a discipline because a body of knowledge or a general set of principles of (software) architecture is used to inform practitioners as to the most effective way to design the system within a set of constraints.

The important part of this definition is that “[…] architecture can best be thought of as a representation of an engineered (or To Be Engineered) software system, and the process and discipline for effectively implementing the design(s) for such a system […]” according to “[…] a general set of principles […]”. In short architecture

The second part is “Service-oriented”. In the context of software development “oriented” is closely linked to “paradigm”. Thus “Service-oriented” represents a paradigm centered around “Services”. You might compare this to “Objects” within “Object-oriented”. In short Objects are described by their behavior, which is controlled by its state (internal structure). Objects interact with each other and react to events from the outside. Object-oriented analysis/design/programming provide suitable means for modeling (analyzing, designing, implementing) real world artefacts according to the OO paradigm, which is defined by a set of principles (-> Classes, Objects, Methods, Events, Inheritance, Polymorphism, …). The Service-oriented paradigm provides concepts such as Services, contracts, messages and documents. These concepts will be described in the following issues. At the moment the point is that “Service-orientation” represents a set of principles (-> paradigm), which are used to model real world artefacts in terms of software Services.

By reconstructing the term “Service-oriented architecture” from its decomposition we arrive at the following statement: Service-oriented architecture represents a means of implementing software systems, which adheres to the concepts of Services, contracts, messages and documents (among others). In other words Service-oriented architecture described a software architecture (template), which is based on the Service-oriented paradigm. Several conclusions can be drawn from this statement:

And a multitude of questions:

I will present my ideas and views on these topics in future entries. Stay tuned.

Posted by Hartmut Wilms at 14:39 | TrackBack

Reasoning about SOA statements

While talking about Service design and implementation with Stefan some time ago, I felt the urge to reason about his 10 SOA statements, which he published half a year ago. As he pointed out himself the most interesting points are presented, discussed respectively, in the accompanying comments.

I will present my musings on the following statements within the next weeks (that’s the plan …):

  1. The word meanings of the three components within “Service-oriented architecture” in order to arrive at an understanding what Services and SOA are all about. In a way I will be referring to statements 1, 7 and 10.
  2. Statement 5 and 6, which discuss the relationship between SOA and Web services.
  3. Statement 3 in respect of the meaning of messages and documents and their relationship (in the context of a SOA).
  4. Statement 3 and 4 in respect of Service contracts and interfaces.
  5. Loose coupling, its dimensions and their impact on or correlation with service layers/types.

A lot of stuff for the next month(s)!

Posted by Hartmut Wilms at 14:33 | TrackBack

06.05.05

SOA, who art thou?

Rich Turner, Radovan Janecek (VP of Engineering at Systinet) and Clemens Vasters are musing about the definition and “existence” of SOA.

I agree with Radovan Janecek’s overall definition of “an enterprise architecture that follows SO principles”. An even better definition would be “Software Architectures that follow SO principles, cause there is no single true service-oriented architecture. Software architectures depend on the requirements and constraints at hand. Although two systems might be realized with SO principles in mind, the underlying architectures will most certainly differ in one or the other aspect - regardless of the tools used to implement these systems. Thus a concrete architecture (including tools, practices, components, communication stack, protocols, notation) which adheres to SO principles is an instance of the “SOA” concept.

This leads to two main questions (among many others):

a) What are the SO principles?

b) What are the identifying features of a service oriented architecture (making them adhere to SO principles)?

The first question has been discussed by several people for a long time. The four tenets are a very popular definition. Although I do not completely agree with them they are a good starting point.

Whereas the first question kept many people busy thinking and talking about, the answer to the second one has been avoided by almost everyone. Although architecture is mainly concerned with abstraction it is more concrete than principles and paradigms. Architecture nails down principles to “concrete” concepts, practices and patterns. This blog entry is no exception to the philosophical and abstract discussion about SOA and SO. I will try to elaborate on architecture and the SO principles in the near future.

The point I’m trying to make is that SOAs exist, or even better, will have to be designed in order to make service-orientation feasible. I really like Rich Turner’s comments about Microsoft dissociating from a SOA solution. SOA is not a product! Vendors have to provide tools and “components” which maybe adapted/configured in order to implement a SOA. No Vendor will be able to provide a one size fits all SOA.

Posted by Hartmut Wilms at 22:45 | Comments (5) | TrackBack

12.04.05

Aaron Skonnard on Contract-First Service Development

Aaron Skonnard has published an article on Contract.First Service Development in MSDN Magazine and announced it in his blog.

Again, this article explains the importance of Contract-First Development in a SOA. The comparison with coding COM components in VB shows the dangers of hiding the paradigm from the developer. I don’t indulge in writing WSDL or XSD files, but hiding the interface or message design from the developer and replacing it with an out of place RPCish model is definitely worse. A good alternative might be some visualization tools - something like the Class Designer: the service designer. If something is difficult don’t replace it with unfitting alternatives even if those are easier to grasp. It just doesn’t fit!

As Aaron Skonnard points out in his article the fact that nearly every tool on the market uses a Contract-First approach when building service consumers (clients) and a Code-First approach when building service providers is paradox (at least).

Posted by Hartmut Wilms at 22:13 | TrackBack

18.02.05

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

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

24.01.05

Generic Implementation Interface

Christian Weyer asks for additions to the WSCF wishlist. This made me think about parameter and return type handling in ASP.NET Web Services …

You can help us improve WSCF, now

Take a look here if you work with WSCF and just think: “well, it’s nice, but…”.
We want to hear your ‘but’. Thanks.

I haven’t had that much time to investigate WSCF 0.4, but I think the tool generates code in a single way, only, i.e. the way the tool (or the author) sees fit. It generates parameter classes which map to the types defined in the XSD file. Although this approach is recommended in many ASP.NET and Contract First forums, I think it is still one step from really being “losely coupled”. Why? Because your implementation is bound to the types in your service description/interface. If the interface changes chances are that you’ll have to change the implementation (of the client), too. This would destroy the most important reason for SOA being independence. Service-oriented architecture is all about reducing dependencies as much as possible.

In order to achieve this independence concerning parameters and return types the implementation should use XMLElement and XPath to access and deliver parameters, return types respectively. If the service changes (non-breaking changes!) and the client isn’t interested in the new additional features, it still would work, because all necessary data is fetched from the XML tree via XPath queries. This approach might seem odd, because C# is a strongly typed language and string queries aren’t really typed … But service description aren’t C# typed either. They are typed by the XSD/WSDL which should be the only service and data definition! There are some (few) sources for this approach:

I like to call this approach the “generic implementation interface”, because the implementation expects an “untyped” XMLNode, which is accessed in a generic way by XPath queries. The opposite is the concrete or typed implementation interface. Both approaches are valid. Sometimes it’s just more effective to generate typed parameters and the corresponding proxies. But in most cases the generic approach largely adds to the losely coupled idea. I still have to investigate how to implement this with ASP.NET Web Services. Maybe there are some serious drawbacks. The idea is to define the fully typed (XSD) WSDL and to use XMLElement or XMLNode parameters and return types in the implementation.

Therefore my most wanted WSCF feature is to make the generation process configurable, perhaps by introducing a template based approach. I know this is much asked for, but you asked, didn’t you ;-) ?

Posted by Hartmut Wilms at 10:51 | Comments (1)