title: Guaranteeing that a .NET WCF Service can be consumed by a Java client
body: <p>I am creating a WCF Service that will be consumed by both .NET and Java client applications.</p>
  
  <p>We do not have any Java experience in the team, so are looking for guidelines or rules to follow to ensure that we do not accidentally include any types in our WCF Service interface or do anything else that would preclude it from being consumed by a Java client application.</p>
  
  <p>Are our worries well-founded? If so, what should we be wary of?</p>
  
  <h2>Edit</h2>
  
  <p>One example of a concern is whether a .NET <code>DateTime</code> value is represented in the service interface in a manner that can be correctly understood by a Java client.</p>
  
  <h2>Edit2</h2>
  
  <p>A second example of a concern is the use of any nullable value types (<code>bool?</code>, <code>int?</code> etc).</p>
  
  <h2>Edit3</h2>
  
  <p>At present some of our development teams are hand-writing .xsd files to define the various objects that the WCF interface methods will take as arguments and return as return values. They are then using xsd.exe to auto-generate C# classes from these.</p>
  
  <p>The rationale behind this is that it guarantees that the generated classes won't contain anything that is .NET-specific.</p>
  
  <p>The downside is that this adds a development burden and also precludes us from documenting these classes using <code>&lt;summary&gt;</code> tags (.NET equivalent of javadoc comments).</p>