Put the knife down and take a green herb, dude. (c) Ruffin Bailey 2001-2021

Get Kingsoft Office Professional 2013 (Win) free | The Cheapskate - CNET News:

al_chirico

@Cool_Daddy For me, I like being able to actually read the data file. The xxxX formated files are XML files. So, If you know XML or HTML, you can just search the file for something you're looking for. This is especially helpful if you're passing a xxxX file to another program. You can just deconstruct the file as input data. Try doing that with an earlier xxx file. Just my 2 cents.

I read through this comment that's essentially in favor of the use of Microsoft's "Office Open XML" file formats and came away with an unexpected take-home. First, why should we care how hard it is to open a .doc file in a text editor at this point? We have plenty of excellent, freeware applications that can do that job for us (AbiWord, though seemingly dead, is still one of my favorites). There's no real practical advantage for having a .doc file in a human readable file format now, is there, minus outliers like, "I just installed my OS and have no internet access and MUST edit the contents of my file in the 'pack-in' text editor!"

But then I shift from the consumer's pov to Microsoft's. If the long game says that proprietary file formats will be broken and provide no (again, long-term) advantage, why bother with them at all? Why not just use XML for your file format? The format's so complex at this point, the degree of obfuscation in XML versions of the files is still tremendous. You're past the point of something simply reproduced -- heck, even MS's Mac Business Unit had a heck of a time pulling it off, and that was an inside job! It's the difference between html made by Seamonkey Composer and html made by Word's "Save As HTML". HTML is supposed to be a nice, human-editable format. Yet one product is pretty easy to edit by hand, and the other nearly impossible. (See also AbiWord's Save As HTML for docs; beautiful stuff.)

So why move from bytecode to XML if you're Microsoft? XML might be a better tool for serializing docs, and puts contracts with governments that demand "free and open" (and therefore, ostensibly, forward compatible and archival) formats back on the table and kill the "open" movement flat.

And there's really no difference to the end user now either, minus those guys who post to CNET and claim to be opening/editing their docs in Notepad. ;^)

Microsoft moving to XML seems better, but, in the end, holds the status quo. (C#'s release as an open standard, however, had much different, more beneficial results. Wonder if that was expected?)

Labels: microsoft, ooxml, open, xml

The most annoying thing about setting up a WCF is the number of things that seem to work in the local testing server that'll explode in IIS. The local testing server that you can invoke with F5 is very lenient.

But before we get into the complicated stuff, a quick list of System-Provided Bindings from Microsoft:

WSHttpBinding
A secure and interoperable binding that is suitable for non-duplex service contracts.
BasicHttpBinding
A binding that is suitable for communicating with WS-Basic Profile conformant Web services, for example, ASP.NET Web services (ASMX)-based services. This binding uses HTTP as the transport and text/XML as the default message encoding.
WebHttpBinding
A binding used to configure endpoints for WCF Web services that are exposed through HTTP requests instead of SOAP messages.

Fair warning: I've done this three or four times now to make sure things work, but I haven't started from scratch on a new machine to run through the steps as I present them, here. Could be wonky somewhere. YMMV.

So let's start a WCF Service project. You select File >>> New Web Site >>>WCF Service. Save the new project in IIS's root folder.

That'll create a project with the file structure seen below:

Looking in Web.config, you'll see that, by default, this project has two endpoints. One is the MEX endpoint, which is nice, but not really the business end of things. The other is a wsHttpBinding. That's important, because, as we learned above, that expects to be called from a SOAP-compliant client.

If you try hitting F5 off the bat, it'll seemingly work, first going to a URL like this one:
http://localhost:50319/WCFService1/Service.svc

But if you try to view the GetData method, which is one of the two IService methods that Service.cs implemented by default, using a URL like this one:
http://localhost:50319/WCFService1/Service.svc/GetData

... you get no response, just a 400 error.

So it's worth saying that it's odd to have a SOAP client in my line of programming. You'd usually rather send out a very simple AJAX request to a URL from a web page to the WCF and receive some JSON back to parse in Javascript. The take-home is that we need to remove the wsHttpBinding (set up for SOAP) and set up webHttpBinding (ready for REST) instead.

The endpoints that Visual Studio inserts into web.config by default are below:

<endpoint address="" 
        binding="wsHttpBinding" contract="IService">
        <!-- 
                Upon deployment, the following identity element should be
                removed or replaced to reflect the identity under which the
                deployed service runs.  If removed, WCF will infer an
                appropriate identity automatically.
        -->
        <identity>
                <dns value="localhost"/>
        </identity>
</endpoint>

Our next step is to change that wsHttpBinding endpoint to one with webHttpBinding. I've also inserted the additional overhead of adding a JsonBehavior. Honestly, not sure what that's doing yet, but I think I want it.

<system.serviceModel>
        <!-- serviceHostingEnvironment aspNetCompatibilityEnabled="true" / -->

        <serviceHostingEnvironment aspNetCompatibilityEnabled="false" />
        <behaviors>
                <serviceBehaviors>
                        <behavior name="ServiceBehavior">
                                <!-- To avoid disclosing metadata information, set
                                        the value below to false and remove the
                                        metadata endpoint above before deployment
                                -->
                                <serviceMetadata httpGetEnabled="true"/>
                                <!-- To receive exception details in faults for
                                        debugging purposes, set the value below to
                                        true.  Set to false before deployment to avoid
                                        disclosing exception information 
                                -->
                                <serviceDebug includeExceptionDetailInFaults="false"/>
                        </behavior>
                </serviceBehaviors>
                <endpointBehaviors>
                        <behavior name="JsonBehavior">
                                <webHttp />
                        </behavior>
                </endpointBehaviors>
        </behaviors>

        <services>
                <service name="Service" behaviorConfiguration="ServiceBehavior">
                        <endpoint address="" binding="webHttpBinding" 
                                behaviorConfiguration="JsonBehavior" contract="IService">
                                
                                <!-- original:
                                endpoint address="" 
                                binding="wsHttpBinding" contract="IService" -->

                                <!-- 
                                        Upon deployment, the following identity
                                        element should be removed or replaced
                                        to reflect the identity under which the
                                        deployed service runs.  If removed, WCF
                                        will infer an appropriate identity
                                        automatically.
                                -->
                                <identity>
                                        <dns value="localhost" />
                                </identity>
                        </endpoint>
                        <endpoint address="mex" 
                                binding="mexHttpBinding" 
                                contract="IMetadataExchange" />
                </service>
        </services>
</system.serviceModel>

(In case I've screwed up, the entire config is here.)

Again, switching from wsHttpBinding to webHttpBinding makes it so that we can use a URL to access the method. With wsHttpBinding, you'd have to have a SOAP client, which involves insane amounts of overhead for most of my applications.

There's more required than that, however. If you've got the same standard setup as I get in VS 2010, you've got two methods in the Service.cs file. One is pretty easy to set up to listen to query strings for its parameters;

[OperationContract]
[WebGet(RequestFormat = WebMessageFormat.Json, 
        ResponseFormat = WebMessageFormat.Json, 
        BodyStyle = WebMessageBodyStyle.WrappedRequest)]
string GetData(int value);

Now, you should be able to nav to GetData and slap in a param of "?value=1231" and have that number repeat back to you with a URL like this:
http://localhost:50319/WCFService1/Service.svc/GetData?value=10

You'll see "You entered: 10" (with quotes) in the web page.

You can also leave the port off if you followed the instructions and created the dir in IIS' home dir and created the application using Internet Information Server (IIS) Manager. Go to your default web site, find your server's folder, right click, convert to application, and voila:

Unfortunately, the other method in the default project (GetDataUsingDataContract) is more complicated, as if you try to turn it into a GET-able method, your WCF Service will complain about the CompositeType hand-rolled datatype that's also part of the project VS 2010 dreams up for you.

[OperationContract] CompositeType GetDataUsingDataContract(CompositeType composite);
You can't webget that because CompositeType isn't serializable.

Operation 'GetDataUsingDataContract' in contract 'IService' has a query variable named 'composite' of type 'CompositeType', but type 'CompositeType' is not convertible by 'QueryStringConverter'. Variables for UriTemplate query values must have types that can be converted by 'QueryStringConverter'.

Whoops. I'm not going to go into serializing to JSON right now. All things considered, that's an easy afterthought after this XML config wading.

So perhaps not the best composed, but that's today's lesson.

(A decent walkthrough of a slightly different way to go about this here.)

Labels: c#, code, wcf, xml

private static BigInteger readFibonacciXMLRPCResponse(
InputStream in) throws IOException, NumberFormatException,
StringIndexOutOfBoundsException {

StringBuffer sb = new StringBuffer();
Reader reader = new InputStreamReader(in, "UTF-8");
int c;
while ((c = in.read()) != -1) sb.append((char) c);

String document = sb.toString();
String startTag = "";
String endTag = "";
int start = document.indexOf(startTag) + startTag.length();
int end = document.indexOf(endTag);
String result = document.substring(start, end);
return new BigInteger(result);

}