Tuesday, October 23, 2012

Frameworkitis and False Enterprisey Security: WS-Security and signing.



http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked.aspx

Who wears a motorcycle helmet indoors? Just because it's a simple analogy doesn't mean it's right.

This is still rampant frameworkitis. HTTPS isn't good enough! What happens if something is done after the message reaches it's point?

Oh, you mean the fucking ENDpoint?

99% of SOAP bloat systems (aka, licensed application servers configured and installed by consultants) IMMEDIATELY deserialize a SOAP message to a datastructure, and from there that data structure will be mangled by database call or MQ message or whatever.

Notice the uselessness of message signing. It's a false security blanket sold to stupid fucking executives. The data will be plaintext in a host of different settings post-parse: SQL requests, followup messages. That requires either good internal data practices or specifically tailored security architecture.

READ: less than 1% of cases, and outside the concerns of SOAP, which is a messaging protocol, not a transport protocol.

It's frameworkitis and enterprisy. Let's add a bunch of stuff that isn't the concern, bloat, bloat, bloat, million dollar license, buy a ferrari.

Fucking software companies. 

Friday, October 5, 2012

A little Spring XML to JSON conversion experiment...

What might some random Spring config (in this case a Spring-batch example) look like if JSON were the configuration/injection message format? What is good, what is bad?

 <bean id="taskletJob" parent="simpleJob">  
   <property name="steps">  
     <list>  
       <bean id="deleteFilesInDir" parent="taskletStep">  
         <property name="tasklet">  
           <bean  
       class="org.springframework.batch.sample.tasklet.FileDeletingTasklet">  
             <property name="directoryResource"  
               ref="directory" />  
           </bean>  
         </property>  
       </bean>  
       <bean id="executeSystemCommand" parent="taskletStep">  
         <property name="tasklet">  
           <bean  
       class="org.springframework.batch.sample.common.SystemCommandTasklet">  
             <property name="command" value="echo hello" />  
             <!-- 5 second timeout for the command to complete -->  
             <property name="timeout" value="5000" />  
           </bean>  
         </property>  
       </bean>  
     </list>  
   </property>  
 </bean>  
 <bean id="directory"  
   class="org.springframework.core.io.FileSystemResource">  
   <constructor-arg value="target/test-outputs/test-dir" />  
 </bean>  



My swing at JSON, using JSON-ish features and advantages (lists, maps/objects, etc)

 {  
   "taskletjob":  
     {"#t":"BEAN", "id":"taskletJob", "parent": "simpleJob",  
     "properties": {   
       "steps": [  
         {"#t": "BEAN",  
          "id":"deleteFilesInDir",   
          "parent":"taskletStep",  
          "properties":  
           {"tasklet":  
             {"#t":"BEAN", "class":"org.springframework.batch.sample.tasklet.FileDeletingTasklet",  
              "properties": {"directoryResource" : {"#ref":"directory"}}  
             }  
           }  
         },  
         {"#t": "BEAN",  
          "id":"executeSystemCommand",   
          "parent":"taskletStep",  
          "properties":  
           {"tasklet":  
             {"#t":"BEAN", "class":"org.springframework.batch.sample.common.SystemCommandTasklet",  
              "properties": { "command": "echo hello", "timeout": 5000}  
             }  
           }  
         }  
        ]  
       }  
     },  
   "directory": {  
     "#t":"BEAN", "id":"directory",   
     "class":"org.springframework.core.io.FileSystemResource",   
     "constructor-args": ["target/test-outputs/test-dir"]  
   }    
 }  

So what I found out:

Size in LOC was mostly identical. No real big savings there.
Spring utilizes namespaces implicitly or explicitly... No real JSON mechanism, so I invented the "#t" which is supposed to indicate the object type if it is typed, to give guidance to some parser/bean construction code as to required fields, etc.

In other places, like properties, the JSON object is used more as a map, since it is more intuitive that way. The JSON format here seems much more natural, and seem to save lots of keystrokes. I mean would you rather type:


<property name="command" value="echo hello" />
<property name="timeout" value="5000" />

or

"properties": { "command": "echo hello", "timeout": 5000}

Clear win for the JSON there.

However, JSON has some weird corner cases in formatting, such as arrays of objects. How do you render that without wasting extra tabs or lines? Granted, the <list> construct in spring xml wastes a tab and a line...

And all the double-quotes in JSON. Annoying. Not as annoying as xml ending tags. And why are commas even needed?

Other JSON problems: Getting lost in curly-brace land. WHile annoying verbose, at least closing tags in XML let you see what's being ended/closed. But considering most modern editors have curly brace features for C and Java code, this isn't a huge deal.

But if I had my druthers with a variation on JSON, where you don't need double-quotes on the object keys, values are optional, and drop the commas, why can't JSON be this?

 {  
   taskletjob:  
     {#BEAN id:"taskletJob"   
     parent: "simpleJob"  
     properties: {   
       steps: [  
         {#BEAN" id:"deleteFilesInDir"  
          parent:"taskletStep"  
          properties  
           {tasklet:  
             {#BEAN class:"org.springframework.batch.sample.tasklet.FileDeletingTasklet"  
              properties: {"directoryResource" : {"#ref":"directory"}}  
             }  
           }  
         }  
         {#BEAN id:"executeSystemCommand"  
          parent:"taskletStep"  
          properties:  
           {tasklet:  
             {#BEAN "class":"org.springframework.batch.sample.common.SystemCommandTasklet"  
              properties: { command: "echo hello" timeout: 5000}  
             }  
           }  
         }  
        ]  
       }  
     }  
   directory: {  
     #BEAN id:"directory" class:"org.springframework.core.io.FileSystemResource"  
     constructor-args: ["target/test-outputs/test-dir"]  
   }    
 }  

... Not a huge difference, but it would make reorganizing and moving object chunks around without worrying about breaking the commas in a list, or the fields inside an object. I think the parser would be about the same, no impacts to speed. But JSON the format spec, that ship has sailed... Maybe it looks too much like S-expr...

Friday, May 11, 2012

Oracle WINS!!!!.... what?

So Oracle has won... something.

I'm scared that Google has won this with a spectacular Oracle pyrrhic victory. But we as software developers may be losing in a big way.

If Oracle gets to copyright a basic rangecheck function, things are going to get really annoying.

I wish I could talk to a copyright judge and make this argument:

"Can you copyright the word 'is'?" (I assume no)

"Can you copyright the words 'greater than'?" (again I assume no)

"Can you copyright the words 'greater than this but less than that'?" (again I assume no)

And really, right there, you have pseudocode for rangecheck. For the java version, well, basically, you're just with a dialect translations: "Can you copyright the words 'superieure a cette mais inferieure a celle'?" (French google translate, and again I assume no).

I mean, it's not even a quote. There is no depth of meaning, or abstract reference, or hidden commentary. It is a direct request statement, basic functional language. How can that be copyrighted?

I mean, imagine the lawsuits that come out of this. Patent armories don't help for defense. Only writing tons and tons of library code and copyrighting it. You might have tons of excess software written just so they can sue other people for doing similar stuff.