You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Christopher L Merrill <ch...@webperformance.com> on 2009/06/03 16:32:14 UTC
Re: singletons, pools, wicket, web services and architecture
It's a question we've wrestled with as well. It seemed remarkably
inefficient to do XML encoding/decoding to move data from one part of
the appserver to another. It seemed to make more sense to let the
web UI skip past that and go straight to the business logic.
Thanks!
Chris
Martijn Dashorst wrote:
> Might be a dumb question, but why not make your wicket front end use
> the JAX-WS services as well?
>
> Martijn
>
> On Thu, May 28, 2009 at 10:01 PM, Christopher L Merrill
> <ch...@webperformance.com> wrote:
>> I've got a few questions that are somewhat general to web development,
>> but since we've chosen Wicket as one of our front-end frameworks, I
>> thought I would ask here first for pointers...especially where there
>> may be a "wicket way" of doing things that we need to be aware of.
>>
>> The system we're developing will have 2 UIs - a browser-based UI
>> developed in Wicket and an Eclipse-based rich-client app (Java). The
>> available functionality will be a little different in each but with a
>> good bit of overlap. There must be common authentication - a user
>> might use either UI or both at any given time. We'll likely be using
>> JAX-WS for communicating between the rich client and server. The server
>> will be Tomcat.
>>
>> We obviously need to keep very good separation between the business logic
>> and presentation layers, since there will be 2 presentation layers :>
>>
>> 1) We need to have an "application" object/singleton to hold things
>> like "online/offline" mode - so we can, for example, bring the application
>> down for maintenance and give the user an intelligent response. In
>> Wicket, I think that would be the Application object? I assume we'll
>> need to make that reference a MyApplication object - how do I expose
>> that to both Wicket and the WS APIs? JNDI?
>>
>> 2) We'll want our database connection pools to also be shared...one
>> of the databases is an odd-ball - Filemaker (groan) - and I'm not sure
>> how to pool connections for it and share the pool between the Wicket
>> app and the WS APIs? When I've used connection pools in the past,
>> it has always been something common, like MySQL, so the Tomcat configuration
>> was pretty well-documented. I'm not sure where to start with this one?
>>
>> 3) Any other architecture issues I should be thinking about? Pointers?
>> Good articles that might address some of these issues?
>>
>> Thanks in advance!
>> Chris
>>
>>
>> --
>> ------------------------------------------------------------------------ -
>> Chris Merrill | Web Performance, Inc.
>> chris@webperformance.com | http://webperformance.com
>> 919-433-1762 | 919-845-7601
>>
>> Website Load Testing and Stress Testing Software & Services
>> ------------------------------------------------------------------------ -
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
--
------------------------------------------------------------------------ -
Chris Merrill | Web Performance, Inc.
chris@webperformance.com | http://webperformance.com
919-433-1762 | 919-845-7601
Website Load Testing and Stress Testing Software & Services
------------------------------------------------------------------------ -
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: singletons, pools, wicket, web services and architecture
Posted by James Carman <jc...@carmanconsulting.com>.
On Wed, Jun 3, 2009 at 1:00 PM, Christopher L Merrill
<ch...@webperformance.com> wrote:
>
> RMI would probably have been our (my) first choice, but is out due to
> firewall issues.
> Spring with the HTTP invoker was considered as well as some other more
> efficient
> HTTP and/or light-XML options. There are some organizational reasons to
> favor
> SOAP vs something simpler and there are plans to extend the service at some
> point to other organizations. We certainly _could_ do that later, but
> maintaining
> a 3rd interface down the road is not attractive in terms of maintenance
> cost.
> We would have to content with an installed user base - and therefore could
> not
> easily deprecate an unused interface.
Understood, however "maintaining" the interface isn't really an issue
with Spring remoting or directly calling the API (standard
refactorings would fix these situations). The only time you would get
into having to really work on the interface is if you do introduce the
SOAP/XML support. Then, you've got to worry about making sure your
XSD stays in synch with everyone. If you add that to your system now,
you're biting off the maintenance at a time when you don't know for
sure if you're going to need it ("at some point" may never come). I'd
go with the YAGNI principle, here.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: singletons, pools, wicket, web services and architecture
Posted by Johan Compagner <jc...@gmail.com>.
We (Servoy) use the same kind of stuff as you are building
We also have a description of the UI and we use ComponentFactories (1 for
swing 1 for web) to generate
pretty much the exact same interface in swing and in the web. The web is
ofcourse way harder because of html
and not the least the most stupid kind of "language" there is called CSS but
it works pretty good.
Besides that the Swing client does use RMI and our customers can use it in 2
variants
1 the server where our server software runs on must ofcourse open port 1099
to allow incomming connections
But thats it
The other option our customers have is use rmi http tunneling:
http://www.sebster.com/tunnel/
Then nothing has to be configured and that tunnel pushes pretty much through
anything.
So you can use rmi just fine, 1 tip put compressing socket factories on top
of the tunnel, rmi traffic is very compressable..
johan
On Wed, Jun 3, 2009 at 19:00, Christopher L Merrill <
chris@webperformance.com> wrote:
> James Carman wrote:
>
>> Is there any particular reason that you want to use XML-based
>> communication if you have an all-Java architecture going on? Wouldn't it
>> be easy to XMLize the services you're exposing remotely later if a
>> different type of client would want to connect to it? I'd say just
>> use Spring remoting (if you're using Spring).
>>
>
> RMI would probably have been our (my) first choice, but is out due to
> firewall issues.
> Spring with the HTTP invoker was considered as well as some other more
> efficient
> HTTP and/or light-XML options. There are some organizational reasons to
> favor
> SOAP vs something simpler and there are plans to extend the service at some
> point to other organizations. We certainly _could_ do that later, but
> maintaining
> a 3rd interface down the road is not attractive in terms of maintenance
> cost.
> We would have to content with an installed user base - and therefore could
> not
> easily deprecate an unused interface.
>
> Personally, I'm not fond of XML for this type of work...but such is life :>
>
>
> --
> ------------------------------------------------------------------------ -
> Chris Merrill | Web Performance, Inc.
> chris@webperformance.com | http://webperformance.com
> 919-433-1762 | 919-845-7601
>
> Website Load Testing and Stress Testing Software & Services
> ------------------------------------------------------------------------ -
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: singletons, pools, wicket, web services and architecture
Posted by Christopher L Merrill <ch...@webperformance.com>.
James Carman wrote:
> Is there any particular reason that you want to use XML-based
> communication if you have an all-Java architecture going on?
> Wouldn't it be easy to XMLize the services you're exposing remotely later if a
> different type of client would want to connect to it? I'd say just
> use Spring remoting (if you're using Spring).
RMI would probably have been our (my) first choice, but is out due to firewall issues.
Spring with the HTTP invoker was considered as well as some other more efficient
HTTP and/or light-XML options. There are some organizational reasons to favor
SOAP vs something simpler and there are plans to extend the service at some
point to other organizations. We certainly _could_ do that later, but maintaining
a 3rd interface down the road is not attractive in terms of maintenance cost.
We would have to content with an installed user base - and therefore could not
easily deprecate an unused interface.
Personally, I'm not fond of XML for this type of work...but such is life :>
--
------------------------------------------------------------------------ -
Chris Merrill | Web Performance, Inc.
chris@webperformance.com | http://webperformance.com
919-433-1762 | 919-845-7601
Website Load Testing and Stress Testing Software & Services
------------------------------------------------------------------------ -
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: singletons, pools, wicket, web services and architecture
Posted by James Carman <jc...@carmanconsulting.com>.
On Wed, Jun 3, 2009 at 10:32 AM, Christopher L Merrill
<ch...@webperformance.com> wrote:
> It's a question we've wrestled with as well. It seemed remarkably
> inefficient to do XML encoding/decoding to move data from one part of
> the appserver to another. It seemed to make more sense to let the
> web UI skip past that and go straight to the business logic.
>
Yes, the web UI should skip it definitely and just talk directly to
the service objects. But, I'm talking about the client application.
Is there any particular reason that you want to use XML-based
communication if you have an all-Java architecture going on? Wouldn't
it be easy to XMLize the services you're exposing remotely later if a
different type of client would want to connect to it? I'd say just
use Spring remoting (if you're using Spring).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org