Philip,let us know if you switch the issue to another forum. Just to share points of view. Thanks
Vincenzo Caselli On Mon, Sep 8, 2008 at 9:02 PM, Philip Barlow <[EMAIL PROTECTED]> wrote: > Thank You Vincenzo for your input. I would agree that XML serialization is > not the fastest and i have yet to finish my research on Matt's suggested > approach but i will share any useful information I find. > > We did show a performance boost in a recent application by trying out > stored procedures but i personally find them harder to maintain and also it > is hader to find problems when they arise. > > Anyway, maybe this subject is for another forum. Thanks alot for your > response. > > Vincenzo Caselli wrote: > >> Hi Philip, >> I completely agree with you with being against the stored procedure >> approach, it should be considered a very old, ugly and not portable way of >> doing things. >> The way suggested by Matt is very interesting indeed. An alternative could >> be exploiting the Appfuse feature of quickly turning a Manager method into a >> web service. This leads to a complete decoupling between the >> business/dao/model layer and the presentation/client side (opening to Flex >> of .NET GUIs for example), though there could be some performace loss due to >> the XML serialization and deserialization >> >> Regards >> >> Vincenzo Caselli >> >> On Sat, Sep 6, 2008 at 4:23 PM, Philip Barlow <[EMAIL PROTECTED]<mailto: >> [EMAIL PROTECTED]>> wrote: >> >> Thanks Matt, I will read up on this and see how closely it suits >> my needs. If anyone has any other suggestions I would be grateful. >> >> >> Matt Raible wrote: >> >> You could use Spring's HttpInvoker Strategy (Java >> Serialization over >> HTTP) to expose your Services via HTTP. Then you clients could >> talk to >> them by pointing at the appropriate URL to load them up. >> >> >> http://static.springframework.org/spring/docs/2.0.x/reference/remoting.html#remoting-httpinvoker >> >> HTH, >> >> Matt >> >> On Fri, Sep 5, 2008 at 1:45 PM, Philip Barlow >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: >> >> Hi All, >> >> I am looking for peoples opinions on 2 subjects, I think >> they are relevant >> enough to Appfuse and hopefully you agree. A design >> decision has recently >> arisen at work that i'm hoping people on this list could >> help advise me on. >> >> Basically i want to use the Appfuse service and data >> access layers as part >> of an application, sitting in front of this, instead of >> having a web front >> end, the application would have a socket server interface, >> in other words, >> the application would receive messages on this socket, >> deserialise the >> information and pass the objects to the service layer for >> processing. >> >> It is essentially a socket server i suppose. What i am >> wondering is, has >> anyone done anything similar? Can you recommend a way to >> launch this app >> with Spring, i.e. load the context at start up without >> having to have an >> application server such as tomcat/jetty? Probably an >> executable jar? >> >> Also, it has been argued that the database should expose >> stored procedures >> rather than using Hibernate in the way appfuse currently >> does, i disagreed >> as i find the way appfuse operates, more maintainable and >> portable between >> different databases, but again i would like peoples >> opinions on Hibernate v >> Stored Procedures... >> >> If you are still reading, thanks for taking the time, much >> appreciated. >> >> Thanks >> >> Philip >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
