Best of this Week Summary 2 August - 8 August 2010

• How to utilize Externalization (faster, less flexible) for high performance applications instead of Serialization (slower, more flexible).
  


• A bunch of pros and cons of Wicket.
  


• An extensive tutorial on how to work with XML, JSON and Google's protocol buffers within Android applications. It shows how to "develop a Web service that converts CSV data into XML, JSON, and protocol-buffers formats. Then you'll build a sample Android application that can pull the data from the Web service in any of these formats and parse it for display to the user". Assumes Froyo 2.2. Also shows a short comparison in performance between the three protocols.
  


• A five part introduction to HTML5 focusing on the mobile web.
  


• Highlights from Black Hat and Defcon 2010. That means security stuff :).
  
  


• A list of (mostly obvious) performance problems identified at Zappos, Monster etc.
  


• A pretty comprehensive overview of Java code obfuscating including these types: name, strings, code and flow, incremental, watermarking etc.
  

Best of this Week Summary 12 October - 18 October 2009

• Last week was Oracle Open World 2009. Beside for Oracle DBMS and SOA specialists, these days the event is definitely also very relevant to Java professionals because of Oracle's (almost official) acquisition of Sun this year. Here's a set of relevant information from OOW:
  
  
  • The keynote on sunday which also describes the plans Oracle has with Java, MySQL and Sun hardware
    
  
  
  • James Gosling explaining to the developer audience what Sun was doing, what the scale is of Java activity around the world and across technology platforms.
    
  
  
  • The Dutch software company Amis also did quite a few presentations at OOW. Some of those presentations were already online before they were actually presented! All were interesting:
    
  
  
  • Good overview of what will be in the Patch Set 1 for the Oracle Fusion Middleware 11g stack, including JSF and ADF (mobile!). It's more than a patch!
    
  
  
  • Edition Based Redefinition (EBR): "Every database object (well, almost every database object - not tables!) can have different implementations/incarnations/versions in various editions. The object versions are all in the same schema - they only differ in the Edition they are created in."
    So no more direct table access! No big bang needed anymore. Challenges: what if a mandatory column is removed or added from the current EBR view (answer: special triggers). Including 2 suggestions for best practices.
    
  
  
  • XML processing/design tips.
    
  
  
  • This "session introduces SOA and the new Oracle SOA Suite 11g to the realm of database professionals from which it sometimes seems so far removed. What are the key SOA concepts and objectives? What is at the heart of Oracle SOA Suite 11g: composite applications, BPEL PM, and the mediator. The session shows how SOA services can be leveraged from the database, from triggers, PL/SQL units, or even SQL and how the database can publish events to the event delivery network. It covers how the SOA infrastructure can access the database, primarily using Oracle Database and Oracle Advanced Queueing adapter and how database developers can help in doing so efficiently. It ends with hints for applying SOA concepts to "normal" database development."
    
    Bit oriented at the database professional, but still interesting for those who want to stay up to date with Oracle's DMBS possibilities. And a bit scary too: it is possible in 11g to make webservice calls and publish them from the database(!). For example from PL/SLQ and put a webservice in front of PL/SQL... I haven't come up with a practical situation where you'd want to do this from an architectural point of view: large risk to getting tightly coupled systems and dependencies. If you have heavily invested (i.e built) in PL/SQL, it might be a valid option though.
    
  
  


• There is currently a renewed focus on the role of code generation in developing enterprise Java applications. Springsource recently released Roo, Skyway Software released Skyway Builder Community Edition version 6.3 and Blu Age released M2Spring. What should the software architects and developers look for in a Code Generation framework?
  


• Seven Wicket Do's and Don'ts.
  

Best of this Week Summary 26 January - 01 February 2009

• Part 1 of a series on how to represent XML schema types taking into account the mismatch between XML and the datatypes of a programming language.
  


• Nice non-techie explanation of what OAuth is. Plaxo and Google are now trying out a combination of OpenID for federated authentication and OAuth for the authorization process, and including the Google Contacts API in the workflow. Thus, more and more towards the Open Stack.
  


• A great series of SOA Patterns by Thomas Erl. This is the first one, a Service Façade.
  


• An interesting opensource effort to make consuming REST services more object oriented and Rails ActiveResource like with Rapa. "Rapa uses the tried and tested Jakarta Commons HttpClient and JAXB."
  


• And as the last item this week, get ready to test your websites with Internet Explorer 8, RC1 can be downloaded now and should be nearly identical to the final version.
  

Best of this Week Summary 16 June - 22 June 2008

• Nice (basic) overview on the architectural challenges Twitter has regarding updating thousands of followers when a user posts a message.
  


• Ten good tips to improve your XML effectiveness and efficiency.
  


• References to good articles on scaling and performance tuning monitoring of MySQL.
  


• This article examines Firebug and YSlow as tools for analyzing and improving performance of Ajax applications.
  


• What are some of the the architectural challenges for mobile applications in the web 2.0 era?
  


• Examples of some major enterprises where Adobe AIR ("the cross-OS runtime that lets you run rich internet applications on your desktop") is already being used. They include Nasdaq, Deutsche Bank.
  

OpenSocial: the harder technical outstanding questions

This week anybody following technical news cannot have missed the announcement of the Google OpenSocial initiative.



Here is a short introduction. A bunch of live examples can be found here.

Basically it is a widgets (gadgets) API specification, built in Javascript and XML that anybody can plugin on a social network page (like MySpace, Plaxo) to show relevant social information (e.g who are my friends in this social network).
Most posts were positive and only looked at potential positive uses. It took about half a day before the first more critical posts showed up.
With this post I'd like to provide you the current outstanding technical questions and issues with the OpenSocial API. First I'll list the posts I found until now, then my own outstanding questions.

Note: don't misunderstand me, I like the initiative, trying to get the so-called social graph standardized. But a careful examination is definitely relevant if you want to introduce it on your site.

• Good points (not only technical) what is not yet so good about OpenSocial
  


• This a good pretty good technical overview and points of critique which the above post mentions. Btw: I disagree with this statement definitly: "if REST APIs are so simple why do developers feel the need to hide them behind object models?". Object model abstraction can still be needed/desired to acquire the best level of abstraction.
  


• Note that the container API itself is not there yet...
  


• In the FAQ there is the question: "Can OpenSocial apps interact with other websites?". The answer is "Yes, social apps have the ability to fully interact with outside 3rd party applications using standard web protocols." But how does it then avoid the same origin policy for Javascript? Would the calls go via Google? How does it work with Google Gadgets (iGoogle), where you can specify any feed URL? My guess for this last one: via a Google proxy as provided in the Google Feed API... At the moment there exists no OpenSocial gadget that implements accessing data from multiple social networks.
  


• Why are technologies like Microformats and APML used? My guess for now: those "standards" are too much in an initial phase. An API with Javascript and XML are based on standardized technologies and immediately available.
  


• Really pay attention to the authentication mechanism described for the People Data , which all go through a Google account (or you can always use an email-address and password). Check the first details on this issue here.
  

Update: here's some sort of answer to some of the above questions.

Update: Google released version 0.5 of the OpenSocial Service Provider API (the container API). Very alpha.

Update: Here's a Javascript library that "solves" the same-origin-policy.

Best of this Week Summary 30 Sept - 07 Oct 2007

• Interesting and provocative point of view in this blog "Why most large-scale Web sites are not written in Java". Quite an extensive discussion can be followed in this TSS refering post. I think the main reason is that the use of the programming language and stack depends on the requirements of the application. Most of the example websites given do not have serious transactional requirements, including transactions that would run over multiple systems, requiring XA. For those example websites no real big harm is done when a transaction occasionally fails. Note also that most Java/JEE implementations use at least some part of the LAMP stack, like Linux and Apache. See here for other reasons.
  


• Danny Ayers is wondering whether JSON is missing a DTD or XSD. Because if you take an arbitrary JSON document from the Internet, you can't tell what it is containing; and usually you can't find it out either. Is that a good or bad thing? I'd say you've got XML and its associated XSD or DTD for interfaces that require a well-defined interface that can be passed on to other, potentially external, 3rd parties without too much effort. For interfaces that stay internal to your system (for example an AJAX call from the browser to the server), adding the extra overhead of some validation format like an XSD or DTD causes just too much overhead, losing the gain of the compactness of JSON. Data is validated anyway by the frontend and backend, though with a bit more programming effort.