Are bookshop ripping us off with eBook?

At the moment I am looking for a couple of technical books and since the fad these days are eBook, I am going to evaluate whether or not eBooks offer real advantages.

Remember, a physical book needs paper, inks, printing press to produce it, bookbinding to bind the pages, warehouse storage facilities and transportation. The costs associated with these processes are not insignificant.

eBook, on the other hand, does not require any one of those processes. In fact, it is rare to produce a physical book without electronic manuscript in one form or another that can readily be converted to eBook format, if not already done so. It is well known in electronic products - be it software or computer games - the reproduction cost is almost zero. I have left out the royalty to the author and merchant's profits. It is not unrealistic to assume that the royalty is the same between eBook and physical book. So any cost savings must be due to the above associated costs to reproduce the physical book.

Hence, eBook should be a lot lot cheaper than physical book. Not quite as the comparisons shown below demonstrate that it in fact has negative economic benefits. The tables below show the book prices without inclusion of handling and shipping cost.

Web Service Contract Design and Versioning for SOA

Bookshop	eBook Price	eBook Protection	Book Price	Savings	Used Price
Amazon	$28.79	DRM	$42.89	$14.1	$31.52
Barnes & Nobles	N/A	N/A	$43.99	$0.0	$33.99
infomIT	$39.59	Watermarked	$49.49	$9.9	N/A

SOA with .NET & Windows Azure: Realizing Service-Orientation with the Microsoft Platform

Bookshop	eBook Price	eBook Protection	Book Price	Savings	Used Price
Amazon	$35.19	DRM	$42.89	$7.7	$42.06
Barnes & Nobles	$43.99	DRM	$46.71	$2.72	$33.05
informIT	$39.59	Watermarked	$49.49	$9.9	N/A

The savings are not uniform and are from book to book, from bookshop to bookshop, ranging from a pittance of under $3 to $14.

Some physical book, despite all these expensive production & storage costs, is cheaper than eBook. Amazon's price for the second book is cheaper than Barnes & Nobles' eBook version. They must be more expensive 1's and 0's used by Barnes & Nobles than those inks and paper used by Amazon!

Now clearly someone is taking advantage of the latest fad to charge for something that cost zero dollar to produce and reproduce.

The above figures are just pure price comparison and now consider the real economic disadvantages of eBook:

1. For those using DRM, even the owner cannot print out a diagram or pages after all it is something you have paid for. At least you can run the physical book over on a photo copying machine or scanner. Does that pittance in savings enough to compensate for the lost of freedom to use the things you have bought?
2. Loss of second hand book market. While the above used book prices are indicative, nonetheless, there is a market for used copies and that you can participate without restriction. All eBooks bar you from that market and their form of compensation is only a pittance. Even allowing a discount of 50% for used copy, you can sell it for more than the saving you can get from eBook.
3. You can't even share part of the book or form a syndicate to buy a book. At least in a physical book, no one forbids you from tearing the book apart to share it. You can tear out pages to lend to others or to give it away. You have total freedom. But not so with eBook. Amazon generously allows you to have 6 devices but they need your access code to your account. Barnes & Nobles has this lend it facility for only 14 days.
4. No one can take the physical book away from you as long as you have paid for it. Not so with eBook. Even if the bookshop does not have any rights to sell a physical book, so long as you have paid for it and walked out of their doors, that book is yours and they can't take it away.
5. How soon does the eBook savings recoup the investment cost of a eBook reader? The only outlay for a physical book is your bookshelf cost if you want to store it that way. The floor is perfectly good free storage space for books.

I have to acknowledge that there are benefits with eBook that physical books are not capable of offering. Such as the ability to carry almost a library-ful of eBook with you,  enhanced searchability, or almost instantaneous delivery and with no delivery charges. Well Amazon does not charge delivery charges for purchase over certain amount to US address.

In my opinion, eBook merchants are definitely taking advantage of current hype and fad to over charge the customers and in my mind, it offers more restriction than physical book and preventing book owner from disposing them in a second hand market, which can return considerable amount to the owner.

In fact, it is not uncommon to find eBook costing more than its hardcover versions. The debate whether eBook should cost so much is raging on the Internet and no end in sight if consumers are willing to pay for the hype & fad.

Using WCF to produce Web Service Contract documents that must use a supplied schema

This post is to describe a very common scenario in SOA/Web Service world. To avoid chaos in SOA world, practitioners are encouraged to use "Standardization of Service Data Representation" so that services and clients are communicating using standardized or common vocabulary. They may be standards data representations specified within an enterprise or by trade groups like MIMOSA and are not necessary standard endorsed by W3C.

The problem at hand is to produce service contract documents that a system needs to interact with abstractly and the data interchanges must use a standardized or common representation. For ease of discussion, let's assumed the standardized data is from ACME Enterprise and supplied in schema file called ACMEEnterprise.xsd.

One way to do this is to use a process called Contract-First or Schema-First. This gives the designer the maximum control in what to put into the Service Contract. Service Contract, include WSDL and XSD, is not just for machine to execute but also containing information that are useful to service producers and consumers. However, it is not for the faint-hearted; it is only for the most determined soul.

Instead of using Contract-First, in this post, I am describing the necessary steps and settings of using WCF to generate Service Contract documents that use the prescribed data representation. In the frequently described scenarios, the developer is responsible for specifying the data and service contract. But in the problem at hand, much of the data representation or data contract, are predetermined.

Designing a Service Contract using WCF conforming to supplied data representation

As stated previously, the data representation is supplied in ACMEEnterprise.xsd and the targetNamespace is "http://ACMEEnterprise.org/2010/12/ACMEEnterprise.xsd". All data or message exchanges must use types specified in this schema file. The Service Contract many specify other data contracts it sees fit but if it is to describe data for ACME Enterprise, it must use the types specified in ACMEEnterprise.xsd.

Step 1 - Produce the .Net classes

The first step is to convert the types specified in the ACMEEnterprise.xsd into .Net classes that we can use in WCF constructs. For illustration purpose, I use C# but you can use any other .Net languages.

This can be achieved by using XSD.exe or SvcUtil.exe. Most WCF materials will recommend one to use SvcUtil.exe but if the schema is specified using the full set of W3C XSD Schema syntax, the chance that SvcUtil can process your schema file is slim. The reason is that SvcUtil is designed to work with DataContractSerializer which maps the CLR data types to XSD's or vice versa and that the Data Contract model only supports a limited subset of the W3C Schema specifications.

You have a better chance of successful conversion by using XSD.exe provided that you follow the caveat. What CLR namespace you choose to use is immaterial and is not something that will affect the wire format. They are local artifacts affecting only your .Net solutions.

Step 2 - Incorporate the generated file into your project

The next step is to incorporate the generated file into your project and begin using the types in that files to design your Service Contract as if you are dealing with normal WCF DataContract types.

The main thing to note is that each class generated is adored with the XmlTypeAttribute declaring the Namespace corresponding to the targetNamespace in ACME, like this:

[System.Xml.Serialization.XmlTypeAttribute
        (Namespace="http://ACMEEnterprise.org/2010/12/ACMEEnterprise.xsd")]
    [System.Xml.Serialization.XmlRootAttribute("employee",
          Namespace="http://ACMEEnterprise.org/2010/12/ACMEEnterprise.xsd", 
          IsNullable=false)]
    public partial class Employee : Person {
        // . . . 
    }

It is vitally important that this namespace is maintained when we generate the Service Contract documents for this type.

Step 3 - Mark the Service Contract with XmlSerializerFormatAttribute

This is a very important point. You may apply this attribute to only those Contract Operations that require to use XmlSerializer. In my case since every operation is using this serializer, I apply this attribute to the entire service contract. If you do not apply this attribute, types that came from ACMEEnterprise.xsd will be placed under the targetNamespace of "http://schemas.datacontract.org/2004/07/ACME.Enterprise" like this:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:tns="http://schemas.datacontract.org/2004/07/ACME.Enterprise" 
 elementFormDefault="qualified" 
 targetNamespace="http://schemas.datacontract.org/2004/07/ACME.Enterprise" 
 xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:complexType name="Person">
    <xs:sequence>
      <xs:element name="ageField" type="xs:int" />
      <xs:element name="firstNameField" nillable="true" type="xs:string" />
      <xs:element name="genderField" type="tns:Gender" />
      <xs:element name="hobbyField" nillable="true" type="xs:string" />
      <xs:element name="lastNameField" nillable="true" type="xs:string" />
      <xs:element name="secretNumberField" nillable="true" type="xs:long" />
    </xs:sequence>
  </xs:complexType>

This effective produces a different type on the wire. The use of XmlSerializerFormatAttribute retains the original targetNamespace.

Step 4 - Build the WCF Service Library and Generate the Contract documents

After you have finished building the WCF Service Library you can use SvcUtil.exe to produce the Service Contract documents. The process will generate the WSDL as well as the companion XSD files. While this process with the aid of XmlSerializerFormatAttribute preserves the targetNamespace, as shown below, for the types that are used in this service library and placing them in a XSD file resembling the original XSD file, the process is at best of low fidelity. That is the process loses information that are in the original documents deem not needed in WCF. Information such as <annotation>, <documentation>, and <restriction> elements are lost. The schema file only contains a subset of the types described in the original schema; it includes only types used in the service.

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:tns="http://ACMEEnterprise.org/2010/12/ACMEEnterprise.xsd" 
 elementFormDefault="qualified" 
 targetNamespace="http://ACMEEnterprise.org/2010/12/ACMEEnterprise.xsd" 
 xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:complexType name="Person">
    <xs:sequence>
      <xs:element minOccurs="0" maxOccurs="1" name="FirstName" type="xs:string" />
      <xs:element minOccurs="0" maxOccurs="1" name="LastName" type="xs:string" />
      <xs:element minOccurs="1" maxOccurs="1" name="Age" type="xs:int" />
      <xs:element minOccurs="1" maxOccurs="1" name="Gender" type="tns:Gender" />
      <xs:element minOccurs="1" maxOccurs="1" name="SecretNumber" nillable="true" type="xs:long" />
      <xs:element minOccurs="1" maxOccurs="1" name="Hobby" nillable="true" type="xs:string" />
    </xs:sequence>
  </xs:complexType>

You may replace the regenerated schema file for types for ACME Enterprise with the original one without problem so that it contains all the valuable information.

The process described here is a low fidelity process. It does not allow designer to include annotation in the WSDL file. The only way to create a full fidelity Service Contract is to use Contract-First process by authoring the messages and then the WSDL. This will be reported in full post.

---

"SOA Principle of Service Design" Section 6.3 "Types of Service Contract Standardization"

Caveat in using xsd.exe

Here is a trap that many can fall into when using xsd.exe:
1) If your xsd schema file uses <xsd:import> to add multiple schemas from different target namespace into the document, xsd ignores the schemaLocation attribute value.

In this case, you need to specify those imported xsd files on the command line.

2) If the document uses <xsd:include>, xsd uses the schemaLocation attribute value.

While it is great to use the latest and greatest but in many situation, particularly when you are given an XSD authored in other platform, SvcUtil.exe /dcOnly will frequently unable to handle XSD Schema syntax that XSD.exe can handle.

In that situation, alternately you can use the /importXmlTypes (/ixt) and ended up with types that implements IExtensibleDataObject, something that only existing in Microsoft world and may even impact on interoperability, certainly a J2EE Web Service does not have this.