Home > Development > Schema First

Schema First

Traditionally, contract-first to us WCF developers meant a .NET interface.  This is a bit silly because In the word of SOAP messages, your recipient more than likely won’t give a toss for your .NET interface because they will never see it; rather it is the SOAP XML message that pops out the other end of your comms conduit.

For this reason, many feel you should Schema First your primitives and message types in XSD and auto-gen the following:

  • WSDL
  • .NET WCF interfaces
  • .NET WCF service stubs
  • .NET classes for your primitives (e.g. Person, Order, GolliWog)

…from the original XSD.

That way when you need to interop with a third party they can adhere to your XSD or you can find a middle ground via XSLT.

More info can be found here

Advertisements
Categories: Development Tags: , ,
  1. Craig D
    2011/03/04 at 8:43 pm

    It’ all sounds great till someone gets hurt, and it’s usually the .NET developer 😉

    Serialized Data Contracts are more limited than WSDL, if you develop WSDL first you can create structures that do not Serialize and you’re stuck editing generated files or working with XML literals.

    If you are creating the interfaces yourself using ServiceContracts and generating the WSDLs is far less time consuming and results in a neater solution.

    Like

    • MickyD
      2011/03/05 at 7:41 am

      not so, many times in the past i was annoyed at the countless stuff that would not serialize and that was with code-first not XSD-first. besides at the XSD schema level it wont happen because you define your types in XSD as well so i doubt that will happen.

      take a look at the benefits of canonical protocol and canonical schema. at this level, .NET and its “contracts” are an implementation issue that SOAP clients wont give a toss about. the xmlserializer is recommended over DataContractSerializer due to its ability to serialize more industry types. besides if you focus on the code aspect youll find that you will fail to interop properly with your SOAP customer.

      just because something is easier does not necessarily imply its the right way to go about it. take databases for example, you cant beat the simplicity of a direct database connection and SQL-in-your-app but we all know enterprise-level development will suffer due to scalability and tight-coupling issues. such type of development is immature. far better to use stored procedures together with an encapsulation layer. sure its a little harder but the evidence shows it pays off. by the same token, SOAP-dev should be done XSD schema first.

      .NET interfaces are an implementation issue and are not the “contract” as we were lead to believe. in .net the WSDL is generated after the fact which is just dumb.

      but dont take my word for it, read the guru thomas erl and his countless books on SOA.

      or this MSDN Mag article
      http://msdn.microsoft.com/en-us/magazine/ee335699.aspx

      you have to remember that .net developers dont own SOAP and like many things we’ve been sadly taught to do things backwards while everyone else say in the java community have been doing it right for years.

      i suspect it is because they dont have some silly wizard doing it the wrong way for them.

      Like

  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: