Better xsd.exe

now, it supports property, collection, import and option not to generate codes for imported types. download.

for more info, check here.

Statement.xsd

<br /> <?xml version="1.0" encoding="utf-8" ?><br /> <xs:schema xmlns:tns="http://microsoft.com/practices/ConsolidatedAccountStatementResponse" elementFormDefault="qualified" targetNamespace=http://microsoft.com/practices/ConsolidatedAccountStatementResponse xmlns:xs="http://www.w3.org/2001/XMLSchema"><br /> <xs:annotation><br /> <xs:appinfo><br /> <code xmlns="http://weblogs.asp.net/cazzu" skipImportedType="true"><br /> <extension Type="XsdGenerator.Extensions.ArraysToCollectionsExtension, XsdGenerator.Library" /><br /> <extension Type="XsdGenerator.Extensions.FieldsToPropertiesExtension, XsdGenerator.Library" /><br /> </code><br /> </xs:appinfo><br /> </xs:annotation><br /> <xs:import namespace="http://microsoft.com/practices/CashAccount" schemaLocation="CashAccount.xsd" /><br /> <xs:element name="ConsolidatedAccountStatementResponse" type="tns:ConsolidatedAccountStatementResponse" /><br /> <xs:complexType name="ConsolidatedAccountStatementResponse"><br /> <xs:sequence><br /> <xs:element name="CashAccounts" xmlns="http://microsoft.com/practices/CashAccount" type="ArrayOfCashAccount" /><br /> </xs:sequence><br /> </xs:complexType><br /> </xs:schema><br />
CashAccount.xsd
<br /> <?xml version="1.0" encoding="utf-8" ?><br /> <xs:schema xmlns:tns="http://microsoft.com/practices/CashAccount" elementFormDefault="qualified" targetNamespace="http://microsoft.com/practices/CashAccount" xmlns:xs="http://www.w3.org/2001/XMLSchema"><br /> <xs:annotation><br /> <xs:appinfo><br /> <code xmlns="http://weblogs.asp.net/cazzu" skipImportedType="true"><br /> <extension Type="XsdGenerator.Extensions.ArraysToCollectionsExtension, XsdGenerator.Library" /><br /> <extension Type="XsdGenerator.Extensions.FieldsToPropertiesExtension, XsdGenerator.Library" /><br /> </code><br /> </xs:appinfo><br /> </xs:annotation><br /> <xs:complexType name="CashAccount"><br /> <xs:sequence><br /> <xs:element minOccurs="0" maxOccurs="1" name="AccountNumber" type="xs:string" /><br /> <xs:element minOccurs="1" maxOccurs="1" name="Contract" type="xs:int" /><br /> <xs:element minOccurs="1" maxOccurs="1" name="Balance" type="xs:decimal" /><br /> <xs:element minOccurs="0" maxOccurs="1" name="AccountType" type="xs:string" /><br /> </xs:sequence><br /> </xs:complexType><br /> <xs:complexType name="ArrayOfCashAccount"><br /> <xs:sequence><br /> <xs:element minOccurs="0" maxOccurs="unbounded" ref="tns:CashAccount" /><br /> </xs:sequence><br /> </xs:complexType><br /> <xs:element name="CashAccount" type="tns:CashAccount" /><br /> </xs:schema><br />
‘ Statement.vb

_
Public Class ConsolidatedAccountStatementResponse

Private _cashAccounts As CashAccountCollection


_
Public Property CashAccounts As CashAccountCollection
Get
Return Me._cashAccounts
End Get
Set
Me._cashAccounts = value
End Set
End Property
End Class
Public Class CashAccountCollection
Inherits System.Collections.CollectionBase

Public Default Property Item(ByVal idx As Integer) As CashAccount
Get
Return CType(MyBase.InnerList(idx),CashAccount)
End Get
Set
MyBase.InnerList(idx) = value
End Set
End Property

Public Function Add(ByVal value As CashAccount) As Integer
Return MyBase.InnerList.Add(value)
End Function
End Class

why did i choose to use typed dataset in web service?

pros

  • vs.net support on xsd and class generation via xsd.exe (drag and drop from data model to dataset plus some final touch)
  • existing data access framework support on mapping xsd to relational data and vise versa using data adapter (minimum coding required)
  • updategram that works well with the mappings defined in 2 (works really well for applications and no much coding required)
  • vs.net generated proxy works!
  • cons

  • locked in on .net (mitigation – provide alternative interface based on xsd for j2ee if required; there’s a way to transform typed dataset into a similar xsd and generate corresponding wsdl; however, it works best for readonly data since there’s no simple way to map the returned data back to relational data w/o writing additional codes )
  • increased data traffic due to schema being serialized (limit dataset usage to minimum; typed dataset for updatable data only)
  • in some cases, typed dataset is too vague or loose specially when there’re more than one table defined (this point is counter balanced by the no 2 in pros. gain something then lose something else …)
  • i ditched the idea of separating schema from dataset since it would require both ends to deal with schema anyway.
    i ditched the idea of not using dataset since it would require us to write tons of mapping code for relational data and updategram.

    everything works if designed and used properly. besides, everying around us is galaxy apart from soa world anyway.

    Web Services, XSD, WSDL and Versioning …

    I’m working on a web service providing user application authorization information based on web service. The basic idea is to expose application authorization data through a web service and remove any need to implement similar functionality in each application and centralize the administration of user profiles and authorizations.

    Like any other web services once deployed, all applications will be dependent on this basic user authorization services. It requires that the authorization service must offer backward compatibility and extensibility to support applications that live on their own life cyles.

    A versioning strategy is shown in the following:

  • All types are defined in XSD and their namespaces are date-stamped. Ex.,
    <s:schema

          xmlns:s=“http://www.w3.org/2001/XMLSchema”

          targetNamespace=“http://tempuri.org/2004/02/16/types/”

          xmlns=“http://tempuri.org/2004/02/16/types/”

        >

         <s:complexType name=“User”>

           <s:sequence>

                  <s:element name=“FirstName” type=“s:string”/>

                  <s:element name=“LastName” type=“s:string”/>

           </s:sequence>

         </s:complexType>

    </s:schema>
  • All WSDL are stored as files that reference the XSD for exposing types. Ex.,
    <definitions

        name=“UserAuthorizationService”

        targetNamespace=“http://tempuri.org/2004/02/16/UserAuthorizationService/”

        xmlns=“http://schemas.xmlsoap.org/wsdl/”

    >

        <import namespace=“http://tempuri.org/2004/02/16/types/”

         location=“UserAuthorization.xsd” />

        <types />

        <message />

       <portType />



       <!– concrete definitions –>

       <binding />

       <service />

    </definition>



  • When implementing web services, the binding is done with import of a particular WSDL such as http://localhost/2004/02/16/UserAuhtorizationService.wsdl, insetad of relying on ASP.NET auto-generated WSDL on an endpoint.
  • When the service interface changes, a new WSDL is created and a new endpoint is created as well for the new interface. Ex, these are two versions of the service with two distinct endpoints.
  • http://localhost/2004/02/16/UserAuthorizationService.wsdl and http://localhost/2004/02/16/UserAuthorization.asmx
  • http://localhost/2004/03/UserAuthorizationService.wsdl and http://localhost/2004/03/UserAuthorization.asmx
  • Here’re some related resources:
    Designing Application-Managed Authorization
    XML Versioning