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/05/28 22:01:01 UTC
singletons, pools, wicket, web services and architecture
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
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
Re: singletons, pools, wicket, web services and architecture
Posted by Christopher L Merrill <ch...@webperformance.com>.
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 Per Lundholm <pe...@gmail.com>.
IMHO: Sounds like you need an J2EE application server more than just a
servlet container (tomcat) with all integration issues.
/Per
2009/5/28 Martijn Dashorst <ma...@gmail.com>:
> 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
>>
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.5 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
FaceBush, min insamling i Mustaschkampen:
http://www.cancerfonden.se//sv/Mustaschkampen/Kampa/Insamlingar/?collection=243
---------------------------------------------------------------------
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 Martijn Dashorst <ma...@gmail.com>.
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
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
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 Adrian Wiesmann <aw...@somap.org>.
Hello all
Christopher L Merrill <ch...@webperformance.com> wrote:
> We obviously need to keep very good separation between the business
> logic and presentation layers, since there will be 2 presentation layers
> :>
We have a similar architectural design for our ORICO (Open RIsk and
COmpliance) Tool. There is a web client and there is a native (Swing)
client. What we did was to write Gozer (GPLv3). Gozer - as the name
implies - has something to do with XUL.
When using Gozer you describe your UI in an XML file which is converted
into a object hierarchy which is then taken by a renderer (Swing, Wicket,
FOP, Excel, ...) and rendered into the actual UI. This works quite good
with Wicket and FOP, Swing lacks a bit behind in development but is
promising as well.
So what we have is a complete abstraction of the UI logic which is then
reused for every platform without us having to rewrite anything. This of
course comes with some cut backs, but if you are willing to take them,
Gozer is the solution to build UIs very quickly.
> 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?
I'd go the entry server way where access to the web application goes
through some reverse proxy. When your application goes down, the entry
server can return a intelligent response.
Concerning the online/offline topic. What we planned is that the Swing
client can be used in offline mode. To do so, you synchronise some data
with an embedded database (Derby) prior to going offline. Since all our
primary keys are UUIDs, synching is (at least theoretically) no pain at
all.
Cheers,
Adrian
---------------------------------------------------------------------
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 Thu, May 28, 2009 at 4: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.
Why use JAX-WS if you don't have to? We use Spring remoting (with
Spring security for common authentication/authorization) in our
application and everything works just fine.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org