diff --git a/doc/reference/src/ajax.xml b/doc/reference/src/ajax.xml index 76e0e16c..ebcf2f96 100644 --- a/doc/reference/src/ajax.xml +++ b/doc/reference/src/ajax.xml @@ -22,8 +22,8 @@ Introduction - 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 + 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. @@ -54,7 +54,7 @@ Exposing Web Services The WebServiceExporter 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. In order for a Web service to be accessed from script, the diff --git a/doc/reference/src/aop-quickstart.xml b/doc/reference/src/aop-quickstart.xml index 794ed8d4..755e5049 100644 --- a/doc/reference/src/aop-quickstart.xml +++ b/doc/reference/src/aop-quickstart.xml @@ -979,7 +979,7 @@ public class ServiceCommand : ICommand Configuring advice 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 diff --git a/doc/reference/src/aop.xml b/doc/reference/src/aop.xml index acc797f8..830320f2 100644 --- a/doc/reference/src/aop.xml +++ b/doc/reference/src/aop.xml @@ -2421,7 +2421,7 @@ object oldTarget = swapper.swap(newTarget); 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. Spring.NET provides out-of-the-box support using a pooling diff --git a/doc/reference/src/messaging.xml b/doc/reference/src/messaging.xml index 0a210d0b..4e2256ff 100644 --- a/doc/reference/src/messaging.xml +++ b/doc/reference/src/messaging.xml @@ -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. + "plain old CLR object" (or POCO) programming model. 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, SimpleMessageListenerContainer. 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 IMessageConverter interface is used by both the template class and the message listener container to convert between - provider message types and PONOs. + provider message types and POCOs. The namespace Spring.Messaging.<Vendor>.Core contains the @@ -156,7 +156,7 @@
Separation of Concerns - The use of MessageConverters and a PONO programming model promote + 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.
@@ -439,7 +439,7 @@ IMessageListener 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. A subclass of AbstractMessageListenerContainer - 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 AbstractMessageListenerContainer packaged with Spring - SimpleMessageListenerContainer. Additional @@ -1009,7 +1009,7 @@ namespace MyApp Consider the following interface definition. Notice that although the interface extends neither the IMessageListener nor ISessionAwareMessageListener 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 MessageListenerAdapter 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 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. <object id="MessagleHandler" type="MyApp.DefaultMessageHandler, MyApp"/> diff --git a/doc/reference/src/msmq-quickstart.xml b/doc/reference/src/msmq-quickstart.xml index a3c14d31..50cb833c 100644 --- a/doc/reference/src/msmq-quickstart.xml +++ b/doc/reference/src/msmq-quickstart.xml @@ -226,7 +226,7 @@ </object> -<!-- Delegate to plain .NET object for message handling --> +<!-- Delegate to plain CLR object for message handling --> <object id="messageListenerAdapter" type="Spring.Messaging.Listener.MessageListenerAdapter, Spring.Messaging"> <property name="HandlerObject" ref="stockAppHandler"/> <property name="DefaultHandlerMethod" value="Handle"/> diff --git a/doc/reference/src/msmq.xml b/doc/reference/src/msmq.xml index fc77baf7..67fe29d2 100644 --- a/doc/reference/src/msmq.xml +++ b/doc/reference/src/msmq.xml @@ -46,8 +46,8 @@ from the core business processing. 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 @@ <property name="MessageListener" ref="messageListenerAdapter"/> </object> - <!-- Adapter to call a PONO as a messaging callback --> + <!-- Adapter to call a POCO as a messaging callback --> <object id="messageListenerAdapter" type="Spring.Messaging.Listener.MessageListenerAdapter, Spring.Messaging"> <property name="HandlerObject" ref="questionHandler"/> </object> - <!-- The PONO class that you write --> + <!-- The POCO class that you write --> <object id="questionHandler" type="MyNamespace.QuestionHandler, MyAssembly"/> @@ -687,7 +687,7 @@ void Send(MessageQueue messageQueue, Message message); <property name="ExceptionHandler" ref="exceptionHandler"/> </object> - <!-- Delegate to plain .NET object for message handling --> + <!-- Delegate to plain CLR object for message handling --> <object id="messageListenerAdapter" type="Spring.Messaging.Listener.MessageListenerAdapter, Spring.Messaging"> <property name="DefaultResponseQueueName" value="msmqTestResponseQueue"/> <property name="HandlerObject" ref="simpleHandler"/> @@ -815,7 +815,7 @@ void Send(MessageQueue messageQueue, Message message); <property name="MessageTransactionExceptionHandler" ref="messageTransactionExceptionHandler"/> </object> - <!-- Delegate to plain .NET object for message handling --> + <!-- Delegate to plain CLR object for message handling --> <object id="messageListenerAdapter" type="Spring.Messaging.Listener.MessageListenerAdapter, Spring.Messaging"> <property name="DefaultResponseQueueName" value="msmqTestResponseQueue"/> <property name="HandlerObject" ref="simpleHandler"/> @@ -1147,7 +1147,7 @@ void Send(MessageQueue messageQueue, Message message); process incoming MSMQ messages using the default message converter. - <!-- Delegate to plain .NET object for message handling --> + <!-- Delegate to plain CLR object for message handling --> <object id="messageListenerAdapter" type="Spring.Messaging.Listener.MessageListenerAdapter, Spring.Messaging"> <property name="DefaultResponseQueueName" value="msmqTestResponseQueue"/> <property name="HandlerObject" ref="myHandler"/> @@ -1161,17 +1161,17 @@ void Send(MessageQueue messageQueue, Message message); 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. 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 diff --git a/doc/reference/src/orm.xml b/doc/reference/src/orm.xml index 2c69a592..e9ad2564 100644 --- a/doc/reference/src/orm.xml +++ b/doc/reference/src/orm.xml @@ -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 diff --git a/doc/reference/src/overview.xml b/doc/reference/src/overview.xml index d90c4297..36f24e51 100644 --- a/doc/reference/src/overview.xml +++ b/doc/reference/src/overview.xml @@ -174,7 +174,7 @@ configuration. Spring.Services - 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. @@ -289,7 +289,7 @@ Distributed Computing - 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. @@ -326,7 +326,7 @@ - AJAX : Demonstrates how to access a plain .NET object as a + AJAX : Demonstrates how to access a plain CLR object as a webservice in client side JavaScript diff --git a/doc/reference/src/psa-intro.xml b/doc/reference/src/psa-intro.xml index 19a3b009..b6d9b3a2 100644 --- a/doc/reference/src/psa-intro.xml +++ b/doc/reference/src/psa-intro.xml @@ -23,7 +23,7 @@ Introduction 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 @@ 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 diff --git a/doc/reference/src/remoting.xml b/doc/reference/src/remoting.xml index 623cebba..e8817c7e 100644 --- a/doc/reference/src/remoting.xml +++ b/doc/reference/src/remoting.xml @@ -22,8 +22,8 @@
Introduction - 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 + 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"); <property name="ServiceName" value="RemotedSaoSingleCallCalculator" /> </object> - Note that we change the singleton attribute of the plain .NET object + Note that we change the singleton attribute of the plain CLR object as configured by Spring in the <object> definition and not an attribute on the SaoExporter. The object referred to in the TargetName parameter can be an AOP proxy to a business diff --git a/doc/reference/src/services.xml b/doc/reference/src/services.xml index a37c4b36..b7a4a053 100644 --- a/doc/reference/src/services.xml +++ b/doc/reference/src/services.xml @@ -23,7 +23,7 @@ Introduction 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.. @@ -217,10 +217,10 @@ 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. + while keeping the core business logic in a technology agnostic POCO, i.e. + Plain Old CLR Object. \ No newline at end of file diff --git a/doc/reference/src/wcf.xml b/doc/reference/src/wcf.xml index 85f220bf..22811ac3 100644 --- a/doc/reference/src/wcf.xml +++ b/doc/reference/src/wcf.xml @@ -246,12 +246,12 @@
- Exporting PONOs as WCF Services + Exporting POCOs as WCF Services Much like the approach taken for .asmx web services Spring provides an exporter that will add [ServiceContract] and [OperationContract] 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 Spring.ServiceModel.ServiceExporter 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 diff --git a/doc/reference/src/webservices.xml b/doc/reference/src/webservices.xml index 8f287b2b..c594536a 100644 --- a/doc/reference/src/webservices.xml +++ b/doc/reference/src/webservices.xml @@ -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 - Exposing PONOs as Web Services + Exposing POCOs as Web Services 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 This means that we can safely remove the WebService and WebMethod 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 WebMethod attributes to all methods of the exported interfaces.