You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2009/05/07 09:21:46 UTC
Node usage of the workspace and implementation-node modules
Currently the node-impl module has dependencies on implementation-node
and the workspace modules, I think its worth exploring if thats
necessary. In r772526 i've created a new node-impl2 module thats a
copy of node-impl but with no dependencies on implementation-node or
the workspace modules. It does include 4 classes copied from
workspace-impl and they're still in the o.a.t.s.workspace package to
make that obvious. Comparing the two node-impl modules i think this
makes node-impl2 significantly cleaner and shows that having those
contribution classes in workspace-impl may not be the correct place
and they'd be better in one of the contribution* modules.
Any comments?
...ant
Re: Node usage of the workspace and implementation-node modules
Posted by Raymond Feng <en...@gmail.com>.
+1 on the summary from Simon.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Friday, May 08, 2009 1:23 AM
To: <de...@tuscany.apache.org>
Subject: Re: Node usage of the workspace and implementation-node modules
> On Fri, May 8, 2009 at 8:02 AM, Mike Edwards
> <mi...@gmail.com> wrote:
>> Raymond Feng wrote:
>>>
>>> Hi,
>>>
>>> The workspace and workspace-impl modules were introduced to model a
>>> collection of contributions that are added to an SCA domain. Basically,
>>> Tuscany allows
>>> you to provide a "workspace.xml" to pre-define a list of contributions
>>> for
>>> an SCA domain. And the workspace model provides the "install
>>> contribution"
>>> and "uninstall contribution" services for the SCA domain. It functions
>>> as
>>> the "contribution service".
>>>
>>> Furthermore, the "workspace" becomes a special archive of artifacts that
>>> are SCA contributions. Now the SCA contribution is just an artifact that
>>> is
>>> identified by the contribution URI and can be loaded by the URL. The
>>> ContributionContentProcessor from workspace-impl is a
>>> URLArtifactProcessor
>>> that uses the ContributionScannerExtensionPoint to parse contributions
>>> in
>>> different packaging schemes such as Folder, JAR, or ZIP.
>>>
>>> The other player in the SCA domain management is the Node. Node is a
>>> configuration of a runtime (like a "SCA virtual machine") that is
>>> capable of
>>> running an SCA composite application. The Node configuration includes
>>> the
>>> base URI for protocols supported by a given SCA binding. It also defines
>>> a
>>> list of contributions and a deployable composite that make up the SCA
>>> composite application. At this moment, the node is modeled as
>>> "implementation.node" (see [3]). It doesn't seem very natural to me.
>>> Maybe
>>> we should use a different way, such as "node.xml" and NodeConfiguration
>>> model.
>>>
>>> The SCA domain manager is developed as an SCA application. It manages
>>> contributions, composites and nodes in the SCA domain. You can add
>>> contributions to the SCA domain. The SCA domain manager can then load
>>> the
>>> contributions, find the deployable composites, resolve the dependencies
>>> as
>>> well as the wirings. A resolved SCA composite application can then be
>>> deployed to the SCA node. To provide remote access, SCA domain manager
>>> uses
>>> binding.atom and packages the messages as ATOM feeds. See [1] and [2]
>>> for
>>> more details.
>>>
>>> I understand we also desire a more dynamic way to constitute an SCA
>>> domain. But conceptually, all the underlying domain level services stay
>>> the
>>> same. It's a matter of how the Workspace/Contribution/Composite/Node
>>> models
>>> are built, statically or dynamically in a centralized or distributed
>>> fashion.
>>>
>>> [1]
>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Composite+Application+Deployment+with+SCA+Domain
>>> [2]
>>> http://www.ibm.com/developerworks/webservices/library/ws-sca-tuscany/index.html
>>> [3]
>>> https://svn.apache.org/repos/asf/tuscany/java/sca/modules/implementation-node/src/test/resources/org/apache/tuscany/sca/implementation/node/xml/TestNode.composite
>>>
>>> Thanks,
>>> Raymond
>>>
>> Raymond,
>>
>> I am happy with the idea of the workspace as a way of coordinating
>> numbers
>> of contributions.
>>
>> The thing that I find VERY odd in the current arrangements is that the
>> *MAIN* code for reading an individual contribution is in the module
>> workspace-impl, with some of its interfaces defined in module
>> "workspace".
>>
>> Meanwhile, there is a module called "contribution" that does not contain
>> the
>> actual code for processing a contribution, but mostly interfaces used by
>> processors for things that you might find in a contribution.
>>
>> I think that this should be reorganized, so that actual contribution
>> processing code is in "contribution" and that "workspace-impl" has code
>> for
>> handling workspaces over the top of individual contributions.
>>
>> Yours, Mike.
>>
>
> I think I'm agreeing with Mike here.
>
> Contribution* modules - process individual contributions gets my +1
> Workspace* modules - process a collection of contributions (I would
> include in this the cross-contribution dependency building stuff) also
> gets my +1
>
> A small adjustment. Not that different from what we have now.
>
> Now, implementation.node. This is not a question of dependency but
> function. I don't like that we use implementation.node in the way it
> is currently used to represent node default configuration. At best
> it's confusing. If the composite that describes a node were describing
> the system services exposed by the node then fair game but that is not
> the case now. However I fully expect this to be discussed and refined
> during the process of implementing OASIS compliant domain function so
> don't think we need to come to a conclusion during this more abstract
> module dependency/structure discussion. So I suggest we defer this
> part for another thread.
>
> my 2c
>
> Simon
>
Re: Node usage of the workspace and implementation-node modules
Posted by Simon Laws <si...@googlemail.com>.
On Fri, May 8, 2009 at 8:02 AM, Mike Edwards
<mi...@gmail.com> wrote:
> Raymond Feng wrote:
>>
>> Hi,
>>
>> The workspace and workspace-impl modules were introduced to model a
>> collection of contributions that are added to an SCA domain. Basically,
>> Tuscany allows
>> you to provide a "workspace.xml" to pre-define a list of contributions for
>> an SCA domain. And the workspace model provides the "install contribution"
>> and "uninstall contribution" services for the SCA domain. It functions as
>> the "contribution service".
>>
>> Furthermore, the "workspace" becomes a special archive of artifacts that
>> are SCA contributions. Now the SCA contribution is just an artifact that is
>> identified by the contribution URI and can be loaded by the URL. The
>> ContributionContentProcessor from workspace-impl is a URLArtifactProcessor
>> that uses the ContributionScannerExtensionPoint to parse contributions in
>> different packaging schemes such as Folder, JAR, or ZIP.
>>
>> The other player in the SCA domain management is the Node. Node is a
>> configuration of a runtime (like a "SCA virtual machine") that is capable of
>> running an SCA composite application. The Node configuration includes the
>> base URI for protocols supported by a given SCA binding. It also defines a
>> list of contributions and a deployable composite that make up the SCA
>> composite application. At this moment, the node is modeled as
>> "implementation.node" (see [3]). It doesn't seem very natural to me. Maybe
>> we should use a different way, such as "node.xml" and NodeConfiguration
>> model.
>>
>> The SCA domain manager is developed as an SCA application. It manages
>> contributions, composites and nodes in the SCA domain. You can add
>> contributions to the SCA domain. The SCA domain manager can then load the
>> contributions, find the deployable composites, resolve the dependencies as
>> well as the wirings. A resolved SCA composite application can then be
>> deployed to the SCA node. To provide remote access, SCA domain manager uses
>> binding.atom and packages the messages as ATOM feeds. See [1] and [2] for
>> more details.
>>
>> I understand we also desire a more dynamic way to constitute an SCA
>> domain. But conceptually, all the underlying domain level services stay the
>> same. It's a matter of how the Workspace/Contribution/Composite/Node models
>> are built, statically or dynamically in a centralized or distributed
>> fashion.
>>
>> [1]
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Composite+Application+Deployment+with+SCA+Domain
>> [2]
>> http://www.ibm.com/developerworks/webservices/library/ws-sca-tuscany/index.html
>> [3]
>> https://svn.apache.org/repos/asf/tuscany/java/sca/modules/implementation-node/src/test/resources/org/apache/tuscany/sca/implementation/node/xml/TestNode.composite
>>
>> Thanks,
>> Raymond
>>
> Raymond,
>
> I am happy with the idea of the workspace as a way of coordinating numbers
> of contributions.
>
> The thing that I find VERY odd in the current arrangements is that the
> *MAIN* code for reading an individual contribution is in the module
> workspace-impl, with some of its interfaces defined in module "workspace".
>
> Meanwhile, there is a module called "contribution" that does not contain the
> actual code for processing a contribution, but mostly interfaces used by
> processors for things that you might find in a contribution.
>
> I think that this should be reorganized, so that actual contribution
> processing code is in "contribution" and that "workspace-impl" has code for
> handling workspaces over the top of individual contributions.
>
> Yours, Mike.
>
I think I'm agreeing with Mike here.
Contribution* modules - process individual contributions gets my +1
Workspace* modules - process a collection of contributions (I would
include in this the cross-contribution dependency building stuff) also
gets my +1
A small adjustment. Not that different from what we have now.
Now, implementation.node. This is not a question of dependency but
function. I don't like that we use implementation.node in the way it
is currently used to represent node default configuration. At best
it's confusing. If the composite that describes a node were describing
the system services exposed by the node then fair game but that is not
the case now. However I fully expect this to be discussed and refined
during the process of implementing OASIS compliant domain function so
don't think we need to come to a conclusion during this more abstract
module dependency/structure discussion. So I suggest we defer this
part for another thread.
my 2c
Simon
Re: Node usage of the workspace and implementation-node modules
Posted by Mike Edwards <mi...@gmail.com>.
Raymond Feng wrote:
> Hi,
>
> The workspace and workspace-impl modules were introduced to model a
> collection of contributions that are added to an SCA domain. Basically,
> Tuscany allows
> you to provide a "workspace.xml" to pre-define a list of contributions
> for an SCA domain. And the workspace model provides the "install
> contribution" and "uninstall contribution" services for the SCA domain.
> It functions as the "contribution service".
>
> Furthermore, the "workspace" becomes a special archive of artifacts that
> are SCA contributions. Now the SCA contribution is just an artifact that
> is identified by the contribution URI and can be loaded by the URL. The
> ContributionContentProcessor from workspace-impl is a
> URLArtifactProcessor that uses the ContributionScannerExtensionPoint to
> parse contributions in different packaging schemes such as Folder, JAR,
> or ZIP.
>
> The other player in the SCA domain management is the Node. Node is a
> configuration of a runtime (like a "SCA virtual machine") that is
> capable of running an SCA composite application. The Node configuration
> includes the base URI for protocols supported by a given SCA binding. It
> also defines a list of contributions and a deployable composite that
> make up the SCA composite application. At this moment, the node is
> modeled as "implementation.node" (see [3]). It doesn't seem very natural
> to me. Maybe we should use a different way, such as "node.xml" and
> NodeConfiguration model.
>
> The SCA domain manager is developed as an SCA application. It manages
> contributions, composites and nodes in the SCA domain. You can add
> contributions to the SCA domain. The SCA domain manager can then load
> the contributions, find the deployable composites, resolve the
> dependencies as well as the wirings. A resolved SCA composite
> application can then be deployed to the SCA node. To provide remote
> access, SCA domain manager uses binding.atom and packages the messages
> as ATOM feeds. See [1] and [2] for more details.
>
> I understand we also desire a more dynamic way to constitute an SCA
> domain. But conceptually, all the underlying domain level services stay
> the same. It's a matter of how the Workspace/Contribution/Composite/Node
> models are built, statically or dynamically in a centralized or
> distributed fashion.
>
> [1]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Composite+Application+Deployment+with+SCA+Domain
>
> [2]
> http://www.ibm.com/developerworks/webservices/library/ws-sca-tuscany/index.html
>
> [3]
> https://svn.apache.org/repos/asf/tuscany/java/sca/modules/implementation-node/src/test/resources/org/apache/tuscany/sca/implementation/node/xml/TestNode.composite
>
>
> Thanks,
> Raymond
>
Raymond,
I am happy with the idea of the workspace as a way of coordinating numbers of contributions.
The thing that I find VERY odd in the current arrangements is that the *MAIN* code for reading an
individual contribution is in the module workspace-impl, with some of its interfaces defined in
module "workspace".
Meanwhile, there is a module called "contribution" that does not contain the actual code for
processing a contribution, but mostly interfaces used by processors for things that you might find
in a contribution.
I think that this should be reorganized, so that actual contribution processing code is in
"contribution" and that "workspace-impl" has code for handling workspaces over the top of individual
contributions.
Yours, Mike.
Re: Node usage of the workspace and implementation-node modules
Posted by ant elder <an...@gmail.com>.
On Thu, May 7, 2009 at 5:39 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> The workspace and workspace-impl modules were introduced to model a
> collection of contributions that are added to an SCA domain. Basically,
> Tuscany allows
> you to provide a "workspace.xml" to pre-define a list of contributions for
> an SCA domain. And the workspace model provides the "install contribution"
> and "uninstall contribution" services for the SCA domain. It functions as
> the "contribution service".
>
> Furthermore, the "workspace" becomes a special archive of artifacts that are
> SCA contributions. Now the SCA contribution is just an artifact that is
> identified by the contribution URI and can be loaded by the URL. The
> ContributionContentProcessor from workspace-impl is a URLArtifactProcessor
> that uses the ContributionScannerExtensionPoint to parse contributions in
> different packaging schemes such as Folder, JAR, or ZIP.
>
> The other player in the SCA domain management is the Node. Node is a
> configuration of a runtime (like a "SCA virtual machine") that is capable of
> running an SCA composite application. The Node configuration includes the
> base URI for protocols supported by a given SCA binding. It also defines a
> list of contributions and a deployable composite that make up the SCA
> composite application. At this moment, the node is modeled as
> "implementation.node" (see [3]). It doesn't seem very natural to me. Maybe
> we should use a different way, such as "node.xml" and NodeConfiguration
> model.
>
> The SCA domain manager is developed as an SCA application. It manages
> contributions, composites and nodes in the SCA domain. You can add
> contributions to the SCA domain. The SCA domain manager can then load the
> contributions, find the deployable composites, resolve the dependencies as
> well as the wirings. A resolved SCA composite application can then be
> deployed to the SCA node. To provide remote access, SCA domain manager uses
> binding.atom and packages the messages as ATOM feeds. See [1] and [2] for
> more details.
>
> I understand we also desire a more dynamic way to constitute an SCA domain.
> But conceptually, all the underlying domain level services stay the same.
> It's a matter of how the Workspace/Contribution/Composite/Node models are
> built, statically or dynamically in a centralized or distributed fashion.
>
I agree with you the implementation.node approach doesn't seem very
natural, also the workspace modules are merging several functions that
would be better separate. I think we need to revisit and refactor this
by striping it down to as simple as possible and then putting back and
moving functions around as appropriate, and thats whats been starting
in node-impl2. The build and all tests pass using node-impl2 so how
about replacing node-impl with that and going from there?
...ant
Re: Node usage of the workspace and implementation-node modules
Posted by Raymond Feng <en...@gmail.com>.
Hi,
The workspace and workspace-impl modules were introduced to model a
collection of contributions that are added to an SCA domain. Basically,
Tuscany allows
you to provide a "workspace.xml" to pre-define a list of contributions for
an SCA domain. And the workspace model provides the "install contribution"
and "uninstall contribution" services for the SCA domain. It functions as
the "contribution service".
Furthermore, the "workspace" becomes a special archive of artifacts that are
SCA contributions. Now the SCA contribution is just an artifact that is
identified by the contribution URI and can be loaded by the URL. The
ContributionContentProcessor from workspace-impl is a URLArtifactProcessor
that uses the ContributionScannerExtensionPoint to parse contributions in
different packaging schemes such as Folder, JAR, or ZIP.
The other player in the SCA domain management is the Node. Node is a
configuration of a runtime (like a "SCA virtual machine") that is capable of
running an SCA composite application. The Node configuration includes the
base URI for protocols supported by a given SCA binding. It also defines a
list of contributions and a deployable composite that make up the SCA
composite application. At this moment, the node is modeled as
"implementation.node" (see [3]). It doesn't seem very natural to me. Maybe
we should use a different way, such as "node.xml" and NodeConfiguration
model.
The SCA domain manager is developed as an SCA application. It manages
contributions, composites and nodes in the SCA domain. You can add
contributions to the SCA domain. The SCA domain manager can then load the
contributions, find the deployable composites, resolve the dependencies as
well as the wirings. A resolved SCA composite application can then be
deployed to the SCA node. To provide remote access, SCA domain manager uses
binding.atom and packages the messages as ATOM feeds. See [1] and [2] for
more details.
I understand we also desire a more dynamic way to constitute an SCA domain.
But conceptually, all the underlying domain level services stay the same.
It's a matter of how the Workspace/Contribution/Composite/Node models are
built, statically or dynamically in a centralized or distributed fashion.
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Composite+Application+Deployment+with+SCA+Domain
[2]
http://www.ibm.com/developerworks/webservices/library/ws-sca-tuscany/index.html
[3]
https://svn.apache.org/repos/asf/tuscany/java/sca/modules/implementation-node/src/test/resources/org/apache/tuscany/sca/implementation/node/xml/TestNode.composite
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <mi...@gmail.com>
Sent: Thursday, May 07, 2009 2:44 AM
To: <de...@tuscany.apache.org>
Subject: Re: Node usage of the workspace and implementation-node modules
> ant elder wrote:
>> Currently the node-impl module has dependencies on implementation-node
>> and the workspace modules, I think its worth exploring if thats
>> necessary. In r772526 i've created a new node-impl2 module thats a
>> copy of node-impl but with no dependencies on implementation-node or
>> the workspace modules. It does include 4 classes copied from
>> workspace-impl and they're still in the o.a.t.s.workspace package to
>> make that obvious. Comparing the two node-impl modules i think this
>> makes node-impl2 significantly cleaner and shows that having those
>> contribution classes in workspace-impl may not be the correct place
>> and they'd be better in one of the contribution* modules.
>>
>> Any comments?
>>
>> ...ant
>>
> Ant,
>
> I too am puzzled by the presence of the Contribution related classes in
> the workspace-impl module.
>
> I could not make any sense of why they were there rather than in the
> Contribution module.
>
> Can anyone offer an explanation of why the Contribution code is organized
> in this way?
>
> If there is no good reason for the current split then I'd argue for moving
> the code into the contribution module.
>
>
> Yours, Mike.
Re: Node usage of the workspace and implementation-node modules
Posted by Mike Edwards <mi...@gmail.com>.
ant elder wrote:
> Currently the node-impl module has dependencies on implementation-node
> and the workspace modules, I think its worth exploring if thats
> necessary. In r772526 i've created a new node-impl2 module thats a
> copy of node-impl but with no dependencies on implementation-node or
> the workspace modules. It does include 4 classes copied from
> workspace-impl and they're still in the o.a.t.s.workspace package to
> make that obvious. Comparing the two node-impl modules i think this
> makes node-impl2 significantly cleaner and shows that having those
> contribution classes in workspace-impl may not be the correct place
> and they'd be better in one of the contribution* modules.
>
> Any comments?
>
> ...ant
>
Ant,
I too am puzzled by the presence of the Contribution related classes in the workspace-impl module.
I could not make any sense of why they were there rather than in the Contribution module.
Can anyone offer an explanation of why the Contribution code is organized in this way?
If there is no good reason for the current split then I'd argue for moving the code into the
contribution module.
Yours, Mike.
Re: Node usage of the workspace and implementation-node modules
Posted by ant elder <an...@apache.org>.
On Thu, May 7, 2009 at 5:53 PM, Raymond Feng <en...@gmail.com> wrote:
> Personally, I don't like having multiple "versions" of the same module such
> as xyz and xyz-2 in trunk.
>
> I'm all for having better ways to do things and I also believe that showing
> the code helps us understand the idea while the discussion is going on. Is
> sandbox a better place? Once the consensus is reached, we can then add it to
> trunk and remove the old one. We had a lot of pain in the 1.x code base that
> modules were providing the same function using a different way which I found
> inconsistent and very confusing.
>
>
That topic and the use of the sandbox has been discussed in the past,
its probably worth searching the archives to understand previous
comments and if we need a new discussion then do that outside of this
Node usage thread.
...ant
Re: Node usage of the workspace and implementation-node modules
Posted by Raymond Feng <en...@gmail.com>.
Personally, I don't like having multiple "versions" of the same module such
as xyz and xyz-2 in trunk.
I'm all for having better ways to do things and I also believe that showing
the code helps us understand the idea while the discussion is going on. Is
sandbox a better place? Once the consensus is reached, we can then add it to
trunk and remove the old one. We had a lot of pain in the 1.x code base that
modules were providing the same function using a different way which I found
inconsistent and very confusing.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Thursday, May 07, 2009 12:21 AM
To: <de...@tuscany.apache.org>
Subject: Node usage of the workspace and implementation-node modules
> Currently the node-impl module has dependencies on implementation-node
> and the workspace modules, I think its worth exploring if thats
> necessary. In r772526 i've created a new node-impl2 module thats a
> copy of node-impl but with no dependencies on implementation-node or
> the workspace modules. It does include 4 classes copied from
> workspace-impl and they're still in the o.a.t.s.workspace package to
> make that obvious. Comparing the two node-impl modules i think this
> makes node-impl2 significantly cleaner and shows that having those
> contribution classes in workspace-impl may not be the correct place
> and they'd be better in one of the contribution* modules.
>
> Any comments?
>
> ...ant