Printer Services Mail Archive: PS> PSI WSDL Interface Specif

PS> PSI WSDL Interface Specification - To strongly type or not?

From: HALL,DAVID (HP-Vancouver,ex1) (dhall@hp.com)
Date: Tue Oct 22 2002 - 13:55:45 EDT

  • Next message: HALL,DAVID (HP-Vancouver,ex1): "RE: PS> PSI WSDL Interface Specification - To strongly type or no t?"

    Hey All...
    We currently have our parameters in PSI defined mostly as Strings,
    (jobProcessingAttributes for example), and are relying on the PWG SM schemas
    to provide the strong typing for the structure that the string contains..
    One option is to strongly type the parameters as a complex type rather than
    a string... I hate to open up this can of worms, but... So far, I've heard
    of 3 different approaches for this...
    I've tried to summarize the advantages / disadvantages for each of the
    approaches. Please add your thoughts to the discussion..
    Dave

    Strongly Typed WSDL Parameters Discussion
    One of the discussions that has been going on is around our WSDL definition
    of the PSI interfaces. There are three possibilities that have presented
    themselves:
    1) The parameters (for example, jobProcessingAttributes) should be encoded
    as a string defined by a schema. Extensions are added within the XML
    document...
    2) The parameters should be encoded as a strongly typed complex type,
    extensions are added as new, vendor defined elements.
    3) The parameters should be encoded as a strongly typed complex type, where
    the last parameter is a string[] of structures.
    There are a number of advantages and dis-advantages to each which I have
    tried to capture here:
    1) String parameters defined by schema:
    This is the current model for the PSI interface specification..
    Advantages:
            * Easily (understandably) extensible at the element level by
    the application.
            * Clients can code up only the elements that they wish to deal
    with.
            * Allows name-space extensions to the interfaces through the
    QueryEndPoints mechanism. (ie, give me the JobControlInterface that
    understands the pwg common semantic model, and give me the
    JobControlInterface that understands the Digital Imaging semantic model.)
            * Interoperability between toolkits. The simple types are
    readily encoded / decoded by the toolkits.
            * A 1.0 server (think existing printer that talks 1.0 psi)
    would be able to interpret a 2.0 clients request. (Assuming the method
    signatures didn't change - it would simply ignore the elements it did not
    understand.)
            * A 2.0 server (Think new print service) could interpret a 1.0
    client request (Assuming no new mandatory elements were added...)
            * A reference to the schema that defines the parameters can
    simply be made in the interface documentation.
    Disadvantages:
            * We need to hand generate the serializers / deserializers
            * Interoperability between devices is not enforced by a
    strongly typed interface.
    2) Complex type parameters
    Advantages:
            * Serializers and de-serializers generated by toolkits
    automatically.
            * Interoperability between devices is more enforced by the
    strongly typed interface.
            * Aligns with UPnP direction
    Disadvantages:
            * How to deal with the #any extensions in the toolkits?
    (Thought is that you inherit from the toolkit generated serializer, and add
    extensibility yourself)
            * Toolkit incompatibilities (Thought to be somewhat mitigated
    at this point.)
            * A 2.0 client would not be able to talk to a 1.0 server, the
    burden would be on the client to also be able to talk the 1.0 interface
    specification.
    3) Complex type parameters with string[] of structures element at the end
    Advantages:
            * Serializers and de-serializers generated by toolkits
    automatically.
            * Interoperability between devices is more enforced by the
    strongly typed interface.
    Disadvantages:
            * Toolkit incompatibilities - structures within structures
    have been problematic in the past. (Thought to be somewhat mitigated at
    this point.)
            * A 2.0 client would not be able to talk to a 1.0 server
    (assuming new elements are added to the base definition), the burden would
    be on the client to also be able to talk the 1.0 interface specification.



    This archive was generated by hypermail 2b29 : Tue Oct 22 2002 - 13:55:50 EDT