CAcert Code Development list.

[Jan Dittberner <jandd AT cacert.org>]

On Wed, Mar 17, 2010 at 11:00:49PM -0700, Mario Lipinski wrote:
> Am 19.12.09 04:28, schrieb Christopher Etz:
> >      One point that I miss in the current information within the wiki,
> >      is the kind of response that the services produce. I expect, you
> >      think of XMLs containing the requested information. Then, it is up
> >      to the different applications to decode (unmarshall, deserialize)
> >      the response. This would require to implement similar code in
> >      every programming lanuguage of the different applications. Or am I
> >      wrong here?
> 
> I guess it will be some kind of XML. Maybe even SOAP. But this is
> still open.

XML/SOAP has quite some overhead. Recent developments (at least at the 
projects
I worked on in the last few years) use more compact yet machine independent
formats like JSON [1] or YAML [2] or even binary formats like Hessian [3] or
Google Protocol Buffers [4]. There exist serializing/deserializing functions
for most commonly used languages (Java, Python, PHP, C/C++), JSON is even 
built
into at least Python and PHP.

[1] http://json.org/
[2] http://yaml.org/
[3] http://hessian.caucho.com/
[4] http://code.google.com/p/protobuf/

The main advantage of XML/SOAP in combination with a properly defined WSDL
description is the well standardized interface definition. But there are
interoperability issues with SOAP when not used properly and especially when
used accross different plattforms/frameworks/programming languages.

JSON has the added advantage that it can be used to communicate between 
backend
systems as well as with JavaScript capable browsers in AJAX scenarios.

> >   3. Technologies that might be useful
> >      Within the architectural overview, a decision should be suggested
> >      about how to access the database. The technologies of interest are:
> >          * Pure SQL via JDBC (if the programming language is Java)
> 
> I tend to do so. Maybe some object oriented framework to
> constructing queries. I know Zend Framework for PHP has something
> like this, but do not know about anything for Java.
> 
> >          * Use of an ORM (object relational mapper, such as Hibernate)
> 
> I had a look at hibernate some days ago and do not like the concept.
> Maybe I am just getting to old for this kind of mondern technology.

Hibernate or JPA (which Hibernate is one implementation of nowadays) shorten
development time and reduce error prone SQL development dramatically. The
disadvantage is that you have to properly annotate your entity classes to not
pull in entire object relationships trees if not necessary. Hibernate/JPA
support lazy loading. I think the advantages of Hibernate/JPA are much bigger
than the added third party framework code for most non-trivial projects.

> This is out of my scope whithin the business logic. But this could
> be anything which is able to talk to our business logic.
> 
> >      In my opinion, PostgreSQL requires regular maintenance (the famous
> >      vacuumdb at least) and might not be the best option when
> >      recoverability is a high requirement.
> 
> Postgres can do auto vacuuming in recent versions and also had made
> great inprovements over the last years. So I tend to using postgres.

Autovacuum is default since at least PostgreSQL 8.0 and it's great ANSI SQL
compliance, good database drivers for many programming languages and decent
performance make it a great choice. In some recent projects at work our 
vendors
recommended PostgreSQL as an alternative to Oracle or IBM DB/2 and support it
as well.


Regards
Jan Dittberner

PS: I work as a software architect for more than 10 years now (using J2EE,
Spring, some Python and PHP frameworks) and just want to help to avoid common
pitfalls

-- 
Jan Dittberner - CAcert Infrastructure Team
GPG-key: 4096R/558FB8DD 2009-05-10
         B2FF 1D95 CE8F 7A22 DF4C  F09B A73E 0055 558F B8DD
http://www.dittberner.info/

Attachment: smime.p7s
Description: S/MIME cryptographic signature