Spring/spring-net
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Minor reference doc housekeeping.

Browse Source
This commit is contained in:
sbohlen
2010-11-09 20:36:42 +00:00
parent 84e6411dec
commit bf51d96ec6
13 changed files with 49 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/reference/src/ajax.xml
View File

@@ -22,8 +22,8 @@
<sect1 xml:id="introduction-ajax">
<title>Introduction</title>
<para>Spring's ASP.NET AJAX integration allows for a plain .NET object
(PONO), that is one that doesn't have any attributes or special base
<para>Spring's ASP.NET AJAX integration allows for a plain CLR object
(POCO), that is one that doesn't have any attributes or special base
classes, to be exported as a web service, configured via dependency
injection, 'decorated' by applying AOP, and then exposed to client side
JavaScript.</para>
@@ -54,7 +54,7 @@
<title>Exposing Web Services</title>
<para>The <literal>WebServiceExporter</literal> combined with the
new HTTP handler exposes PONOs as Web Services in your ASP.NET AJAX
new HTTP handler exposes POCOs as Web Services in your ASP.NET AJAX
application.</para>
<para>In order for a Web service to be accessed from script, the

2
doc/reference/src/aop-quickstart.xml
View File

@@ -979,7 +979,7 @@ public class ServiceCommand : ICommand
<title>Configuring advice</title>
<para>In case it is not immediately apparent, remember that advice is
just a plain old .NET object (a PONO); advice can have constructors
just a plain old CLR object (a POCO); advice can have constructors
that can take any number of parameters, and like any other .NET class,
advice can have properties. What this means is that one can leverage
the power of the Spring.NET IoC container to apply the IoC principle

2
doc/reference/src/aop.xml
View File

@@ -2421,7 +2421,7 @@ object oldTarget = swapper.swap(newTarget);</programlisting></para>
<para>A crucial difference between Spring.NET pooling and pooling in
.NET Enterprise Services pooling is that Spring.NET pooling can be
applied to any PONO. (Plain old .NET object). As with Spring.NET in
applied to any POCO. (Plain old CLR object). As with Spring.NET in
general, this service can be applied in a non-invasive way.</para>
<para>Spring.NET provides out-of-the-box support using a pooling

22
doc/reference/src/messaging.xml
View File

@@ -36,7 +36,7 @@
practices in designing a messaging application by promoting a clear
separation between the messaging middleware specific code and business
processing that is technology agnostic. This is generally referred to a
"plain old .NET object" (or PONO) programming model.</para>
"plain old CLR object" (or POCO) programming model.</para>
<para>This chapter discusses Spring's messaging support for providers
whose API was modeled after the Java Message Service (JMS) API. Vendors
@@ -88,12 +88,12 @@
is used. Asynchronous message consumption is performed though a
multi-threaded message listener container,
<literal>SimpleMessageListenerContainer</literal>. This message listener
container is used to create Message-Driven PONOs (MDPs) which refer to a
messaging callback class that consists of just 'plain .NET object's and
container is used to create Message-Driven POCOs (MDPs) which refer to a
messaging callback class that consists of just 'plain CLR object's and
is devoid of any specific messaging types or other artifacts. The
<literal>IMessageConverter</literal> interface is used by both the
template class and the message listener container to convert between
provider message types and PONOs.</para>
provider message types and POCOs.</para>
<para>The namespace
<literal>Spring.Messaging.&lt;Vendor&gt;.Core</literal> contains the
@@ -156,7 +156,7 @@
<section xml:id="activemq-intro-soc">
<title>Separation of Concerns</title>
<para>The use of MessageConverters and a PONO programming model promote
<para>The use of MessageConverters and a POCO programming model promote
messaging best practices by applying the principal of Separation of
Concerns to messaging based architectures. The infrastructure concern of
publishing and consuming messages is separated from the concern of
@@ -166,12 +166,12 @@
business processing is decoupled from the messaging technology, making
it more likely to survive technological changes over time and also
easier to test. Spring's MessageConverters provides support for mapping
messaging data types to PONOs. Aside from being the link between the two
messaging data types to POCOs. Aside from being the link between the two
layers, MessageConverters provide a pluggable strategy to help support
the evolution of a loosely coupled architecture over time. Message
formats will change over time, typically by the addition of new fields.
MessageConverters can be implemented to detect different versions of
messages and perform the appropriate mapping logic to PONOs such so that
messages and perform the appropriate mapping logic to POCOs such so that
multiple versions of a message can be supported simultaneously, a common
requirement in enterprise messaging architectures.</para>
</section>
@@ -439,7 +439,7 @@
<literal>IMessageListener</literal> that is injected into it. The
listener container is responsible for all threading of message reception
and dispatches into the listener for processing. A message listener
container is the intermediary between an Message-Driven PONO (MDP) and a
container is the intermediary between an Message-Driven POCO (MDP) and a
messaging provider, and takes care of registering to receive messages,
resource acquisition and release, exception conversion and suchlike.
This allows you as an application developer to write the (possibly
@@ -448,7 +448,7 @@
infrastructure concerns to the framework.</para>
<para>A subclass of <literal>AbstractMessageListenerContainer</literal>
is used to receive messages from JMS and drive the Message-Driven PONOs
is used to receive messages from JMS and drive the Message-Driven POCOs
(MDPs) that are injected into it. There are one subclasses of
<literal>AbstractMessageListenerContainer</literal> packaged with Spring
- <literal>SimpleMessageListenerContainer</literal>. Additional
@@ -1009,7 +1009,7 @@ namespace MyApp
<para>Consider the following interface definition. Notice that although
the interface extends neither the <literal>IMessageListener</literal>
nor <literal>ISessionAwareMessageListener</literal> interfaces, it can
still be used as a Message-Driven PONOs (MDP) via the use of the
still be used as a Message-Driven POCOs (MDP) via the use of the
<literal>MessageListenerAdapter</literal> class. Notice also how the
various message handling methods are strongly typed according to the
contents of the various Message types that they can receive and
@@ -1033,7 +1033,7 @@ namespace MyApp
<para>In particular, note how the above implementation of the
IMessageHandler interface (the above DefaultMessageHandler class) has no
messaging provider API dependencies at all. It truly is a PONO that we
messaging provider API dependencies at all. It truly is a POCO that we
will make into an MDP via the following configuration.</para>
<programlisting language="myxml">&lt;object id="MessagleHandler" type="MyApp.DefaultMessageHandler, MyApp"/&gt;

2
doc/reference/src/msmq-quickstart.xml
View File

@@ -226,7 +226,7 @@
&lt;/object&gt;
&lt;!-- Delegate to plain .NET object for message handling --&gt;
&lt;!-- Delegate to plain CLR object for message handling --&gt;
&lt;object id="<emphasis role="bold">messageListenerAdapter</emphasis>" type="Spring.Messaging.Listener.MessageListenerAdapter, Spring.Messaging"&gt;
&lt;property name="HandlerObject" ref="stockAppHandler"/&gt;
&lt;property name="DefaultHandlerMethod" value="Handle"/&gt;

24
doc/reference/src/msmq.xml
View File

@@ -46,8 +46,8 @@
from the core business processing.</para>
<para>Spring's approach to distributed computing has always been to
promote a plain old .NET object approach or a PONO programming model. In
this approach plain .NET objects are those that are devoid of any
promote a plain old CLR object approach or a POCO programming model. In
this approach plain CLR objects are those that are devoid of any
reference to a particular middleware technology. Spring provides the
'adapter' classes that converts between the middleware world, in this case
MSMQ, and the oo-world of your business processing. This is done through
@@ -218,12 +218,12 @@
&lt;property name="MessageListener" ref="messageListenerAdapter"/&gt;
&lt;/object&gt;
&lt;!-- Adapter to call a PONO as a messaging callback --&gt;
&lt;!-- Adapter to call a POCO as a messaging callback --&gt;
&lt;object id="messageListenerAdapter" type="Spring.Messaging.Listener.MessageListenerAdapter, Spring.Messaging"&gt;
&lt;property name="HandlerObject" ref="questionHandler"/&gt;
&lt;/object&gt;
&lt;!-- The PONO class that you write --&gt;
&lt;!-- The POCO class that you write --&gt;
&lt;object id="questionHandler" type="MyNamespace.QuestionHandler, MyAssembly"/&gt;
</programlisting>
@@ -687,7 +687,7 @@ void Send(MessageQueue messageQueue, Message message);</programlisting>
&lt;property name="ExceptionHandler" ref="exceptionHandler"/&gt;
&lt;/object&gt;
&lt;!-- Delegate to plain .NET object for message handling --&gt;
&lt;!-- Delegate to plain CLR object for message handling --&gt;
&lt;object id="messageListenerAdapter" type="Spring.Messaging.Listener.MessageListenerAdapter, Spring.Messaging"&gt;
&lt;property name="DefaultResponseQueueName" value="msmqTestResponseQueue"/&gt;
&lt;property name="HandlerObject" ref="simpleHandler"/&gt;
@@ -815,7 +815,7 @@ void Send(MessageQueue messageQueue, Message message);</programlisting>
&lt;property name="MessageTransactionExceptionHandler" ref="messageTransactionExceptionHandler"/&gt;
&lt;/object&gt;
&lt;!-- Delegate to plain .NET object for message handling --&gt;
&lt;!-- Delegate to plain CLR object for message handling --&gt;
&lt;object id="messageListenerAdapter" type="Spring.Messaging.Listener.MessageListenerAdapter, Spring.Messaging"&gt;
&lt;property name="DefaultResponseQueueName" value="msmqTestResponseQueue"/&gt;
&lt;property name="HandlerObject" ref="simpleHandler"/&gt;
@@ -1147,7 +1147,7 @@ void Send(MessageQueue messageQueue, Message message);</programlisting>
process incoming MSMQ messages using the default message
converter.</para>
<programlisting language="myxml"> &lt;!-- Delegate to plain .NET object for message handling --&gt;
<programlisting language="myxml"> &lt;!-- Delegate to plain CLR object for message handling --&gt;
&lt;object id="messageListenerAdapter" type="Spring.Messaging.Listener.MessageListenerAdapter, Spring.Messaging"&gt;
&lt;property name="DefaultResponseQueueName" value="msmqTestResponseQueue"/&gt;
&lt;property name="HandlerObject" ref="myHandler"/&gt;
@@ -1161,17 +1161,17 @@ void Send(MessageQueue messageQueue, Message message);</programlisting>
<para>The goals of Spring's MSMQ messaging support are quite similar to
those of WCF with its MSMQ related bindings, in as much as a WCF service
contract is a PONO (minus the attributes if you really picky about what
you call a PONO). Spring's messaging support can give you the programming
convenience of dealing with PONO contracts for message receiving but does
not (at the moment) provide a similar PONO contract for sending, instead
contract is a POCO (minus the attributes if you really picky about what
you call a POCO). Spring's messaging support can give you the programming
convenience of dealing with POCO contracts for message receiving but does
not (at the moment) provide a similar POCO contract for sending, instead
relying on explicit use of the MessageQueueTemplate class. This feature
exists - some question whether it should for messaging - in the Java
version of the Spring framework, see JmsInvokerServiceExporter and
JmsInvokerProxyFactoryBean.</para>
<para>The good news is that if and when it comes time to move from a
Spring MSMQ solution to WCF, you will be in a great position as the PONO
Spring MSMQ solution to WCF, you will be in a great position as the POCO
interface used for business processing when receiving in a Spring based
MSMQ application can easily be adapted to a WCF environment. There may
also be some features unique to MSMQ and/or Spring's MSMQ support that you

2
doc/reference/src/orm.xml
View File

@@ -183,7 +183,7 @@
are usable on their own but integrate nicely with Spring's application
context concept, providing XML-based configuration and cross-referencing
of plain object instances that don't need to be Spring-aware. In a
typical Spring application, many important objects are plain .NET
typical Spring application, many important objects are plain CLR
objects: data access templates, data access objects (that use the
templates), transaction managers, business services (that use the data
access objects and transaction managers), ASP.NET web pages (that use

6
doc/reference/src/overview.xml
View File

@@ -174,7 +174,7 @@
configuration.</para>
<para><link linkend="spring-services">Spring.Services</link> - Use this
module to adapt plain .NET objects so they can be used with a specific
module to adapt plain CLR objects so they can be used with a specific
distributed communication technology, such as .NET Remoting, Enterprise
Services, and ASMX Web Services. These services can be configured via
dependency injection and ‘decorated’ by applying AOP.</para>
@@ -289,7 +289,7 @@
<listitem>
<para><link linkend="remoting-quickstart">Distributed Computing</link>
- A calculator demonstrating remote service abstractions that let you
'export' a plain .NET object (PONO) via .NET Remoting, Web Services,
'export' a plain CLR object (POCO) via .NET Remoting, Web Services,
or an EnterpriseService ServiceComponent. Corresponding client side
proxies are also demonstrated.</para>
</listitem>
@@ -326,7 +326,7 @@
</listitem>
<listitem>
<para>AJAX : Demonstrates how to access a plain .NET object as a
<para>AJAX : Demonstrates how to access a plain CLR object as a
webservice in client side JavaScript</para>
</listitem>

6
doc/reference/src/psa-intro.xml
View File

@@ -23,7 +23,7 @@
<title>Introduction</title>
<para>The goal of Spring's integration with distributed technologies is to
adapt plain .NET objects so they can be used with a specific distributed
adapt plain CLR objects so they can be used with a specific distributed
technology. This integration is designed to be as non-intrusive as
possible. If you need to expose an object to a remote process then you can
define an exporter for that object. Similarly, on the client side you
@@ -49,8 +49,8 @@
<para>The diagram shown below is a useful way to demonstrate the key
abstractions in the Spring tool chest and their interrelationships. The
four key concepts are; plain .NET objects, Dependency Injection, AOP, and
Portable Service Abstractions. At the heart sits the plain .NET object
four key concepts are; plain CLR objects, Dependency Injection, AOP, and
Portable Service Abstractions. At the heart sits the plain CLR object
that can be instantiated and configured using dependency injection. Then,
optionally, the plain object can be adapted to a specific distributed
technology. Lastly, additional behavior can be applied to objects. This

6
doc/reference/src/remoting.xml
View File

@@ -22,8 +22,8 @@
<section xml:id="remoting-introduction">
<title>Introduction</title>
<para>Spring's .NET Remoting support allows you to export a 'plain .NET
object' as a .NET Remoted object. By "plain .NET object" we mean classes
<para>Spring's .NET Remoting support allows you to export a 'plain CLR
object' as a .NET Remoted object. By "plain CLR object" we mean classes
that do not inherit from a specific infrastructure base class such as
MarshalByRefObject. On the server side, Spring's .NET Remoting exporters
will automatically create a proxy that implements MarshalByRefObject. You
@@ -138,7 +138,7 @@ RemotingServices.Marshal(calc, "MyRemotedCalculator");</programlisting></para>
&lt;property name="ServiceName" value="RemotedSaoSingleCallCalculator" /&gt;
&lt;/object&gt;</programlisting></para>
<para>Note that we change the singleton attribute of the plain .NET object
<para>Note that we change the singleton attribute of the plain CLR object
as configured by Spring in the &lt;object&gt; definition and not an
attribute on the SaoExporter. The object referred to in the
<literal>TargetName</literal> parameter can be an AOP proxy to a business

8
doc/reference/src/services.xml
View File

@@ -23,7 +23,7 @@
<title>Introduction</title>
<para>Spring's .NET Enterprise Services support allows you to export a
'plain .NET object' as a .NET Remoted object. By "plain .NET object" we
'plain CLR object' as a .NET Remoted object. By "plain CLR object" we
mean classes that do not inherit from a specific infrastructure base class
such as ServicedComponent..</para>
@@ -217,10 +217,10 @@
<para>You can then inject this instance of the IUserManager into a client
class and use it just like you would use original SimpleUserManager
implementation. As you can see, by coding your services as plain .Net
implementation. As you can see, by coding your services as plain CLR
objects, against well defined service interfaces, you gain easy
pluggability for your service implementation though this configuration,
while keeping the core business logic in a technology agnostic PONO, i.e.
Plain Ordinary .Net Object.</para>
while keeping the core business logic in a technology agnostic POCO, i.e.
Plain Old CLR Object.</para>
</sect1>
</chapter>

4
doc/reference/src/wcf.xml
View File

@@ -246,12 +246,12 @@
</section>
<section>
<title>Exporting PONOs as WCF Services</title>
<title>Exporting POCOs as WCF Services</title>
<para>Much like the approach taken for .asmx web services Spring provides
an exporter that will add <literal>[ServiceContract] </literal>and
<literal>[OperationContract]</literal> attributes by default to all public
interface methods on a given (PONO) class. The exporter class is
interface methods on a given (POCO) class. The exporter class is
<literal>Spring.ServiceModel.ServiceExporter</literal> and has various
options to fine-tune what interfaces are exported and the specific
attributes that get applied to each method and on that class. Here is a

8
doc/reference/src/webservices.xml
View File

@@ -32,8 +32,8 @@
excellent, there are a few areas that the Spring.NET thought could use
some improvement. Spring adds the ability to perform dependency injection
on standard asmx web services. Spring's .NET Web Services support also
allows you to export a 'plain .NET object' as a .NET web service By "plain
.NET object" we mean classes that do not contain infrastructure specific
allows you to export a 'plain CLR object' as a .NET web service By "plain
CLR object" we mean classes that do not contain infrastructure specific
attributes, such as WebMethod. On the server side, Spring's .NET web
service exporters will automatically create a proxy that adds web service
attributes. On the client side you can use Spring IoC container to
@@ -255,7 +255,7 @@ namespace MyApp.Services
</sect2>
<sect2 xml:id="web-services-exporter">
<title>Exposing PONOs as Web Services</title>
<title>Exposing POCOs as Web Services</title>
<para>Now that we are generating a server-side proxy for the service,
there is really no need for it to have all the attributes that web
@@ -268,7 +268,7 @@ namespace MyApp.Services
<para>This means that we can safely remove the
<literal>WebService</literal> and <literal>WebMethod</literal> attribute
declarations from the service implementation, and what we are left with
is a plain old .NET object (a PONO). The example above would still work,
is a plain old CLR object (a POCO). The example above would still work,
because the proxy generator will automatically add
<literal>WebMethod</literal> attributes to all methods of the exported
interfaces.</para>