On Wednesday 05 February 2003 06:01 am, Pavel Penchev wrote: > There are nice things my I'm more concerned how a piece of code that is > going to be deployed in the app server is described. Again Java but.. as an > example the EJB is described by a interfaces (Local, Remote), the code that > really does the job, and descriptors in xml format that specifies the > abstract shemas for SQL tasks. As I do not want to copy the way Java did it > (I just like the idea of EJB) I wonder some of you (Tod,Tom or anyone else > who has dealt with these matters) have defind a sertain skeleton that works > well for him.
Here's my problem with EJB. EJB frameworks take over total access to your database. IE, the schema ends up being whatever EJB decides it is, and most EJB implementations create horrible nightmarish cludge schemata!!! PowerTier for instance is complete hogwash. It doesn't even know how to do transactions for Pete's sake. Once you get your data into EJB, its there for good, and THAT I can't abide. The reason for RDBMS is so data can be formally structured properly and accessed easily and efficiently by whatever client software needs to talk to it. EJB breaks that entirely. To answer your question in a more positive fashion you always have WSDL which can describe your actual interface, both at the level of what parameters are required, and at other levels like what transport bindings are used and where the endpoints are (addresses of physical servers). Given that you can apply XML Schema to your messages you can essentially specify close to any arbitrary data formats you want to transport in a standardized way. Now as far as toolkits to do all this? Well, for perl they are still sadly lacking. You have to build all this basically by hand. I would love to see several things done 1) an IDL generator that can take a server class and generate the WSDL to describe the corresponding service. 2) a stub generator which would create the corresponding client-side code (in some instances you can live without that with perl, its so flexible in this regard you can make blind function calls across SOAP and 99% of the time it works, but it would still be a requirement for a serious system). 3) Some really decent open source tools for working with XML Schema. The tools that are at all good are now VERY expensive and still pretty limited. 4) I'm not sure what else, but.... As for SPOPS and Tangram the only reason we didn't use them was that they didn't allow for distributed object stores (IE every object would need both a serverid and an objectid and no existing object system provides that, including EJB). > > > > Pavel -- Tod Harter Giant Electronic Brain --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
