| Why is a J5EE server required? [message #4123] |
Sun, 09 March 2008 15:18  |
|
[Jochen Krause said]
Are your server components already packaged in (OSGI) bundles? Why do
you require a JEE server?
[Tim deBoer said]
The one question I had that I couldn't find (or at least understand)
the answer to is why your architecture uses a J2EE server - most
requirements tools I've used in the past are just client tools backed
by a team provider. Do users version the requirements and also
'publish' to the server, and what extra capabilities does the 'business
logic' on the server provide?
--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
| Re: Why is a J5EE server required? [message #4194 is a reply to message #4123] |
Mon, 10 March 2008 13:06  |
|
On 2008-03-09 15:18:51 +0000, Joel Rosi-Schwartz
<Joel.Rosi-Schwartz@Etish.org> said:
> [Jochen Krause said]
> Are your server components already packaged in (OSGI) bundles? Why do
> you require a JEE server?
>
> [Tim deBoer said]
> The one question I had that I couldn't find (or at least understand)
> the answer to is why your architecture uses a J2EE server - most
> requirements tools I've used in the past are just client tools backed
> by a team provider. Do users version the requirements and also
> 'publish' to the server, and what extra capabilities does the 'business
> logic' on the server provide?
I am actually a bit surprised that this question has not come up more
frequently; I will take that as a good omen :-)
First to answer the OSGI packaging question. No not yet, but it is on
our agenda to do do so. I am not as up on OSGI as I would like, but I
am hopeful that they will help resolve some sticky server side
contribution issues that the framework presently has.
The J5EE server is not strictly necessary, but some level of server is
required. A team provider would simply not be sufficient to meet the
goals of the framework. One of the most important features of the
framework is that it is collaborative and that multiple users can
create and edit highly interdependent document sets safely. This
implies that a person editing a document must not be able to make
changes that would break other documents in the system. The best a team
provider would be able to do is provide a merge facility after the
fact. We seriously investigated this path early on and came to the
conclusion that the complexity of merging multiple changes, possibly
made by multiple persons at different times would be exceedingly
complex to build and to use. Remember this is not source code which is
highly structured and where conflicts are relatively easy to recognise
and resolve. The problem is more closely akin to web editors, e.g.
Dreamweaver, that does link updates for you on the fly when changes in
the document structure occur. The big difference is that we aim to
solve a similar (but actually larger) problem in a collaborative
environment. I am not familiar with a web editor that will keep links
straight with multiple persons editing simultaneously and checking in
at arbitrary intervals. If you think the problem through, even edit
locking does not solve the problem unless the person doing the edits is
aware of the repercussions of the edit through the graph of affected
documents, and then lock all of them, does the edit and checks them all
in immediately. This is obviously going to lead to deadlocks in an
active project that will make tools built on ORMF virtually useless.
In fact, however, a full blown J5EE server is not necessarily required.
For instance we have investigated a lighter approach of Spring on top
of Tomcat. The trade-offs are the usual performance and scalability vs.
simplicity. The framework is being built to be able to handle any
number of projects on a single sever, with as many users per project as
are needed for each project. This implies that resource management will
be essential in large active environments.
If there were sufficient demand for both a light weight and heavy
weight version of the ORMF it is certainly architecturally feasible. In
fact, as long as the model and data store schema stay stable, it would
be rather straightforward to migrate from one to other.
B. and Joel
--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
| Re: Why is a J5EE server required? [message #561564 is a reply to message #4123] |
Mon, 10 March 2008 13:06 |
|
On 2008-03-09 15:18:51 +0000, Joel Rosi-Schwartz
<Joel.Rosi-Schwartz@Etish.org> said:
> [Jochen Krause said]
> Are your server components already packaged in (OSGI) bundles? Why do
> you require a JEE server?
>
> [Tim deBoer said]
> The one question I had that I couldn't find (or at least understand)
> the answer to is why your architecture uses a J2EE server - most
> requirements tools I've used in the past are just client tools backed
> by a team provider. Do users version the requirements and also
> 'publish' to the server, and what extra capabilities does the 'business
> logic' on the server provide?
I am actually a bit surprised that this question has not come up more
frequently; I will take that as a good omen :-)
First to answer the OSGI packaging question. No not yet, but it is on
our agenda to do do so. I am not as up on OSGI as I would like, but I
am hopeful that they will help resolve some sticky server side
contribution issues that the framework presently has.
The J5EE server is not strictly necessary, but some level of server is
required. A team provider would simply not be sufficient to meet the
goals of the framework. One of the most important features of the
framework is that it is collaborative and that multiple users can
create and edit highly interdependent document sets safely. This
implies that a person editing a document must not be able to make
changes that would break other documents in the system. The best a team
provider would be able to do is provide a merge facility after the
fact. We seriously investigated this path early on and came to the
conclusion that the complexity of merging multiple changes, possibly
made by multiple persons at different times would be exceedingly
complex to build and to use. Remember this is not source code which is
highly structured and where conflicts are relatively easy to recognise
and resolve. The problem is more closely akin to web editors, e.g.
Dreamweaver, that does link updates for you on the fly when changes in
the document structure occur. The big difference is that we aim to
solve a similar (but actually larger) problem in a collaborative
environment. I am not familiar with a web editor that will keep links
straight with multiple persons editing simultaneously and checking in
at arbitrary intervals. If you think the problem through, even edit
locking does not solve the problem unless the person doing the edits is
aware of the repercussions of the edit through the graph of affected
documents, and then lock all of them, does the edit and checks them all
in immediately. This is obviously going to lead to deadlocks in an
active project that will make tools built on ORMF virtually useless.
In fact, however, a full blown J5EE server is not necessarily required.
For instance we have investigated a lighter approach of Spring on top
of Tomcat. The trade-offs are the usual performance and scalability vs.
simplicity. The framework is being built to be able to handle any
number of projects on a single sever, with as many users per project as
are needed for each project. This implies that resource management will
be essential in large active environments.
If there were sufficient demand for both a light weight and heavy
weight version of the ORMF it is certainly architecturally feasible. In
fact, as long as the model and data store schema stay stable, it would
be rather straightforward to migrate from one to other.
B. and Joel
--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
Powered by
FUDForum. Page generated in 1.50007 seconds
] 
Search
Help
Register
Login
Home
