Skip to main content

[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:
[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 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: 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:// [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.

Back to the top