Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stp-pmc] Deployment Framework Doc


I don't have a problem with that.

I have talked with Arthur Ryman from a WTP standpoint.  He is in agreement that we need to get a resolution on this topic.

Regards,
Dan




Carl Trieloff <cctrieloff@xxxxxxxxxx>
Sent by: stp-pmc-bounces@xxxxxxxxxxx

04/18/2006 12:58 PM

Please respond to
cctrieloff@xxxxxxxxxx; Please respond to
STP PMC list <stp-pmc@xxxxxxxxxxx>

To
STP PMC list <stp-pmc@xxxxxxxxxxx>
cc
Subject
Re: [stp-pmc] Deployment Framework Doc






Is there any objection to cc the WTP and DTP pmc list on this thread?
Carl


David.Brandow@xxxxxxxxxx wrote:
>
> > If DTP is more flexible we should push WTP to adopt DTP's connection
> framework as their base.
> > [...]
> > I don't see a need for a third connection framework.  I am fine with
> STP defining a deployment platform but I believe it should adopt the
> WTP server connections for connecting to servers.  We shouldn't have
> multiple different frameworks within Eclipse for defining connections
> to servers.  You could even argue whether application server
> connections are different from DB connections.  Ideally both
> connections would be built on the same framework.  I am fine with a
> conversation about WTP adopting DTP for connections but I disagree
> with STP defining a new connection framework that simply "consumes"
> WTP server definitions.
>
> This seems like the most natural way of having all three projects,
> STP, DTP and WTP work together.  If WTP adopted DTP for connections,
> then we'd have a common connection framework.  I don't believe DTP can
> adopt WTP's connection framework, WTP its too JEE-specific, as I
> understand it, the DTP connection framework is more general.  So it
> seems fairly straightforward to me that if we can convince WTP to
> adopt DTP's connection framework, say in the Callisto time frame, all
> three can integrate together quite naturally and we can move on to the
> next issue.
>
> -----------------------------------------------
> Keep your stick on the ice,
>
> David Brandow
> Sybase EAServer Engineering
>
>
>
> *Daniel Berg <danberg@xxxxxxxxxx>*
> Sent by: stp-pmc-bounces@xxxxxxxxxxx
>
> 04/13/2006 06:19 PM
> Please respond to
> STP PMC list <stp-pmc@xxxxxxxxxxx>
>
>
>                  
> To
>                  STP PMC list <stp-pmc@xxxxxxxxxxx>
> cc
>                  STP PMC list <stp-pmc@xxxxxxxxxxx>, stp-pmc-bounces@xxxxxxxxxxx
> Subject
>                  Re: [stp-pmc] Deployment Framework Doc
>
>
>
>                  
>
>
>
>
>
>
> Hi Karl,
>
> I have some responses but I think it will be hard to in-line them
> below.  So I will pull up the portions that I have a comment (let's
> see if this is not too confusing).
>
> <karl>WTP will be adopting DTP post-Callisto as a replacement for the
> RDB functionality.  This means WTP will have a direct dependency on
> DTP.</karl>
>
> Yes I realize this fact.  Will the WTP server connections be using the
> DTP connection framework as well?
>
> <karl>Could you please elaborate?  Does WTP contain server
> implementations for ESBs?  Does it contain server implementations for
> SCA containers, JBI, etc.?  I can understand the overlap with respect
> to JEE, but I don't think that will be as large an effort as you think
> (primarily because, this would only need to be done once, delegating
> to the WTP APIs, not for every server implementation).  (Internally,
> we have been able to successfully bridge these two frameworks with
> minimal effort.)</karl>
>
> WTP server tooling has an extensible mechanism for defining server
> connections.  Currently there are no ESBs defined as I am aware or SCA
> containers or JBI containers.  For the most part they are Web
> application servers and JEE servers.  I don't think there is a reason
> it couldn't be used for the others.  I agree that STP needs to be able
> to bridge the efforts between WTP and DTP but at the same time I don't
> see a need for a third server connection framework.  Are there
> concrete reasons for not using WTP server tooling for defining server
> connections?  
>
> If STP defines a third way to define server connections then I assume
> there will not be any integration with WTP tooling.  So there would be
> a Servers View in WTP that would only show some of the servers.  Would
> STP need to define another view for servers?  Wouldn't this be
> confusing to clients?
>
> <karl>Also, has it been decided that STP will apply WTP project facets
> to services projects? </karl>
>
> Not completely but I don't see a reason why we would not.  This would
> give us better integration with the WTP tools.  Plus we would get the
> benefit of describing new capabilities that would extend the support
> beyond just WTP.  A facet describes a capability that will be
> supported by the project.  This helps to setup builpath dependencies
> and aids in determining what can or cannot be done within a project
> (i.e., whether the capability exists or not).
>
> <karl>I agree that WTP is the standard for application server
> integration.  However, STP will be supporting more architectures than
> application servers, but the intention would be to ensure that the WTP
> model is supported by the connection frameworks. <karl>
>
> You are absolutely correct but WTP does have a generic server
> connection framework.  Why create another?  If DTP is more flexible we
> should push WTP to adopt DTP's connection framework as their base.
>  This is all necessary to provide a tighter integration between the
> projects.  We don't want STP to look like a tool that was thrown into
> the mix that doesn't integrate well at both the model level and the UI
> level.
>
> <karl>I do not think that the assessment that the package profile and
> package are closely linked to the implementations is correct.  The
> package profile references the implementations.  The package
> references a package profile and is closely linked to the targeted
> server architecture.  (Based on the fact that we are using SCA models
> to represent assemblies and implementations, and that these are not
> specific to any particular implementation type and that the SCA
> specification does not specify anything with respect to package
> structure or deployment.) </karl>
>
> I think we are on the same page but there may be some confusion on the
> terminology.  When I stated that it was linked to the implementation I
> meant that the implementation of a ModuleComponent (e.g., a JAR, an
> EAR, a WAR, etc.) would have a PackageProfile defined for it.
>
> Since a ModuleComponent is the configuration of an implementation
> (e.g., a JAR, etc.) do you think there would be different
> PackageProfiles for each ModuleComponent even if they point to the
> same implementation?
>
> <karl>Logical packages can be configured directly within the
> deployment file editor (this is accomplished through a configurable
> package extension, which simply adds configuration capabilities to a
> logical package).  The package constructor associated with that
> logical type and deployment driver for the targeted server is used to
> validate the package as applicable to the target server (e.g. can
> verify that certain capabilities are installed on the target server
> which are required by the package). </karl>
>
> What I was trying to express with my 3rd question was whether amin
> configuration could be captured for the target servers.  Also would
> the editor generate the necessary scripts for doing the installation
> onto the servers and configuring the servers with the necessary data
> to support the application?
>
> <karl>Overall, I agree that there is overlap between the proposed
> framework and the framework provided by WTP.  However, I believe this
> framework is more flexible than the framework provided by WTP.
>  Furthermore, I think the two frameworks are fairly compatible with
> each other and could peacefully coexist.</karl>
>
> I don't see a need for a third connection framework.  I am fine with
> STP defining a deployment platform but I believe it should adopt the
> WTP server connections for connecting to servers.  We shouldn't have
> multiple different frameworks within Eclipse for defining connections
> to servers.  You could even argue whether application server
> connections are different from DB connections.  Ideally both
> connections would be built on the same framework.  I am fine with a
> conversation about WTP adopting DTP for connections but I disagree
> with STP defining a new connection framework that simply "consumes"
> WTP server definitions.  I think this will be very confusing to the
> population using the STP and WTP tools together.
>
> Regards,
> Dan
>
> -------------------------------------------------
> Daniel Berg
> Rational SOA Tooling Lead
> (919) 486-0047
> T/L     526-0047
>
> *Karl.Reti@xxxxxxxxxx*
> Sent by: stp-pmc-bounces@xxxxxxxxxxx
>
> 04/13/2006 04:11 PM
> Please respond to
> STP PMC list <stp-pmc@xxxxxxxxxxx>
>
>                  
> To
>                  STP PMC list <stp-pmc@xxxxxxxxxxx>
> cc
>                  
> Subject
>                  Re: [stp-pmc] Deployment Framework Doc
>
>
>
>
>                  
>
>
>
>
>
>
>
> Hi Dan,
>
> Some inline comments from both myself and Rob Cernich ..
>
> I refer to requirements that we need to support in STP, although these
> have not been publically declared at this point, the following is a
> list to get the ball rolling..
>
>     * clean separation between design metadata and server runtime
>     * allow design metadata to be packaged as required for the target
>       server
>     * package definition
>     * package configuration
>     * server introspection
>     * server capability support
>     * repeatable deployment definition
>     * deployment to one or more remote servers concurrently
>     * remote server management hooks
>     * support for deployment across multiple different runtimes
>     * and more...
>
>
> Regards
> Karl
>
>
> > 1)  The first issue that I want to bring up is around the technology
> > being used for the connections (i.e., using DTP).
> >
> > Question
> > Have you reconciled how the server connections align with the WTP
> > server tooling and project facet support?
> >
> > Issue
> > This approach may be risky since it aligns STP on top of the Data
> > Tools Platform for server integration; all of the existing J2EE
> > types (*.ear, *.war, EJBs, etc) are aligned on the WTP Server API.
> > The DTP and WTP API have some similarities (for instance DTP has a
> > loosely defined concept of a "Technology Type" that is mapped to a
> > "Server Type"; this is conceptually similar to the Project Facets in
> > WTP). Following the current plan of action may make the J2EE
> > integration story much more difficult; for instance, will we have to
> > duplicate all of the J2EE Server integration on these new "DTP-
> > flavored" "Server Connection Profiles" ?
>
> WTP will be adopting DTP post-Callisto as a replacement for the RDB
> functionality.  This means WTP will have a direct dependency on DTP.
>
> As for "technology types," DTP does not define these.  These are
> defined through the deployment framework.
>
> I agree that an analysis needs to be done to see where duplicate,
> differing solutions exist.  Ideally, these issues would be worked out
> between the three projects.
>
>
> > I think re-using DTP for Database integration makes alot of sense; I
> > don't think reusing any Server integration for any sort of ESB or
> > Application Server makes sense. With the current deployment proposal
> > we may have alot of work down the road; either by us (or someone
> > else in STP) having to duplicate all of the J2EE server integration
> > OR by STP having to port everything over from their DTP Connection
> > Profile scheme to the WTP Project Facets. Either way, it's not a
> good story.
>
> The connectivity framework within DTP is not specific to DB servers,
> any servers can be supported by the frameworks.
>
> Could you please elaborate?  Does WTP contain server implementations
> for ESBs?  Does it contain server implementations for SCA containers,
> JBI, etc.?  I can understand the overlap with respect to JEE, but I
> don't think that will be as large an effort as you think (primarily
> because, this would only need to be done once, delegating to the WTP
> APIs, not for every server implementation).  (Internally, we have been
> able to successfully bridge these two frameworks with minimal effort.)
>
> Also, has it been decided that STP will apply WTP project facets to
> services projects?
>
> Once again, I agree that there is some investigation that needs to be
> done here.
>
> > In addition, the usability story may not be ideal if we go with DTP
> > as existing J2EE developers who use WTP (or WTP based products) will
> > be used to a particular way of creating application server artifacts
> > and associating those with application servers. Existing WTP users
> > who pick up STP will have to follow a different path (via the
> > Database Server configuration wizards) in order to create ESB or SCA
> > deployable projects.
>
> Post-Callisto these developers will be using the connectivity
> framework provided by DTP, at least for creating DB connections, but
> hopefully for more if we can ensure interoperability.  Also, STP is
> targeting more than just JEE developers.
>
> > This proposal *builds* on the DTP Connection Profile scheme; which
> > means that STP will be building and supporting yet another server
> > integration/deployment story with this proposal. Clearly WTP is the
> > platform for Application Server integration; the API is there,
> > tested, and for better or worse it is the standard.
>
> I agree that WTP is the standard for application server integration.
>  However, STP will be supporting more architectures than application
> servers, but the intention would be to ensure that the WTP model is
> supported by the connection frameworks.
>
> I am not sure I would agree with the statement regarding the WTP apis
> being a standard, and even if it is, we need to ensure that whatever
> we use meets the requirements that we set for it rather than just
> using whatever happens to be available.
>
> I think it is important to point out that the connectivity framework
> within DTP was designed to allow users to create connections to any
> type of server, regardless of deployment capabilities.  The deployment
> framework was built atop connectivity to provide deployment
> capabilities to connections where applicable. The real point here is
> that the deployment framework is far broader in capability than that
> currently supported by WTP - I btw, would have no issue with this
> being moved into WTP at some point, but for the time being, we need to
> ensure that we can support the necessary requirements for STP.
>
>
> > 2) I don't see a connection between the definition of a "Package"
> > and the core model ModuleComponent.
> >
> > Question:
> > Is there a scenario that shows how a Module is constructed,
> > assembled into a Subsystem, and then deployed?  
> >
> > Your PackageProfile and Package must be closely linked with the
> > implementations used for ModuleComponents (hopefully this will
> > change to simply Component) defined within a Subsystem.  It is then
> > the Subsystem that you want to deploy and create Packages for each
> > implementation defined by the ModuleComponents.
> > I would like to see the scenario that ties the construction and
> > deployment efforts together so there is a seamless story and vision
> > that we are presenting.
>
> Our thinking would be that a ModuleComponent would be aligned with a
> package profile since this artifact defines the services and
> implementations which are to be packaged and deployed (and, by
> extension a Subsystem, since this is also a deployable unit).  Because
> the structure of the deployable package is dependent upon the
> architecture of the target server, the construction of that package
> would be handled by a package constructor associated with a deployment
> driver for that server's architecture.  In this scenario, the design
> metadata can be created without regard to the architecture of the
> target server (e.g. SCA, JBI, ESB, etc.; obviously, this is a little
> overly simplistic, but probably covers > 80%).  (It should also be
> noted that even if a server supports a logical package type (i.e.
> package profile), but that package would include artifacts that are
> not supported by the server, the server can report this back through
> the framework and that package profile would show as not supported by
> the server (i.e. the user would be prevented from deploying the
> package to that server.).)
>
> I do not think that the assessment that the package profile and
> package are closely linked to the implementations is correct.  The
> package profile references the implementations.  The package
> references a package profile and is closely linked to the targeted
> server architecture.  (Based on the fact that we are using SCA models
> to represent assemblies and implementations, and that these are not
> specific to any particular implementation type and that the SCA
> specification does not specify anything with respect to package
> structure or deployment.)
>
> In short, the deployment framework was designed to allow a clear,
> clean separation between design metadata and package structure.  This
> approach is advantageous for STP since one of its charters is to
> support SCA runtimes and SCA does not specify a common package
> structure.  Given that, this approach allows adopters to create
> package constructors specific to their runtime architecture without
> having to modify design tooling.
>
>
>
> > 3)  On slide 10 you indicate that there will be a Deployment File
> editor.
> >
> > Question:
> > Will this editor allow for the definition of configuration elements
> > on the application servers which are in support of the packages
> > being deployed (e.g.., data sources)?
>
> The deployment file editor is a simple editor which allows packages
> (logical or physical) to be targeted for deployment to specific
> servers.  This editor also allows logical packages to be reconfigured
> for deployment to a specific server, so long as configuration is
> supported by the package extension.  This editor also allows multiple
> packages to be targeted to multiple servers, deploying them all as a
> single unit of work.
>
> As for the definition of configuration elements as applies to
> application servers, this capability is supported through the package
> and deploy driver extensions depending on what type of package,
> logical or physical, is being deployed.
>
> Logical packages can be configured directly within the deployment file
> editor (this is accomplished through a configurable package extension,
> which simply adds configuration capabilities to a logical package).
>  The package constructor associated with that logical type and
> deployment driver for the targeted server is used to validate the
> package as applicable to the target server (e.g. can verify that
> certain capabilities are installed on the target server which are
> required by the package).
>
> For physical packages, the deploy driver provides verification prior
> to deployment (this is also true of packages constructed from logical
> package profiles).  The physical package extension also provides a
> certain amount of validation.  For example, in a JEE environment an
> EAR file containing vendor specific configuration information could be
> identified by a generic EAR package extension and by a vendor specific
> package extension as supported, while other vendor specific package
> extensions might choose not to identify the package as supported.
>  (Note, I'm just using JEE as an example since it is pretty well
> understood.)
>
> Overall, I agree that there is overlap between the proposed framework
> and the framework provided by WTP.  However, I believe this framework
> is more flexible than the framework provided by WTP.  Furthermore, I
> think the two frameworks are fairly compatible with each other and
> could peacefully coexist.
>
> *Daniel Berg <danberg@xxxxxxxxxx>*
> Sent by: stp-pmc-bounces@xxxxxxxxxxx
>
> 04/13/2006 12:00 PM
> Please respond to
> STP PMC list <stp-pmc@xxxxxxxxxxx>
>
>
>                  
> To
>                  stp-pmc@xxxxxxxxxxx
> cc
>                  
> Subject
>                  Re: [stp-pmc] Deployment Framework Doc
>
>
>
>
>
>                  
>
>
>
>
>
>
>
>
> Hi Karl,
>
> This is good to see.  I do have some comments.
>
> 1)  The first issue that I want to bring up is around the technology
> being used for the connections (i.e., using DTP). *
>
> Question*
> Have you reconciled how the server connections align with the WTP
> server tooling and project facet support? *
>
> Issue*
> This approach may be risky since it aligns STP on top of the Data
> Tools Platform for server integration; all of the existing J2EE types
> (*.ear, *.war, EJBs, etc) are aligned on the WTP Server API. The DTP
> and WTP API have some similarities (for instance DTP has a loosely
> defined concept of a "Technology Type" that is mapped to a "Server
> Type"; this is conceptually similar to the Project Facets in WTP).
> Following the current plan of action may make the J2EE integration
> story much more difficult; for instance, will we have to duplicate all
> of the J2EE Server integration on these new "DTP-flavored" "Server
> Connection Profiles" ?
>
> I think re-using DTP for Database integration makes alot of sense; I
> don't think reusing any Server integration for any sort of ESB or
> Application Server makes sense. With the current deployment proposal
> we may have alot of work down the road; either by us (or someone else
> in STP) having to duplicate all of the J2EE server integration OR by
> STP having to port everything over from their DTP Connection Profile
> scheme to the WTP Project Facets. Either way, it's not a good story.
>
> In addition, the usability story may not be ideal if we go with DTP as
> existing J2EE developers who use WTP (or WTP based products) will be
> used to a particular way of creating application server artifacts and
> associating those with application servers. Existing WTP users who
> pick up STP will have to follow a different path (via the Database
> Server configuration wizards) in order to create ESB or SCA deployable
> projects.
>
> This proposal *builds* on the DTP Connection Profile scheme; which
> means that STP will be building and supporting yet another server
> integration/deployment story with this proposal. Clearly WTP is the
> platform for Application Server integration; the API is there, tested,
> and for better or worse it is the standard.
>
> 2) I don't see a connection between the definition of a "Package" and
> the core model ModuleComponent. *
>
> Question:*
> Is there a scenario that shows how a Module is constructed, assembled
> into a Subsystem, and then deployed?  
>
> Your PackageProfile and Package must be closely linked with the
> implementations used for ModuleComponents (hopefully this will change
> to simply Component) defined within a Subsystem.  It is then the
> Subsystem that you want to deploy and create Packages for each
> implementation defined by the ModuleComponents.
> I would like to see the scenario that ties the construction and
> deployment efforts together so there is a seamless story and vision
> that we are presenting.
>
> 3)  On slide 10 you indicate that there will be a Deployment File
> editor. *
>
> Question:*
> Will this editor allow for the definition of configuration elements on
> the application servers which are in support of the packages being
> deployed (e.g.., data sources)?
>
> Regards,
> Dan_______________________________________________
> stp-pmc mailing list
> stp-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/stp-pmc
> _______________________________________________
> stp-pmc mailing list
> stp-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/stp-pmc
> _______________________________________________
> stp-pmc mailing list
> stp-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/stp-pmc
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> stp-pmc mailing list
> stp-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/stp-pmc
>  

_______________________________________________
stp-pmc mailing list
stp-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-pmc


Back to the top