Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[stp-dev] Seeking a balance


I ran across this blog from Mike: http://milinkovich.blogspot.com/2006/04/seeking-balance.html referring to John's post (http://www.xlml.com/aehso/2006/03/14/jcp-rubberstamping-and-eclipseorg-project-disarray/) and I'd like to take this criticism and run with it. I think the STP deployment framework is a perfect example of the "cracks" that John mentions.

 I really do fear that we are about to reinvent alot of the pieces in the WTP Server Tools API. I know there is some coordination going through the PMCs (I think), but I'd like to encourage the STP PMC to open the discussion up about the design of the deployment framework to the STP community through the stp-dev mailing list, rather than the stp-pmc mailing list.

I think there are some misconceptions about what the WTP Server Tools API supports. As John points out, the WTP Server Tools API is not J2EE-specific. It operates around a generic "Connection" object, and I think that most servers use the standard JMX API for communication between servers, but this is not required. The "Technology Types" concept which is to be introduced under an STP Server Tool API is exactly that of WTP Project Facets -- which are also generic ways to add information to a project about what kind of development the project can support.

The WTP Server Tools API and Project Facet API have had more scrutiny and overview than any other API in WTP. They are the core of what WTP has been developing since its early days, since they are so fundamental to an integrated Enterprise development platform. WTP will almost certainly never agree to drop their API and replace it with a DTP "Connection Profile" as so many WTP adopters already have significant dependencies to this API.

WTP will also *NOT DEPEND* on DTP. The RDB functionality is being moved out of WTP, but DTP and WTP are to be sibling projects. If clients need Database integration, then they are free to pick up DTP and WTP; but this is *not* required. There will be no hard dependency between the two projects, and I have confirmed this with a member of the WTP Architecture Group. Therefore, they are even less likely to consider replacing their server integration API with the DTP version.

I think that any deployment framework that STP produces has to be "connection neutral". I would encourage that integration into Enterprise Service Buses (ESBs) or SCA containers (like Tuscany) simply re-use the WTP Server Tools framework, as it provides a way to define new servers, monitor server connections, and in conjunction with Project Facets, allows Eclipse projects to be configured with the appropriate build path configuration or other functionality. Any platform built on STP cannot require clients to redefine integration with existing J2EE servers; nor expose "new" server views for monitoring running servers. The Web Tools Platform already has a server monitor view for any type of server. It is not J2EE server specific. Also, as there is already extensive support for Apache Tomcat -- and even a base Apache server (I believe), it should be easy to add the server definition for the Apache Tuscany sever through this framework as well.

I appreciate the fact that there are individuals who have invested sizeable effort into a server integration piece in isolation, but we have to consider what is best for the STP platform; and I truly believe that any new server integration framework with new concepts that mirror existing functionality in already well-reviewed platforms is a severe error. That said, I'm sure that there are some pieces that can be re-used from this effort; but any pieces that deal with defining "new connections" or "new servers" or that expose new views for monitoring or deploying applications to a server are likely to splinter the Eclipse ecosystem architecture even more.  I also think these will lead to new usability concerns if existing users who are familiar with WTP or DTP pick up the STP functionality and then have new Enterprise project creation paths that are incompatible with WTP projects.

It has been a long process for  WTP to build the server tool and facet API and establish adoption of these concepts and API. Let's take that and run with it so that we can get off the ground more quickly; rather than undergoing the same effort that they've had to endure for the server integration piece.


-------------------------------------------------------------------------
Kind Regards,

Michael D. Elder
Rational Studio / Services Tools Development    
IBM RTP Lab
Ext: (919) 543-8356
T/L:  441-8356
mdelder@xxxxxxxxxx


Back to the top