[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stp-dev] IRC record 19apr06

I've been watching this discussion around the WTP/DTP server layers with some interest for a while now and judging from below there seems to be some confusion over what WTP provides. I thought I'd pass on some (high level) background reading for those who might be interested. "Server Tools API Concepts and Roles" (http://www.eclipse.org/webtools/wst/components/server/api_concepts.html) is a good start, also worth a look are the two presentations listed at http://www.eclipse.org/webtools/wst/components/server/index.html. After that, the best source of information is Reference section of the WST Developers Guide, in Eclipse Help (http://help.eclipse.org/help31/index.jsp) - it contains decent API JavaDoc and Extension Point documentation. Note these documents don't mention facets much but they are important. Facets arrived late in the WTP 1.0 release cycle so some earlier design docs are out of date as a result.

The most important concepts for first time readers are the "module" (logical units of content that can be deployed - e.g. 'service unit' in JBI speak) and the distinction between a "server" and a "server runtime". The WST Server tools framework effectively manages server lifecycle and how/when modules get deployed from the workspace to servers. Deployment implementations are all pluggable and are chosen based on the target server and source module type.

Worth noting, some of the documents above were written with a J2EE audience in mind since that's their primary audience. Don't be put off by the references to Web servers and EARs - the WST framework is technology neutral, hence it's existence in the "WST" rather than "JST" (J2EE) tier of WTP components.

On the question of whether WST would change to incorporate the DTP connectivity framework after 1.5, I think that is highly unlikely as the existing WST Server components are already published APIs. I'd imagine you'd get a pretty quick clarification from their PMC (and/or Tim deBoer ).


Oisin Hurley wrote:
[16:58] RobCernich joined the chat room.
[16:58] jrohn joined the chat room.
[17:02] oisin: hi guys
[17:03] DavidBosschaert: Hi Oisin
[17:03] RobCernich: hello
[17:03] jrohn: hi
[17:06] oisin: antony has done a top job on reforming the B2J part of the site: http://www.eclipse.org/stp/b2j/
[17:08] oisin: so whats current....
[17:08] oisin: 1. deployment and connectivity framework
[17:09] oisin: is on my list
[17:10] oisin: anything from anyone online?
[17:10] DavidBosschaert: Any chance of getting the build system checked in?
[17:10] oisin: naci is doing a refactor of it to make it look like what we discussed last week
[17:10] DavidBosschaert: (committed I mean)
[17:11] oisin: he has to fit this in -- adrian is not online here but has been talking to him
[17:11] oisin: then we need to put pieces on the website to host build results, etc
[17:12] oisin: I will ping him on it
[17:12] DavidBosschaert: Great
[17:14] jackl joined the chat room.
[17:15] oisin: on the deploy/connect framework, there has been some conversations regarding the facilities offered by wtp and dtp and how they fit with stp
[17:17] oisin: as I understand it there is concern that the connectivity part of the framework is represented by both DTP and WTP equally
[17:17] oisin: and the greater concern I guess in some areas is that the STP won't use the same connectivity apis as the WTP
[17:18] RobCernich: actually, there is no connectivity within the framework
[17:18] RobCernich: the framework leverages the DTP connectivity framework
[17:18] RobCernich: (just to clear things up)
[17:18] oisin: ah thanks for the clarification
[17:18] oisin: right. so there is a DTP connectivity framework and a WTP connectivity framework
[17:19] oisin: and they are considered by some to address the exact same issue in slightly different ways
[17:19] oisin: so the deploy framework is *not* the issue
[17:19] RobCernich: correct, although i'm not familiar enough with the WTP framework to comment on it, or similarities or differences between the two
[17:20] RobCernich: only so much as it relies on DTP connectivity
[17:20] oisin: so, our goal is to get someone who knows both the WTP and DTP connectivity frameworks
[17:20] RobCernich: and there is some concern that it does not leverage WTP's connectivity framework as you stated earlier
[17:20] RobCernich: it's on my list
[17:20] oisin: rob does WTP connectivity use DTP connectivity to get to data sources?
[17:20] RobCernich:
[17:20] RobCernich: not currently
[17:20] oisin: is there a plan to make this so?
[17:21] RobCernich: as i understand things, they will begin migrating to DTP as soon as callisto is released
[17:21] RobCernich: (from RDB)
[17:21] oisin: so WTP will have a dependency on DTP at some point in the future
[17:21] RobCernich: as i understand things, yes
[17:21] oisin: i feel a diagram coming on...
[17:22] RobCernich: we should clarify with them, to be sure
[17:22] RobCernich: i have no diagrams
[17:22] oisin: WTP connectivity also connects to things like web containers and J2EE servers, right?
[17:23] RobCernich: sorry, missed something from above...
[17:24] RobCernich: the WTP RDB component does not use WTP's server framework as far as I know
[17:24] RobCernich: there is a separate connectivity layer for db's in wtp
[17:24] oisin: yes that is what I was getting around to
[17:24] oisin: looks like more education is in order for all concerned
[17:24] oisin: i.e. me
[17:25] RobCernich: you're not alone
[17:25] DavidBosschaert: Question is, if WTP will take DTP connectivity...
[17:25] DavidBosschaert: will it only use it for the DB, or also for its J2EE servers?
[17:25] RobCernich: i can't speak to that
[17:26] RobCernich: we need to talk to somebody in wtp
[17:26] oisin: I'm going to set something up along those lines, Rob. Any suggestions for a good way to go about it?
[17:26] oisin: [that's a question for all, not just Rob]
[17:27] RobCernich: i think getting the pmc's together to chat about it would be a good place to start
[17:28] oisin: also, Rob: is there any good documentation you can point us to for the deployment framework
[17:28] RobCernich: not as yet
[17:28] oisin: there is some DTP connectivity information at http://www.eclipse.org/datatools/project_connectivity/connectivity_doc/dse/DTP%20Connectivity%20DSE%20Design%200_5.htm

[17:28] RobCernich: i just finished refactoring it for stp
[17:28] pombreda is now known as pombreda|away.
[17:28] RobCernich: i don't know how long it will take legal to sign off on it and karl is out of town
[17:29] oisin: arg!
[17:29] oisin:
[17:29] RobCernich: it will come with example implementations for the extension points
[17:29] oisin: still, that's cool that the hard work is done and now its just down to legal....
[17:29] oisin: can you tell us more about the example implementations?
[17:29] RobCernich: i need to make sure the javadoc is up to date
[17:29] RobCernich: sure
[17:30] pombreda|away: just my 2 cents on wtp/dtp/data tools...
[17:30] RobCernich: ...
[17:30] pombreda|away: afaik data tools migrated from wtp to dtp
[17:30] pombreda|away: and is kinda self standing
[17:31] RobCernich: parts of it, yes
[17:31] pombreda|away: hehe.. soryy for interrupting
[17:31] RobCernich: parts are new as well
[17:31] RobCernich: np
[17:31] pombreda|away: I pack it in my eclispe distro standalone. only has a few deps on on wst core stuffs
[17:31] RobCernich: would you like me to go into details (rdb->dtp)
[17:31] pombreda|away: sure
[17:32] pombreda|away: if this is appropriate for here and now
[17:32] RobCernich: the dbdefinition model, sql model, and model visualation code were migrated down from wtp
[17:32] pombreda|away: kk
[17:32] RobCernich: the connectivity framework was contributed by sybase
[17:33] RobCernich: as well as the sql editor and sp debugger framework
[17:33] pombreda|away: debugger? nice!
[17:33] • pombreda|away did not check it out yet
[17:34] RobCernich: k
[17:34] RobCernich: sample impl's....
[17:34] RobCernich: there is a logical package extension that works with eclipse jardesc files
[17:34] RobCernich: there is a physical package extension that works with jar files
[17:35] RobCernich: there is a deploy driver that extends the file connection profile example impl in dtp, supporting both package types listed above
[17:35] oisin: so that just writes them to a file?
[17:36] RobCernich: sort of
[17:36] oisin:
[17:36] RobCernich: the sample profile is designed to illustrate how to implement a connection profile and add content to the data source explorer
[17:36] RobCernich: it represents a directory on disk
[17:37] RobCernich: the deploy driver simply copies the package (either a jar file in a project or the jar file produced by a jardesc) to the directory represented by the profile
[17:37] oisin: ah i see
[17:38] RobCernich: the connection profile example is slightly contrived, but is simple to understand
[17:38] RobCernich: the connection created is simply a java.io.File object representing a directory
[17:38] RobCernich: in practice, this would be more complex
[17:38] RobCernich: e.g. java.sql.Connection
[17:39] RobCernich: or a JEE management connection
[17:39] RobCernich: or an ESB
[17:39] RobCernich: etc.
[17:39] jackl: thx Rob!
[17:39] oisin: great.
[17:40] RobCernich: the deploy extension would be responsible for "doing the right thing" with respect to its targeted server type
[17:40] RobCernich: so, for this contrived case, it simply copies the jar file into a directory
[17:41] RobCernich: for an app. server, it would presumably use JEE management api's in deploying an ear, war or jar
[17:41] RobCernich: for an ESB, it might use a proprietary api
[17:41] RobCernich: you get the idea
[17:42] oisin: the deploy driver is responsible for conducting the conversation that leads to the package being delivered to the target
[17:42] RobCernich: right
[17:42] RobCernich: the target is represented by a dtp connection profile
[17:42] RobCernich: the driver is typed to a specific class of profiles
[17:42] RobCernich: and registers with the framework which package types it supports
[17:43] RobCernich: there may be more than one driver for a given profile type
[17:43] oisin: can you expand a little on 'specific class of profiles'
[17:43] RobCernich: sure
[17:43] RobCernich: a class is really just a type of profile
[17:44] RobCernich: a type of profile represents an connectionProfile extension implementation
[17:44] RobCernich: the objects appearing in the data source explorer represent instances of connection profiles
[17:45] RobCernich: so, when i say class, i mean the driver supports all instances belonging to a type or class of profile
[17:46] oisin: thanks!
[17:46] RobCernich: say you have a Celtix profile extension
[17:46] RobCernich: the user creates instances representing various servers within their enterprise
[17:46] RobCernich: the deploy driver is capable of handling deployment to each of those instances
[17:47] RobCernich: (stop me if you get it
[17:47] jackl: i reckon I get it
[17:48] RobCernich: hopefully, we can get the code up on the stp site within the next week or so
[17:48] RobCernich: i've also got a diagram illustrating how it might fit into an stp workflow
[17:49] RobCernich: i'm just waiting for karl to review it before posting
[17:49] oisin: that would be great - don't forget it has to go in through bugzilla, so put it in as an attachment and then we will move it into cvs once all the epl process stuff is satisfied
[17:49] RobCernich: yep
[17:50] jackl: Apologies - I've gotta run. Thanks all!
[17:50] oisin: the diagram, plus another items like presentations, etc would make great starter material for the web site SOAS page
[17:50] oisin: thanks jack
[17:50] jackl left the chat room.
[17:53] oisin: ok have we any other business? Thanks Rob for all your information!
[17:54] RobCernich: np
[17:57] oisin: ok see you all next time.
[17:57] RobCernich: bye
[17:57] RobCernich left the chat room._______________________________________________
stp-dev mailing list