[stp-dev] IRC log 07jun06

[Oisin Hurley <ohurley@xxxxxxxx>]

[16:58] jrohn joined the chat room.
[17:04] RobCernich joined the chat room.
[17:04] RobCernich: sorry i'm late
[17:04] oisin: no prob
[17:06] oisin: well guys not much going on at the moment for one  
reason or another
[17:06] oisin: rob: do we have something to put up on the website  
around the SOAS subproject?
[17:10] oisin: knock knock, rob, hello?
[17:11] oisin: get the coffee before the IRC
[17:13] oisin: ok, most of the questions I had were for rob, so I  
guess this will be a short one...
[17:13] oisin: does anyone else want to put anything on the agenda?
[17:14] DavidBosschaert: Maybe we should talk a bit about facets,  
since some links to its docs were posted to the devlist...
[17:14] DavidBosschaert: Did anyone look into them?
[17:14] DavidBosschaert: (I did for a bit
[17:14] RobCernich: sorry
[17:15] oisin: yes the facets stuff is pretty cool and the work done  
by Philip Dodds for JBI deployment is neat
[17:16] oisin: we have a very important task to see how the facets  
approach and the deploy framework approaches can co-exist
[17:16] RobCernich: i don't see any problems there
[17:16] RobCernich: the facets look like a more advanced version of  
project natures
[17:16] oisin: yes indeed they do
[17:17] RobCernich: i don't see them as a requirement for the stp  
platform
[17:17] RobCernich: although extensions may decide to use them
[17:17] RobCernich: as far as integration with the assembly models  
go, i think the context api's included in the core project are more  
appropriate
[17:18] DavidBosschaert: Would it maybe make sense to use them in the  
same manner as WTP is using, basically as technology markers...
[17:18] RobCernich: since they would have an affect the functionality  
available within the assembly editor
[17:18] oisin: rob: can you explain a bit more?
[17:18] RobCernich: which part
[17:19] oisin: the part where you started talking about integration  
with assembly models
[17:19] RobCernich: i meant with respect to facets
[17:20] oisin: still don't understand - bit slow today - let me try  
to be a bit more accurate
[17:21] oisin: are you saying that the core context apis are more  
appropriate for use than the facets?
[17:21] RobCernich: as i understand (from a high level) the context  
portion of the core project allows extensions to define which sca  
extensions are available for use within that editing session
[17:21] RobCernich: i think so
[17:21] RobCernich: the facets seem useful in the ways wtp uses them
[17:22] RobCernich: i don't see a matching use case for stp
[17:22] RobCernich: exemplary tools may use them, but i don't see a  
use for the core platform
[17:23] oisin: I'm still struggling a bit but I think what you are  
saying is that...
[17:23] RobCernich: facets affect the project, contexts affect a  
specific assembly model instance
[17:24] oisin: the use of facets in the context of them being an  
analog of an advanced nature is not necessary for STP
[17:24] RobCernich: or the editing session for a particular assembly  
model
[17:24] RobCernich: at the platform level
[17:24] RobCernich: extension developers may choose to use them for  
their specific service types
[17:24] DavidBosschaert: What about requirements that maybe be placed  
on a target runtime. Could they not be specified as a facet?
[17:24] RobCernich: e.g. EJB services
[17:25] RobCernich: they could, but that would affect an entire project
[17:25] RobCernich: as opposed to a single assembly model
[17:25] RobCernich: which, i think, is what the context api's are for  
(don't quote me on that)
[17:26] RobCernich: the assembly model is the deployable unit, not  
the project
[17:26] RobCernich: i think that's a basic difference from wtp
[17:26] DavidBosschaert: I understand what you mean now.
[17:26] oisin: if  we take the approach that each service within the  
assembly is a project in its own right, then facets could be used as  
markers for those projects, then when we go to deploy the assembly,  
the actions we need to take could be driven from those facets?
[17:27] oisin: implication that the assembly is a separate project
[17:28] RobCernich: that is a possible approach
[17:28] RobCernich: i'm not sure i would want to develop using that  
approach
[17:28] RobCernich: my analogy would be a separate project for each  
java class
[17:28] oisin: ??
[17:28] RobCernich: a single project for every service
[17:28] RobCernich: my analogy would be, for a pojo app
[17:29] RobCernich: one project for every java file
[17:29] RobCernich: one project defining the jar
[17:29] oisin: I think your analogy doesn't fit because classes are a  
much more fine-grained thing than a service
[17:29] RobCernich: so, if i had an assembly with 10 services, i'd  
have 11 projects
[17:29] oisin: that being said, multiple services per project is a  
much better idea
[17:30] RobCernich: that was my point
[17:30] oisin: so if you had an assembly with 10 services you could  
have anything from 2 to 11 projects
[17:30] RobCernich: seems reasonable
[17:30] RobCernich: my preference would be to have a single project
[17:30] oisin: I think you will need project per service if they are  
heterogenous -- e.g. different languages or different runtimes
[17:31] oisin: I think it's useful to decouple the service  
implementation projects from the assembly project
[17:31] oisin: My reasoning is that this allows your developers to  
construct services without having to deal with the assembly project  
(where practical of course)
[17:32] RobCernich: i think that is useful, i also think it's useful  
to have them colocated
[17:32] RobCernich: depending on how big the project or organization is
[17:33] oisin: yes, and how you want to reuse services
[17:33] RobCernich: right
[17:33] DavidBosschaert: Freedom of choice for the developers is good
[17:33] RobCernich: with respect to that, you may have services  
referencing a common interface
[17:33] oisin: enough freedom, just not too much
[17:33] RobCernich: aye
[17:34] RobCernich: so, now you have possible three artifact types  
that you are referencing
[17:34] oisin: note that the services that reference a common  
interface can also reference a common implementation
[17:34] RobCernich: assembly references components (services)
[17:34] RobCernich: a service may reference/make use of service  
interfaces
[17:35] RobCernich: that interface would be implemented by another  
service
[17:35] RobCernich: the assembly hooks them together
[17:35] RobCernich: so if we have multiple projects
[17:35] RobCernich: we need to figure out this bit of simply  
referencing an interface
[17:36] RobCernich: would this be another project type?
[17:36] oisin: i have an example in my head and here it is:
[17:37] oisin: somehow you have contrived to have a number of  
projects that implement services you wish to assemble
[17:37] oisin: so you make a new assembly project and you enter a  
wizard dialog...
[17:38] oisin: (actually, scratch the wizard bit, I was getting ahead  
of myself)
[17:38] oisin: you want to add a component to the assembly - it's  
this bit that has a wizard
[17:38] oisin: you can choose to import a component from an existing  
project
[17:39] oisin: your registered introspectors scan the project you  
choose to see if they can find anything they can use as the interface  
and the binding
[17:39] oisin: then you pick the ones you want and they are added to  
the assembly
[17:40] oisin: there is a cross-project reference here that might be  
a problem I am not sure
[17:40] DavidBosschaert: Additionally, I think you should be able to  
refer (or wire) to an External Service (outside of your control)  
without creating a project. You simply refer to them from the  
assembly project.
[17:40] oisin: (since it's in my head the edges are already all smooth
[17:41] RobCernich: seems reasonable
[17:41] oisin: this looks very like  http://wiki.eclipse.org/ 
index.php/Enterprise_SOA_Developer_Scenario
[17:41] oisin: on our scenarios page
[17:42] RobCernich: i'm still curious about references below the  
component level
[17:43] RobCernich: e.g. service a uses interface b
[17:43] RobCernich: service c implements interface b
[17:43] RobCernich: service a is added to assembly x
[17:43] RobCernich: assembly x needs to define a component  
implementing b
[17:43] oisin: a--wire-->b--impl by-->c
[17:44] RobCernich: user (perhaps with some help) finds service c,  
wires them together
[17:44] RobCernich: where does interface b live?
[17:45] oisin: I think it lives in a number of places
[17:45] RobCernich: assuming service a and c reside in separate projects
[17:45] RobCernich: shouldn't there be a single reference?
[17:45] oisin: ok -- what's the reality of where it lives in a multi- 
project scenario, right?
[17:45] RobCernich: i see three possibilities....
[17:46] RobCernich: it lives in the project by itself with projects a  
and c referencing it
[17:46] RobCernich: it lives in project c with project a referencing it
[17:46] RobCernich: it lives in project a with c referencing it
[17:46] RobCernich: sorry four, they are all colocated
[17:47] DavidBosschaert: yep, I think these are the possibilities
[17:47] RobCernich: i think the decision depends on your usage of the  
interface
[17:47] RobCernich: and your assembly
[17:48] oisin: and of course your development history
[17:48] RobCernich: from here you can start looking at permutations  
within the assembly model...e.g. different instances or impl's for  
qos, security, etc.
[17:49] oisin: if you have developed all this guys separately, then  
you may be constrained by your initial choice
[17:50] adisakala joined the chat room.
[17:51] oisin: i think we are having a useful discussion here - would  
you be in favor of continuing on the mailing list Rob
[17:51] RobCernich: maybe
[17:51] RobCernich: sure
[17:52] adisakala left the chat room.
[17:52] oisin: whew! didn't know where the maybe fitted in there
[17:52] RobCernich: do you want me to write something up
[17:52] oisin: yes please!
[17:52] RobCernich: ok
[17:52] RobCernich: i'll have something out by cob tomorrow
[17:52] oisin: that would be great.
[17:52] RobCernich: but i'll try for later today
[17:53] oisin: that would be very great
[17:53] oisin: one more question for you:  have you got any feedback  
on you CQ from the EMO
[17:53] RobCernich: yes
[17:54] RobCernich: i should be committing the code today or tomorrow
[17:54] RobCernich: i still need to get in contact with Naci about  
the build system
[17:54] oisin: excellent - I must catch up with Dan and the guys  
about their outstanding CQs
[17:55] oisin: when you contact naci will you keep adrian in the loop  
too - he's not here right now - he's going to take some of the  
buildmaster load
[17:55] RobCernich: do i need to do anything for the ip log for this  
(e.g. re. the approval from the emo)
[17:55] RobCernich: i will do that
[17:56] oisin: yes an entry will be required in the IP log
[17:56] oisin: http://www.eclipse.org/stp/development/ip_log.php
[17:56] oisin: I can add you in if you like
[17:57] RobCernich: ok
[17:57] RobCernich: do i need to do anything with the approval  
confirmation email i got from the emo, or is this tracked directly by  
them?
[17:57] RobCernich: i.e. do you need anything from a project perspective
[17:58] oisin: it would be useful to keep it on file as it were -  
would be a good plan to add it as a comment to the bugzilla entry  
before closing
[17:58] RobCernich: will do
[17:58] oisin: yes it is tracked directly by them too
[17:59] oisin: will you move any doco over to the SOAS subproject  
page too Rob when you get the chance - it's bare!
[18:00] oisin: sorry rob seems I am dumping stuff on you here
[18:00] RobCernich: i am a committer; should earn my keep
[18:01] oisin: there is advice there for us all...
[18:04] oisin: one more topic before we go...
[18:05] oisin: there was a mail on stp-dev about changing the time of  
this IRC to mondays at something like 1200 EST
[18:05] RobCernich: works for me
[18:05] oisin: there was a huge response to the question and the mail  
server was totally swamped
[18:05] oisin: *not*
[18:05] oisin:
[18:06] oisin: ok we will move our irc for next week to Monday at  
1200 EST]
[18:06] oisin: will send out notice.
[18:07] oisin: we are not at the watershed - thanks guys for an  
interesting discussion and see you on the list