Re: [stp-pmc] Deployment Framework Doc

[Daniel Berg <danberg@xxxxxxxxxx>]

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