Christian Weyer shows off the few lines of pretty straightforward WCF code & config he needed to figure out in order to set up a duplex conversation through BizTalk Services.

Categories: Architecture | SOA | BizTalk | WCF | Web Services | XML

April 3, 2006
@ 03:39 PM

Mark, I care deeply about the hobbyist who writes some code on the side, the programmer who works from 9-5 and has a life and just as deeply about those who work 24/7 and about everybody in between ;-)

That said: now that we're getting close to being done with the "this vs. that" debate, we can most certainly figure out the "how can we optimize the programming experience" story. For very many people I've talked to in the past 4 years or so, reducing complexity is an important thing. I firmly believe that we can do enterprise messaging and Web-Style/Lo-REST/POX with a single technology stack that scales up and down in terms of its capabilities.  

Since I take that you are worried about code-bloat on the app-level, how would you think about the following client-side one-liners?

  • T data = Pox.Get<T>("myCfg")
  • T data = Pox.Get<T>("myCfg", new Uri("/customer/8929", UriKind.Relative));
  • T data = Pox.Get<T>("myCfg", new Uri("http: //example.com/customer/8929"));
  • T data = Pox.Get<T>(new Uri("http: //example.com/customer/8929"));
  • U reply = Pox.Put<T,U>( new Uri("http: //example.com/customer/8929"), data, ref location));
  • U reply = Pox.Post<T,U>( new Uri("http: //example.com/customer/"), data, out location));
  • Pox.Delete(settings, new Uri("http: //example.com/customer/8929"));

Whereby "myCfg" refers to a set of config to specify security, proxies, and so forth; settings would refer to an in-memory object with the same reusable info. Our stack lets me code that sort of developer experience in a quite straightforward fashion and I can throw SOAPish WS-Transfer under it and make the call flow on a reliable, routed TCP session with binary encoding without changing the least bit.

If I am still missing your point in terms of ease of use and line count, make a wish, Mark. :-)

Categories: Indigo | Web Services | XML

Joe McKendrick at ZDNet cites Joel Spolsky and his "Web 2.0" rant.

What is particularly interesting about this new hype-term that this is the first technology term that describes nothing at all about technology. It rather seems to describe that a suffiently large, critical mass of people has grasped a sufficiently broad set of technologies (most of which have been available for the past 4-5 years) for DHTML and XML to actually go mainstream. And clearly contributing to that is (even though everybody seems to complain mostly about IE and its gaps in standards support) that Mozilla seems to have managed to clear the dreaded Netscape 4 garbage off the net.

AJAX is the same buzzword b/s. I am currently building an AJAX app, yay! In order to remember a few things and how they worked, I dug in code dating a few years back that sits in my "OldStuff" directory. Innovation!

And VCs going crazy about this is something that absolutely shocks me.

Categories: XML

December 15, 2004
@ 12:37 PM

Just had to figure this out and thought I’d share. With the XmlSerializer (.NET v1.1), one would think that TimeSpan maps to the XML Schema type duration, but it doesn’t – for whatever reason. Anyways … here’s a trick to make it work. Interestingly enough, the XmlConvert class understands TimeSpan. However it does not work correctly with fractional seconds and ignores them. That’s enough for my purposes in the given app and therefore I am ignoring that issue in the snippet below and treat all times of less than one second as equivalent to zero. If it isn’t enough for you, you’d have to write an alternate implementation for the respective XmlConvert functionality or beg Microsoft to fix it. (Doug? ;-)

 

private TimeSpan interval;

[XmlElement("Interval", DataType="duration")]
public string IntervalXml
{
    get
    {
        if (Interval < TimeSpan.FromSeconds(1) )
        {
            return null;
        }
        else
        {
            return XmlConvert.ToString(interval);
        }
    }
    set
    {
        if (value == null )
        {
            interval = TimeSpan.Zero;
            return;
        }
        TimeSpan newInterval = XmlConvert.ToTimeSpan(value);
        if (interval == newInterval)
            return;
        interval = newInterval;
    }
}

[XmlIgnore]
public TimeSpan Interval
{
    get
    {
        return interval;
    }
    set
    {
        if (interval == value)
            return;
        interval = value;
    }
}

 

 

Categories: XML

December 5, 2004
@ 02:33 PM

"My Lists", "My Photos", "My Profile" .... sounds all very familiar over there in MSN Spaces. So ... roll in the Web service interfaces, please.

Categories: Web Services | Weblogs | XML

August 20, 2003
@ 01:43 PM

While I wasn't looking, Doug Purdy, who is the PM for the team in charge of the XmlSerializer has posted this little cryptic answer to my initial question:

String serializedDateTime = XmlConvert.ToString( someDateTime );

DateTime deserializedDateTime = XmlConvert.ToDateTime( serializedDateTime );

What Doug is showing is really what the serializer is doing with dates under the hood and that I am incorrectly blaming the XmlSerializer for the lack of UTC support. [XmlConvert.ToString() also does nothing more than calling DateTime.ToString() with the appropriate format string]. As I was already saying in yesterday's post, but what I want to make a bit clearer here again is that the actual problem is the lack of time-zone awareness in DateTime.

So the proper thing more me to do is to ask the base-class library team for time-zone support in the base-class library for Whidbey so that Doug can fix this for us ;)

Categories: XML | CLR

August 19, 2003
@ 06:41 PM

I posted a little question here, just asking "Why?". For your reading convenience, I pull the code in here once more:

DateTime issued;

[XmlIgnore]
public DateTime IssuedUtc
{ get { return issued; } set { issued = value; } }

[XmlElement("issued")]
public DateTime IssuedLocalTime
{ get { return Issued.ToLocalTime(); } set { Issued = value.ToUniversalTime(); } }

So, indeed, why am I doing this? Well, when I decided to normalize all times handled by the backend engine of dasBlog into the UTC timezone, I really didn't think of the XML Serializer being a problem at first. It turned out to be one.

The reason why I wanted all times to be handled internally as UTC is quite simple: Too many time zones to deal with and I need to have a proper reference to do forward and backward time calculations. dasBlog deals with four time-zones:

  • "Reader Time": The "<%userWhen%> macro emits a block of script that will cause the browser to emit the time of a post local to the reader's time zone. That one is easy, because the calculation happens on the client, but I need to feed it UTC (GMT).
  • "Display Time": This is the time zone the blog owner selects for his/her blog. All times displayed on the weblog pages are shown in that time zone (complete with the TZ name and the GMT offset). This also applies to the "admin pages" such as referrals and events (which both roll over in synch with the display time zone). Display time is calculated dynamically and you will notice that it also automatically adjusts for daylight savings time. The display time zone is also by no means fixed. If the blog author travels (and you will see this on my blog starting next week), he/she can adjust the blog to his/her present time zone. When I am going to be at TechEd Malaysia, my blog will show UTC+0800. To make this time-zone shifting work, the absolute time must be stored in UTC.
  • "Engine Time": This is UTC. All of the dasBlog runtime handles everything in UTC.
  • "Server Time": Now were getting to the point. The engine runs on a server that has it's own local time zone setting: "server local time". That's something that the user who's running his engine at some ISP can't control and that's the one of all the time zones that really nobody is ever interested in. You shouldn't care whether your blog is hosted in Germany, the U.S. East Coast or Singapore. That's even more of an issue because one could expect that hosted sites may get moved around between ISP locations. The only little thing we're interested in is that the server knows its offset to UTC.

So ... I was thinking.... ask for DateTime.Now.ToUniversalTime(), handle everything in UTC from there on and everything's good. (Btw, I know about DateTime.UtcNow, but I like the expressiveness of this better).

What I wasn't considering is the way the XmlSerializer works, which I am using both for storage and for the various web services (including the Atom feed). What I also found is that the DateTime class in the framework isn't time-zone aware.

The workaround above is used because the XML Serialization infrastructure always assumes local time ("Server time") for serialization and will always emit ISO 8601 dates with a time-zone suffix like this: 2003-08-19T15:15:58.0781250+02:00. So when you are handling UTC times internally and use them blindly with XML serialization for both storage and web services, the serializer will assume you are using local time and throw you off by your own time-zone difference to UTC.

This isn't "too bad" when you store stuff in local XML files, because when you write something wrong from the same place you read it back into and your time-zones don't change you are in ok in memory, but you are nevertheless wrong on disk. What happened to me in dasBlog version 1.1 was that I was thinking that I stored UTC, but in fact I stored everything in local time. My UTC time 2003-08-19T15:15:58 always turned into 2003-08-19T15:15:58+02:00, because the DateTime class doesn't keep time-zone information around that the serializer could use. Therefore the serializer must always assume local time and that causes the offset to be emitted. That's of course much worse for UTC+12.

The fix:

The field  DateTime issued; holds the "engine time", which is always UTC. 

The property

[XmlIgnore]
public DateTime IssuedUtc
{ get { return issued; } set { issued = value; } }

wraps this value and is the property that the engine works with internally. The XmlSerializer is instructed to ignore this value in the serialization process by declaration of the [XmlIgnore] attribute. Instead, we tell the serializer to look at the following property, which is not used by the engine itself and also indicates that by its name suffix "LocalTime", which essentially declares it as "off limits" for direct access to everyone knowing the project:


[XmlElement("issued")]
public DateTime IssuedLocalTime
{ get { return Issued.ToLocalTime(); } set { Issued = value.ToUniversalTime(); } }

This property is the one that the serializer grabs and it does the proper conversion to and from server local time that the serializer requires. The actual dasBlog code is using a variant of this property that is a bit larger in code size because it also checks for DateTime.MinValue and DateTime.MaxValue occurrences, which, depending on the server time zone, would cause the time zone shifting to fail with an overflow/underflow exception (and no, I am not checking near MinValue and MaxValue):

[XmlElement("Date")]
public DateTime DateLocalTime
{
   
get
    {
      
return (DateUtc==DateTime.MinValue||DateUtc==DateTime.MaxValue)?
               DateUtc:DateUtc.ToLocalTime();
    }
   
set
    {
        DateUtc = (
value==DateTime.MinValue||value==DateTime.MaxValue)?
                  value
:value.Date.ToUniversalTime();
    }
}

So, that's why.

Be aware that all of this applies to ASP.NET Web Services, too, and if you are dealing with multiple time zones are you are using UTC normalized times in your app, you will have to deal with this. If "server time" makes you happy, you won't need to worry.

Categories: XML | CLR

August 14, 2003
@ 05:51 PM

DateTime issued;

[XmlIgnore]
public DateTime IssuedUtc
{ get { return issued; } set { issued = value; } }

[XmlElement("issued")]
public DateTime IssuedLocalTime
{ get { return Issued.ToLocalTime(); } set { Issued = value.ToUniversalTime(); } }

 

Why?

Categories: XML | CLR

Dan Farino, who wrote the CLR based, Regex extended stored procedure on which I put a warning sign yesterday, wrote me an email back (I notified him that I wrote that blog entry) and told me that he just uploaded an unmanaged version. Haven't downloaded it, yet, but it seems to be functionally equivalent. If it's stable and quick, I can think of 2 bazillon uses for this -- including, of course, Regex based XML parsing inside SQL Server (while we wait for Yukon).

Categories: CLR | Technology | XML

August 10, 2003
@ 07:21 AM

Tim Bray, author of the Namespace spec, enlightens us here that I am technically wrong by using the term "empty namespace". Yes. Absolutely. But the "not member of any namespace" vs. "member of the empty namespace" distinction becomes meaningless once you start coding against an XML infrastructure, because in the programming models, there is pretty much always a namespace qualifier. In the .NET Framework, for instance, the NamespaceURI is an empty string in such cases (... and it should really be null).

Categories: Technology | XML

Jon Udell writes in his most recent column that some think that there is a "controversy" about the use of XML namespaces. This seems to stem from the sad fact that RSS never got a proper namespace assigned to it and is one of the hottest schemas specs in the XML space right now. Sorry, there may people in disbelief, but the XML Namespaces spec is normative and referenced in the current XML 1.0 (Second Edition) spec. The empty namespace is a namespace.

Some notable experts — including Sean McGrath, CTO of Propylon in Dublin, Ireland — argue that namespaces should be avoided for that reason.

You can't avoid namespaces, they are automatic if you use XML today. If you don't declare one for your vocabulary/schema, you are contributing to a large cloud of "stuff" sitting in the "not part of any" namespace. The "empty" namespace (which essentially says "not part of any namespace") is the XML equivalent of a the "these are just some tags" garbage dump.

Categories: Web Services | Technology | XML