名称翻译
0 views
Skip to first unread message
Wang Feng
Aug 4, 2008, 1:01:32 AM8/4/08
to Tuscany SCA 中文论坛
正在做SCA Spec的翻译,对以下名称大家看一下翻译成什么最合适?
artifact - 工件?
intent - 意图?
artifact - 工件?
intent - 意图?
Jeff Yu
Aug 4, 2008, 4:49:44 AM8/4/08
to tuscany-s...@googlegroups.com
正在做SCA Spec的翻译,对以下名称大家看一下翻译成什么最合适?
artifact - 工件?
intent - 意图?
Haibo Zhao
Aug 4, 2008, 10:55:50 AM8/4/08
to Tuscany SCA 中文论坛
在SCA spec里没找到intent这个词，估计你说的是 intents.
以下是从policy spec中找到的的intents的描述
1.2.2 Intents describe the requirements of Components, Services and
References
SCA intents are used to describe the abstract policy requirements of a
component or the
requirements of interactions between components represented by
services and references. Intents
provide a means for the developer and the assembler to state these
requirements in a high-level
abstract form, independent of the detailed configuration of the
runtime and bindings which is the
role of application deployer. Intents support the late binding of
services and references to particular
SCA bindings, since they assist the deployer in choosing appropriate
bindings and concrete policies
which satisfy the abstract requirements expressed by the intents.
It is possible in SCA to directly attach policies to a service, to a
reference or to a component at any
time during the creation of an assembly, through the configuration of
bindings and the attachment
of policy sets. Attachment may be done by the developer of a component
at the time when the
component is written or later at deployment time. SCA recommends a
late binding model where the
bindings and the concrete policies for a particular assembly are
decided at deployment time. SCA
favors the late binding approach since it promotes re-use of
components. It allows the use of
components in new application contexts which may require the use of
different bindings and
different concrete policies. Forcing early decisions on which bindings
and policies to use is likely to
limit re-use and limit the ability to use a component in a new
context.
For example, in the case of authentication, a service which requires
its messages to be
authenticated can be marked with an intent "authentication". This
intent marks the service as
requiring message authentication capability without being prescriptive
about how it is achieved. At
deployment time, when the binding is chosen for the service (say SOAP
over HTTP), the deployer
can apply suitable policies to the service which provide aspects of WS-
Security and which supply a
group of one or more authentication technologies.
In many ways, intents can be seen as restricting choices at deployment
time. If a service is marked
with the confidentiality intent, then the deployer must use a
policySet that provides for the
encryption of the messages.
The set of intents available to developers and assemblers can be
extended arbitrarily by policy
administrators. The SCA Policy Framework specification does define a
set of intents which address
the infrastructure capabilities relating to security reliable
messaging.
[1] http://www.osoa.org/download/attachments/35/SCA_Policy_Framework_V100.pdf?version=1
以下是从policy spec中找到的的intents的描述
1.2.2 Intents describe the requirements of Components, Services and
References
SCA intents are used to describe the abstract policy requirements of a
component or the
requirements of interactions between components represented by
services and references. Intents
provide a means for the developer and the assembler to state these
requirements in a high-level
abstract form, independent of the detailed configuration of the
runtime and bindings which is the
role of application deployer. Intents support the late binding of
services and references to particular
SCA bindings, since they assist the deployer in choosing appropriate
bindings and concrete policies
which satisfy the abstract requirements expressed by the intents.
It is possible in SCA to directly attach policies to a service, to a
reference or to a component at any
time during the creation of an assembly, through the configuration of
bindings and the attachment
of policy sets. Attachment may be done by the developer of a component
at the time when the
component is written or later at deployment time. SCA recommends a
late binding model where the
bindings and the concrete policies for a particular assembly are
decided at deployment time. SCA
favors the late binding approach since it promotes re-use of
components. It allows the use of
components in new application contexts which may require the use of
different bindings and
different concrete policies. Forcing early decisions on which bindings
and policies to use is likely to
limit re-use and limit the ability to use a component in a new
context.
For example, in the case of authentication, a service which requires
its messages to be
authenticated can be marked with an intent "authentication". This
intent marks the service as
requiring message authentication capability without being prescriptive
about how it is achieved. At
deployment time, when the binding is chosen for the service (say SOAP
over HTTP), the deployer
can apply suitable policies to the service which provide aspects of WS-
Security and which supply a
group of one or more authentication technologies.
In many ways, intents can be seen as restricting choices at deployment
time. If a service is marked
with the confidentiality intent, then the deployer must use a
policySet that provides for the
encryption of the messages.
The set of intents available to developers and assemblers can be
extended arbitrarily by policy
administrators. The SCA Policy Framework specification does define a
set of intents which address
the infrastructure capabilities relating to security reliable
messaging.
[1] http://www.osoa.org/download/attachments/35/SCA_Policy_Framework_V100.pdf?version=1
Reply all
Reply to author
Forward
0 new messages