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