Re: [stp-dev] STP IRC log 5 April 06

[Daniel Berg <danberg@xxxxxxxxxx>]

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

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>

To	STP Dev list <stp-dev@xxxxxxxxxxx>
cc
Subject	[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  
build system
[17:14] RobCernich: i'm willing to volunteer once i've met my current  
obligations
[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  
in contact
[17:15] oisin: rob: tell us about your current obligations....
[17:15] RobCernich: i'm working on our deployment contribution at the  
moment
[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"
(for lack  
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  
connectivity)
[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  
other containers
[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  
builder
[17:31] oisin: that makes sense
[17:31] RobCernich: these will probably need to be customized for  
particular containers
[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
 
yesterday
[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 -->
 
runtime
[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?
id=132747
[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  
upon annotations
[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  
contribution
[17:42] oisin: devang: perhaps you would like to tell us more about  
that?
[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
 
introspector?
[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  
WSDL introspector
[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  
WSDL definitions
[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  
interface
[17:57] dparikh: here is the example for java
[17:57] dparikh: <service name="MyValueService"> <interface.java
 
interface="services.myvalue.MyValueService"/> </service>
[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?
S=571917605
[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
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev