I think there is some confusion with
the introspector extensions. The introspector extension point is
intended to be implemented by groups that want to provide a new "implementation"
type to be assembled into the tooling (e.g., POJO, BPEL, PHP, C, Cobol,
etc.). The purpose of the introspector is to "introspect"
a specific instance of an implementation and provide the ComponentType
definition. The ComponentType definition describes the services,
references, and properties that are available and configurable for this
implementation. The services and references have an interface. The
interface can be any interface type that is registered with the tooling
(e.g., Java or WSDL port type). There are also apis on the introspector
to allow the tool to update the ComponentType definition and "push"
changes back into the implementation as well as react to changes in the
implementation and "push" the changes into the in-memory ComponentType.
So indicating that we would have an
introspector for WSDL doesn't make any sense because WSDL is just another
interface and not an implementation.
Hope this helps.
Oisin Hurley <ohurley@xxxxxxxx> Sent by: stp-dev-bounces@xxxxxxxxxxx
04/05/2006 02:53 PM
Please respond to
STP Dev list <stp-dev@xxxxxxxxxxx>
STP Dev list <stp-dev@xxxxxxxxxxx>
[stp-dev] STP IRC log 5 April 06
[17:03] oisin: hi all
[17:03] oisin: karl - i see you have got around your firewall
[17:04] Karlr: the easy way - I am at home
[17:05] Karlr: So whats on the agenda for today ?
[17:06] oisin: the agenda is open today - so let me know what you
would like to talk about. I have some topics....
[17:06] oisin: 1. volunteers to be buildmasters, lack thereof
[17:07] oisin: 2. our choices for runtimes as part of deployment support
[17:07] oisin: 3. what requirements for project layouts
[17:08] oisin: 4. what choices around 'introspectors' for extending
the STP assembly model
[17:08] oisin: anything from anyone else?
[17:08] DavidBosschaert: Just wondering about the ALF demo after this
IRC, is there a voice connection with that too?
[17:09] DavidBosschaert: (Not mentioned in the email)
[17:10] oisin: I don't see one in the email, I will send Tim a
message to confirm
[17:10] DavidBosschaert: We could use our IONA bridge, if needed.
[17:12] oisin: any other items?
[17:12] oisin: seeing non...
[17:12] oisin: Item 1
[17:13] oisin: again I say - volunteer to be a buildmaster to get
this stuff off the ground
[17:13] oisin: Naci and his guys have done great work in getting the
WTP system going on their local machine
[17:13] oisin: and they deserve our support
[17:14] askehill: if people are fairly patient I can help out in this
space and use it to come up to speed with the CVS repository and
[17:14] RobCernich: i'm willing to volunteer once i've met my current
[17:14] oisin: adrian and rob truly you are both gentlemen
[17:14] oisin: adrian: naci is a very patient guy and I will put you
[17:15] oisin: rob: tell us about your current obligations....
[17:15] RobCernich: i'm working on our deployment contribution at the
[17:15] RobCernich: in addition to dtp and internal tasks
[17:16] RobCernich: i'm spread pretty thin at the moment
[17:16] oisin: great - how is the deployment contrib looking? This is
closely related to #2 in my list. Can you give us a quick outline of
the current capabilities, i.e. what runtimes it can connect/deploy to?
[17:16] RobCernich: (i feel like the last human in that new episode
of dr who :-))
[17:17] RobCernich: i'm in the process of refactoring at the moment
[17:17] RobCernich: the contribution provides a framework for
building deployment capabilities into eclipse
[17:18] RobCernich: it provides extension points for identifying
packages within the workspace
[17:18] RobCernich: packages may be "physical" or "logical"
of better terms)
[17:19] RobCernich: a logical package can be thought of as a resource
defining a package, e.g. an sca assembly model instance
[17:19] oisin: right rob will get back to us I'm sure
[17:20] RobCernich: the framework also provides an extension point
for adding deployment capabilities to a connection profile (dtp
[17:21] RobCernich: this extension point can include a package
builder that is used to build one of these logical packages for
deployment to the targeted server
[17:22] DavidBosschaert: Could the connection profile be an appserver
(as opposed to database) or other type of container?
[17:22] RobCernich: from a supported runtime perspective, we would
need to implement these extensions for the servers we decide to
support "out of the box"
[17:22] RobCernich: yes
[17:22] RobCernich: a connection profile can be used to represent any
type of server
[17:22] oisin: We're looking at 'ESB's being our runtimes
[17:23] RobCernich: this should be possible
[17:23] oisin: So - here's some of the options: Tuscany, Celtix,
JBI, JBoss ESB
[17:23] Karlr: this is possible as we have implemented a connection
profile to out own 'ESB'
[17:25] RobCernich: is there a question in there oisin
[17:27] oisin: i guess that it is not possible to have an 'exemplar'
ESB as part of the framework contrib...because there is no standard
[17:28] oisin: so we will need to drill down real quickly on some
exemplars to understand how it hangs together
[17:28] RobCernich: i think we can provide an example
[17:29] oisin: which strongly indicates a good need for documentation
-- although an example is good
[17:29] RobCernich: from a design perspective
[17:30] RobCernich: we should define a package artifact. i think
we've already decided this would be the sca assembly model
[17:30] RobCernich: i think it would be beneficial to have this
example built atop a base implementation that could be reused for
[17:30] oisin: I'm not sure that the assembly model is exactly
suitable as a package artifact, although I don't know what your
package model requires
[17:31] RobCernich: not as an artifact, but as the input to a package
[17:31] oisin: that makes sense
[17:31] RobCernich: these will probably need to be customized for
[17:31] oisin: yes, I imagine that there will be some kind of model
visitation and reforming for particular container requirements
[17:31] RobCernich: however, there is the possibility for reuse for
containers that specify a package artifact
[17:32] oisin: example?
[17:32] RobCernich: jbi
[17:32] RobCernich: same would go for deployment api's
[17:32] RobCernich: e.g. app servers
[17:32] dparikh joined the chat room.
[17:33] RobCernich: base impl's can/should be provided for reuse in
these cases (note app servers, just given as an example of a
container with a specified deployment api)
[17:33] oisin: of course, again that seems sensible
[17:34] oisin: hi devang: thank you for posting that UML diagram
[17:34] dparikh: no problem
[17:35] oisin: we were just discussion deployment runtimes
[17:37] oisin: so we have introspector --> assembly model
package builder --> deployment framework --> connection profile -->
[17:38] oisin: has everyone read the assembly code contrib and know
what an introspector is?
[17:38] oisin: say no now
[17:38] oisin: if you haven't
[17:39] askehill: I haven't
[17:39] davidbrpr joined the chat room.
[17:39] oisin: adrian: https://bugs.eclipse.org/bugs/show_bug.cgi?
[17:40] askehill: ok, I'll follow up on this later on. thanks.
[17:40] oisin: an introspector has the responsibility for visiting
potential model contributors and extracting relevant information, for
example looking over a .java file and obtaining model elements based
[17:42] oisin: in the contribution, there is a test introspector and
a .module file introspector
[17:42] oisin: there is a java introspector in the works as a further
[17:42] oisin: devang: perhaps you would like to tell us more about
[17:43] dparikh: yes example java implementation with introspection
framework is in works for contribution
[17:44] oisin: ballpark arrival time?
[17:44] dparikh: I will get back and post on mailing list for that one
[17:45] oisin: many thanks! I for one am very keen to see a full
example of how to implement one of these guys
[17:46] oisin: devang: are you guys considering contributing a WSDL
[17:48] dparikh: WSDL introspector ? not sure what you mean.
Introspection produces ComponentType from various implementation e.g
Java, BPEL, C++ ...
[17:49] dparikh: short answer no we are not currently considering
[17:51] oisin: just probing a bit here -- a ComponentType needs to
refer to an interface so I guess that something needs to be done to
get that information in there
[17:52] oisin: so if the only way to construct a ComponentType is
thru introspectors, then there will be some requirement to do it for
[17:52] oisin: or to find some out-of-band approach
[17:52] oisin: would this be a fair comment? or am I making an error?
[17:53] dparikh: Specification also talks about standalone
resource .componenttype file to describe ComponentType
[17:54] oisin: yes
[17:55] oisin: so basically if you are doing WSDL-first then you are
required to do your WSDL separately, then make a .componenttype file
and manually put in a pointer to your WSDL in there?
[17:56] dparikh: So in componenttype file you will describe Services,
References and properties
[17:57] dparikh: In Service definition you will refere to WSDL for
[17:57] dparikh: here is the example for java
[17:57] dparikh: <service name="MyValueService"> <interface.java
[17:58] dparikh: and for WSDL <service name="MyValueService">
<interface.wsdl porttype="..."/> </service>
[17:59] askehill left the chat room.
[17:59] oisin: ok -- so it's clear that we need to provide some
tooling that means that developers can create wsdl interfaces, then
connect up to the model through the .componenttype introspection
[18:00] dparikh: I think WTP has tooling for WSDL interface creation
[18:00] oisin: BTW -- I've mailed the call-in phone number for the
ALF presentation to the dev list
[18:00] oisin: a reminder: https://serena.webex.com/serena/j.php?
[18:00] oisin: a reminder: Meeting password: alfdev
[18:01] oisin: a reminder: Phone +1-303-928-3232 ID: 6053141#
[18:01] oisin: yes WTP does have such a tool
[18:02] oisin: on an organizational note -- the ALF webex is starting
now, so we will have to leave this discussion for the moment and take
anything we need to the dev list.
[18:02] oisin: thanks for coming online all
[18:02] dparikh: thanks
stp-dev mailing list