[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [wtp-jst-dev] Notes from today's EJB3 meeting?
|
Hi
Arthur,
So, it
seems I have catching up to do regarding the WTP subprojects
:-)
"The scope of JST is standards defined by JCP for J2EE, which
certainly includes EJB 3.0. Any project that supports EJB 3.0 should build on
the EJB support currently in WTP.
"
[RCG] I think it would be important to understand what you mean why
you say EJB 3.0 projects should "build" upon the current
support. Can we identify the areas that you think are
important? I know some of the things are those which have moved to
DTP and we are working with those, but I suspect there are other areas you
are thinking about. Can you elaborate?
Thanks,
-Robert
Robert,
Nice summary, but I'd like to correct one
statement. WTP is not restricted to J2EE server managed runtimes. It also
includes client programming. In many cases, the client will be a Web
application that runs in a J2EE server, but that is not the only case.
WTP includes the WST subproject which
deals with Web standards and includes tools for client side technologies such
as HTML, _javascript_, and CSS.
Also, the the JST subproject supports clients that access components
that run in J2EE servers or other compliant Web service servers. For example,
the current JAX-RPC spec includes both client and server programming models.
The spec will be split to support client access to Web services that do not
include a full J2EE environement, i.e. the next JAX-RPC will support J2SE
based Web service clients.
The
scope of JST is standards defined by JCP for J2EE, which certainly includes
EJB 3.0. Any project that supports EJB 3.0 should build on the EJB support
currently in WTP.
Arthur
Ryman,
Rational Desktop Tools Development
phone: +1-905-413-3077, TL
969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920,
TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
intranet:
http://labweb.torolab.ibm.com/DRY6/
"Robert Greene"
<rgreene@xxxxxxxxxxx> Sent by: wtp-jst-dev-bounces@xxxxxxxxxxx
06/10/2005 11:53 AM
Please respond
to J2EE Standard Tools developer
discussions |
|
To
| <wtp-jst-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [wtp-jst-dev]
Notes from today's EJB3 meeting? |
|
Hello all,
Below is my contact info as well.
I am
additionally the project manager for this open source initiative.
I did not
take any notes, but can summarize the main points as I recall them.
(1)
There is a belief that this technology is very application developer centric.
I think everyone agreed on this point.
(2) There is the
thought by WTP PMC that given (1) and the fact that this is based on a J2EE
driven spec that it may be best to host the project within the WTP
project.
(3) There are 2 considerations opposing the above.
a)
Whether longer term in the technology adoption lifecycle the use might
find it's way closer to the DBA's. The point was that developers can
with this technology ignore the database, one button click and they are
mapped. However, existing schema and/or the realities of performance and
scalability will drive smarter decisions regarding the selected mapping
patterns. Plus there are other features like named queries where SQL execution
plans can be reviewed and improved by someone who understand the relational
schema better (DBA's). If ORM becomes the predominant way of dealing
with the database and DBA's want to retain control over relational schema and
it's access outside of the language contsructs then they may assume the role
of "mapper". I do not have a strong opinion regarding this point, only
wanted to raise the issue as a valid consideration.
b) Because the ORM
technology is spec'ed to work both inside and outside of application server
managed environments and WTP is very much dedicated to J2EE then perhaps it
belongs somewhere else. One potential "other place" is DTP since this
technology is so tightly coupled with data access in general and ORM was
originally defined in it's top level project proposal. Additionally, the
DTP has several code bases that are integral parts of what is needed by ORM.
You can view ORM as a consumer of DTP components.
(4)
Regardless of the above discussion on where the project belongs longer term,
there was a suggestion that ideally we should only have one project and we (
Oracle, JBoss, Versant, Others ) should find a way to work together to achieve
that goal.
(5) I suggested a discussion regarding (4) could start by a
discussion of where the interested parties are headed, what is currently
implemented and available and how can those things that are available can be
combined to bring a quality solution to the Eclipse community as in a
meaningful timeframe. I indicated that we are reworking our previous
plug-in to be properly integrated with existing Eclipse project code. We
have been heavily focused on full SWT, forward engineering, annotations,
Live ER diagrams, context sensitive mapping pattern selectivity. The
folks from JBoss indicated that they have been focusing on reverse engineering
work.
The following is a high level overview of what we are
doing.
Created the ability to enable a project for ORM configuration
and created a framework for associating a runtime plug-in with a project.
We have created one example of how to use the framework using our open
source EJB runtime. Created a framework for the context sensitive
mapping GUI to reflect the capabilities of the runtime currently associated
with an enabled project. We have used our open source EJB runtime to
show how to use this context sensitive GUI framework. Created
synchronized views of mapping information ( source code editors, mapping
pattern editors, live ER editors ) where a change in any view is reflected in
the others. So, for example if someone adds an annotation to the source
code the appropriate mapping possibilities automatically appear in the mapping
view and the default mapping is selected and represented by a live ER diagram.
Created an extensible framework for allowing vendors to provide
customizable input output capabilities to accommodate alternative runtimes.
Used this framework to show an example of outputting meta data for our
open source EJB runtime. All of this is driven by an EMF model that
vendors may extend to suit their needs.
Rather than working on
reverse engineering over the last 6 weeks, the proposed JSR220 committers have
been reworking to integrate with Eclipse code base. Given that the JBoss
group has done a lot around reverse engineering, perhaps this is one starting
point for looking at integrating the code bases? In recent
additions to the Oracle proposal, I have seen some screen shots of expected
capabilites. Perhaps we can talk about these in more detail and
understand what has been done so we can understand overlap with JBoss and
Versant stuff. Then we could fill in the holes on a phase 1 of a
complete solution.
-Robert
Robert Charles
Greene
Vice President, Product Strategy
Versant Corporation
6539
Dumbarton Circle
Fremont, CA 94555
Office: (510)789-1627
Mobile:
(925)577-4634
_______________________________________________
wtp-jst-dev
mailing
list
wtp-jst-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-jst-dev