[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[stp-dev] IRC log 24may06

[17:03] oisin: howdy
[17:03] askehill: Hi there
[17:03] jrohn joined the chat room.
[17:04] oisin: looks quiet today
[17:04] oisin: maybe everyone is off writing up scenarios!
[17:07] RobCernich joined the chat room.
[17:08] oisin: ok we shall start. some scenarios have been received, anonymously, and maybe it would be a good plan to have a quick scan through them and see if there are any questions
[17:08] oisin: http://wiki.eclipse.org/index.php/STP_Call_for_Scenarios
[17:09] askehill: oops, that was me, I forgot to sign 'em!
[17:09] DavidBosschaert: So there is: Creating a new service & test
[17:09] DavidBosschaert: Adding an additional runtime
[17:09] DavidBosschaert: And finally, enabling existing app as SOA service
[17:10] askehill: Do I need to explain them, or is the title of scenario clear enough
[17:10] DavidBosschaert: I thought they were pretty clear
[17:10] askehill: basically I'm targetting the types of users who download the STP and want to become prodcutive
[17:10] oisin: The first one looks to be the first 15 minute scenario - that vital slice of time in which someone will either make something work or throw away the notion altogether
[17:11] askehill: agreed
[17:11] oisin: what do you think the 'generic stp project' means?
[17:11] askehill: not sure, I put a caveat in there stating that we should have some form of project type
[17:12] askehill: a generic stp project could just be a very basic boiler plate style project that people can use to edit basic interfaces
[17:12] DavidBosschaert: Were we not planning a toplevel project
[17:12] askehill: but there would be no generators / deployment available
[17:12] RobCernich: i think this would be useful for associating builders for STP supplied resources
[17:12] askehill: Yes a toplevel project could also exist, it just wasn't dicussed in those scenarios
[17:12] RobCernich: e.g. subsystem and module
[17:13] RobCernich: not sure if i agree with the notion that a project has to be specific to a runtime
[17:13] askehill: well there comes a point in the development where you need to make some decisions relating to the runtime you have to use
[17:13] askehill: ...
[17:13] askehill: for example
[17:14] askehill: specific runtimes could have their own particular stub code or deployment requirement
[17:14] Karlr___: I can see project types that may be mapped to specific types of runtime SCA, JBI etc but not specific runtime instances
[17:14] RobCernich: not sure if that makes a difference either
[17:15] askehill: yes, not specific instances but specific types
[17:15] Karlr___: it should be the deployment framework that deals with the runtime differences
[17:15] RobCernich: having a project type does not constrain the user to creating certain resource types
[17:15] oisin: I agree with Karl on first consideration, but I think instances are important too as the runtime in question may be configured one way that allows a policy to be enforced on one host, but maybe not on another
[17:15] Karlr___: Right, but thats still a deplyment issue not a designtime development issue
[17:16] oisin: or maybe binding choices are limited, depending on the where the runtime is in fact running
[17:16] Karlr___: I should be able to build a service in one project and deploy it to many runtimes
[17:16] askehill: I think that would only work with the most generic of services
[17:16] Karlr___: Really ??
[17:16] Karlr___: Why??
[17:16] oisin: Karl do you mean many instances of runtimes or many types of runtimes?
[17:16] askehill: call me a cynic, but once things start to get complicated, you'll find you narrow down your choice of runtimes
[17:17] askehill: so an up front association maybe require so you do not completely implement your service and then go to deploy and fail
[17:17] RobCernich: the deployment framework should prevent this
[17:17] askehill: is it not too late then?
[17:18] RobCernich: however i agree that it would be nice to limit the users activities so that they can be successful
[17:18] DavidBosschaert: Maybe leave the option open?
[17:18] DavidBosschaert: A user might have the option to completely implement a service in a generic way
[17:19] oisin: this is a question that will come up again and again - it has done so already on more than one occasion, so can we put that to one side here and have a list conversation at a later point?
[17:19] DavidBosschaert: and then make the deployment choice later?
[17:19] Karlr___: ok, I should be able to build an set of services, associate them together and then bind them to endpoints - if the target runtime does not support those spefic endpoints then the deployment framework / editor should allow me to change the endpoint definition to ones that are supported by that specific runtime..
[17:19] DavidBosschaert: Exactly
[17:19] DavidBosschaert: But also, if you know in advance that you might want to use
[17:20] DavidBosschaert: a specific feature of one ESB, restrict your options upfront.
[17:20] Karlr___: Oh yes sure, if thats a choice that the user makes, by all means
[17:20] Karlr___: But its not enforced
[17:20] DavidBosschaert: I agree
[17:20] askehill: so I think we need to define what the set of activities that a user can do without having to define a runtime then
[17:21] askehill: not now obviously
[17:23] oisin: ok, so any other points/questions on that scenario
[17:23] DavidBosschaert: I think the toplevel project (as referred to in http://www.eclipse.org/stp/sc/) should be completely...
[17:23] DavidBosschaert: agnostic as to how the individual services are created
[17:24] DavidBosschaert: Individual service implementation project might be restricted.
[17:24] oisin: i note that it's quite basic, has no assembly characteristics, but this is something we can grow to
[17:25] askehill: I wasn't quite sure if we should have gone to that level of detail in the scenario Oisin, but yip, we can grow it to include more details in that space
[17:26] oisin: that is not an issue for me, we have plenty of space for scenarios and I think fine-grained is good when we are in the business of planning milestones
[17:26] oisin: I'm hoping we will get plenty more of them
[17:27] oisin: actually one point I meant to make on the wiki: when you have entered a scenario please send a link to stp-dev, because otherwise there is no way to find it without browsing
[17:27] askehill: ok
[17:28] oisin: the second scenario has me a bit confused : is this a packaging thing for vendors that will adopt STP frameworks?
[17:28] oisin: http://wiki.eclipse.org/index.php/ Adding_an_Additional_Runtime
[17:28] askehill: No
[17:29] oisin:
[17:29] askehill: the idea behind it may have changed somewhat based on our conversation here
[17:29] askehill: I wanted to see what would be required if you had done some generic work, what would be visible if you put a new runtime in place, how the STP would be customised to reflect the features of the new runtime
[17:30] DavidBosschaert: I notice that you describe two options and are in favour of the extension point based approach...
[17:30] DavidBosschaert: I second that.
[17:31] RobCernic1 joined the chat room.
[17:31] askehill: so the scenario alludes to the STP architecture, but it ultimately covers what people who are using the tooling will get
[17:32] askehill: should I clarify this scenario somewhat?
[17:32] oisin: I think it would be helpful...
[17:33] askehill: ok, I'll follow up on it
[17:35] RobCernic1: hello?
[17:35] oisin: hi rob
[17:36] RobCernic1: sorry, my connection's a bit flaky. wasn't sure if i was kicked off again.
[17:36] oisin: scenario 3 specifically refers to jax-ws markup
[17:37] oisin: maybe that should be in the title?
[17:37] askehill: yip, I was planning to update the title
[17:37] oisin: ok
[17:37] RobCernic1: i think this is good
[17:38] RobCernic1: i would omit the fourth bullet as i think this is an internal operation not required by the user
[17:38] RobCernic1: i think there should be a piece about creating a module prior to deployment
[17:38] RobCernich left the chat room. (Read error: 104 (Connection reset by peer))
[17:39] RobCernic1: my assumption is that the sca module and subassembly are the only deployable units
[17:39] askehill: (I've edited the title and now the original is gone missing, fixing now)
[17:39] oisin: i think it may be a valid approach to have an 'implicit module' when you are in the situation of only having one service
[17:40] RobCernic1: agreed
[17:40] oisin: so for these simple cases, the assembly is effectively invisible to the user
[17:41] askehill: no point involving them with the assembly in those circumstances
[17:42] oisin: do we think that there will be some users writing services and some users creating assemblies and some users doing both?
[17:43] RobCernic1: i think so, but i don't think that fits the goals specified for these use cases
[17:43] RobCernic1: those being, take it for a quick test drive
[17:43] oisin: fair enough!
[17:44] RobCernic1: we could add a more complicated use case if necessary
[17:44] oisin: btw - the scenarios gathering is an open process, please feel free to contribute regardless of how complex your scenario will be!
[17:45] RobCernic1: are we looking for end user scenarios, extender scenarios, both?
[17:46] RobCernic1: i think extender scenarios would flow nicely into eclipse articles or white papers
[17:46] oisin: both are good, rob
[17:46] RobCernic1: and would help adoption
[17:46] oisin: and agree with your point
[17:46] oisin: on articles/etc
[17:48] oisin: BTW I have a link to an interesting thread: http:// dev.eclipse.org/mhonarc/lists/wtp-dev/msg04081.html
[17:48] oisin: this is someone adding JBI container support using the WTP facets, I'll get in touch with him.
[17:49] oisin: have we any more points about the scenarios here?
[17:50] oisin: I'll take the pause as a no
[17:51] oisin: ok. please add more scenarios - I will be doing some outreach to open source communities on this over the next couple of days.
[17:52] oisin: if there's nothing else for now we can finish up - thanks for joining!
[17:52] RobCernic1: have a good one. bye
[17:52] RobCernic1 left the chat room.
[17:52] DavidBosschaert: see ya
[17:54] askehill: ciao
[17:54] askehill left the chat room.
[17:54] Karlr___ left the chat room.