Wednesday, October 30, 2002

Alternative XML syntaxes Alternative XML syntaxes. Via Sender Traumawind, IBM developerWorks: Exploring alternative syntaxes for XML. [Keith's Weblog] Ah. It looks like Tanga is very similar to SLiP. (Actually Chris's initial suggestion was use Python syntax, I tried to persuade him to use "=" instead of ":" to prevent namespace syntax confusion.  Great minds think aline eh :-). So we just need a JAXP parser for it then... 10:05:26 AM    comment []

Being architecture neutral Domain data. There is an article in the TheServerSide about designing your applications with a layer of 'Plain Old Java Objects' representing the domain data, and an EJB layer to handle the persistence. Even if I don't really like the complete solution presented in the article, I think it's difficult to not to agree with the idea that we should use domain classes that are totally independent of the persistence strategy. I want to use the same Customer class in my Windows client code, in my web application, in the middle tier, in the web services layer, etc, etc. Separating Data From Architecture is a good article about this. Working with a persistence layer that stores objects to the database is nice, but if you build your application on top of that classes, you are stuck with that persistence implementation, which is not a good idea. If you want to use a persistence layer, use it to persist your domain classes. I think .NET got it right. I really like the DataSets idea, even if today they do not interop via web services (I hope they will someday), and even if they are too 'relational'. DataSets are 'domain classes on steroids'. Designing Data Tier Components and Passing Data Through Tiers is a very good MSDN article describing the strategies available in .NET. [Andres Aguiar's Weblog] I totally agree with the above and there's some great links to interesting articles. I also totally agree with Carlos recent comments on the whole EJB issue. We should be able to build business logic in a way that is completely architecturally neutral (i.e. with no visible dependency on EJB, JDO, CMP). Then deploy it in various different topologies. e.g. rich client application talking to a database or a 1 tier Servlet engine with POJOs. Or 2 tiers, each tier could use different connectors (servlets, web services, JMS, RMI, even if need be EJB too). Different transaction managers could be used if need be. Different persistence mechanisms chosen based on the complexity of the application. Sometimes just beans + JDBC is fine. Or DynaSql etc. Via one of the articles above I spotted JBeans which is interesting. Its a fairly nice simple model. Though I don't like their 'Bean' base class, beans should just be beans - though I guess thats optional in their framework.  The concept of simple services which could be deployed as just POJOs or on EJB or in a web service framework is good. The biggest problem with EJB isn't the technical solution to remoting, to stateful/stateless session beans. Its that its all so visible and intrusive and damned complicated to use. Also the irony is barely 10% of uses ever even need the EJB solution. Most folks are developing web applications or web services that really don't need EJB at all. This stuff should be hidden and only actually used if stuff really is deployed remotely. .Net doesn't do this perfectly either; .Net remoting requires you to derive from MarshalByRefObject (rather like RMI in Java) whereas the SOAP stuff does not but requires extra class metadata. So again your business logic code must choose its architecture. So I think we need a new simple business logic Container API and then we can deploy our business logic in lots of different configurations using different technologies. Right now the closest thing I've seen to this is EOB with JBeans a close second both of which I think are close to what we need. I think we just need to seperate out what the domain classes actually need from a container, from how it actually works. Then we can write our application code then deploy it in the architecture or container that suits us best. As EOB demonstrates, a very simple API is all that we need; mostly just perfoming lookups on other objects in the container and registering services in the container so that they can be managed. To paraphrase something I remeber Rickard saying recently,  in the future we'll have lots of different kinds of Container. The trick going forward is to come up with one simple API we can use to keep the complex stuff hidden away from our precious business logic code. I think we need a new brand and name for this new API. .Jet anyone? :-) 8:51:31 AM    comment []