|
From: Mark P. <mar...@us...> - 2007-10-10 03:03:53
|
Update of /cvsroot/springnet/Spring.Net/doc/reference/src In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv26805 Modified Files: index.xml remoting.xml services.xml web.xml webservices.xml Log Message: update documentation Index: webservices.xml =================================================================== RCS file: /cvsroot/springnet/Spring.Net/doc/reference/src/webservices.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -C2 -d -r1.10 -r1.11 *** webservices.xml 5 Sep 2007 18:30:17 -0000 1.10 --- webservices.xml 10 Oct 2007 03:03:28 -0000 1.11 *************** *** 3,9 **** <title>Web Services</title> ! <para>While the out-of-the-box support for web services in .NET is ! excellent, there are a few areas that the Spring.NET thought could use some ! improvement.</para> <sect1 id="server-side"> --- 3,27 ---- <title>Web Services</title> ! <sect1> ! <title>Introduction</title> ! ! <para>While the out-of-the-box support for web services in .NET is ! 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 ! 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 ! configure a client side proxy that you generated with standard command ! line tools. Additionally, Spring provides the functionality to create the ! web service proxy dynamically at runtime (much like running the command ! line tools but at runtime and without some of the tools quirks) and use ! dependency injection to configure the resulting proxy class. On both the ! server and client side, you can apply AOP advice to add behavior such as ! logging, exception handling, etc. that is not easily encapsulated within ! an inheritance hierarchy across the application.</para> ! </sect1> <sect1 id="server-side"> *************** *** 26,30 **** should be exposed as a remote object, web service, or even an enterprise (COM+) component, should only be a matter of configuration, and not ! implementation.<!-- TODO link to services --></para> <sect2> --- 44,48 ---- should be exposed as a remote object, web service, or even an enterprise (COM+) component, should only be a matter of configuration, and not ! implementation.</para> <sect2> *************** *** 85,90 **** exactly the same as a standard handler factory if said handler factory cannot find the object definition for the specified service name. In ! that case the handler factory will simply look for an .asmx file. ! </para> <para>If you are using IIS7 the following configuration is needed</para> --- 103,107 ---- exactly the same as a standard handler factory if said handler factory cannot find the object definition for the specified service name. In ! that case the handler factory will simply look for an .asmx file.</para> <para>If you are using IIS7 the following configuration is needed</para> *************** *** 442,452 **** in order to work.</para> ! <para>The <classname>WebServiceProxyFactory</classname> also implements the interface, ! <classname>Spring.Objects.Factory.IConfigurableFactoryObject</classname>, ! allowing to specify configuration for the product that the ! <classname>WebServiceProxyFactory</classname> creates. ! This is done by specifying the ProductTemplate property. This is ! particularly useful for securing the web service. An example is shown ! below.</para> <programlisting><object id="PublicarAltasWebService" type="Spring.Web.Services.WebServiceProxyFactory, Spring.Services"> --- 459,469 ---- in order to work.</para> ! <para>The <classname>WebServiceProxyFactory</classname> also implements ! the interface, ! <classname>Spring.Objects.Factory.IConfigurableFactoryObject</classname>, ! allowing to specify configuration for the product that the ! <classname>WebServiceProxyFactory</classname> creates. This is done by ! specifying the ProductTemplate property. This is particularly useful for ! securing the web service. An example is shown below.</para> <programlisting><object id="PublicarAltasWebService" type="Spring.Web.Services.WebServiceProxyFactory, Spring.Services"> Index: services.xml =================================================================== RCS file: /cvsroot/springnet/Spring.Net/doc/reference/src/services.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -d -r1.6 -r1.7 *** services.xml 28 Jun 2007 14:42:34 -0000 1.6 --- services.xml 10 Oct 2007 03:03:28 -0000 1.7 *************** *** 1,67 **** <chapter id="services"> ! <title>.NET Enterprise Services</title> ! <sect1 id="services-introduction"> ! <title>Introduction</title> ! <para>The main goal of Spring.Services is to provide location transparency for business ! services. We believe that users should be able to implement services the simplest way ! possible, using service interfaces and implementations in the form of plain .Net ! classes. We also think that decision on how a particular service is exposed to clients ! should be a configuration concern and not an implementation concern. </para> ! <para>Spring.Services provides infrastructure that allows you to expose ! <emphasis>any</emphasis> normal object as a ! <link linkend="webservices">web service</link>, System.EnterpriseServices ! serviced component or ! remoting object using service exporter definitions in the configuration file. </para> ! <para> We believe that this approach will also provide the easiest migration path to Indigo. ! As long as your services are coded against interfaces and implemented as regular ! classes, we should be able to implement Indigo exporter for them once the Indigo ships. </para> ! <para>In the meantime, you get the benefit of being able to expose business services any way ! you find appropriate using existing exporters and Spring configuration. </para> ! </sect1> ! <sect1 id="services-servicedcomponents"> ! <title>Serviced Components</title> ! <para>Services components in .NET are able to use COM+ services such as declarative and ! distributed transactions, role based security, object pooling messaging. To access these ! services your class needs to derive from the class ! <classname>System.EnterpriseServices.ServicedComponent</classname>, adorn your class ! and assemblies with relevant attributes, and configure your application by registering ! your serviced components with the COM+ catalog. The overall landscape of accessing and ! using COM+ services within .NET goes by the name .NET Enterprise Services. </para> ! <para>Many of these services can be provided without the need to derive from a ! ServicedComponent though the use of Spring's Aspect-Oriented Programming functionality. ! Nevertheless, you may be interested in exporting your class as a serviced component and ! having client access that component in a location transparent manner. By using Spring's ! <literal>ServicedComponentExporter</literal>, ! <literal>EnterpriseServicesExporter</literal>and ! <literal>ServicedComponentFactory</literal> you can easily create and consume serviced ! components without having your class inherit from <literal>ServicedComponent</literal> ! and automate the manual deployment process that involves strongly signing your assembly ! and using the <literal>regsvcs</literal> utility.</para> ! <para> Note that the following sections do not delve into the details of programming .NET ! Enterprise Services. An excellent reference for such information is Christian Nagel's ! "Enterprise Services with the .NET Framework" </para> ! </sect1> ! <sect1 id="services-serverside"> ! <title>Server Side</title> ! <para>One of the main challenges for the exported to host a serviced component is the need ! for them to be contained within a physical assembly on the file system in order to be ! registered with the COM+ Services. To make things more complicated, this assembly has to ! be strongly named before it can be successfully registered. </para> ! <para>Spring provides two classes that allow all of this to happen. <itemizedlist> ! <listitem><classname>Spring.Enterprise.ServicedComponentExporter</classname> is ! responsible for exporting single component and making sure that it derives from ! ServicedComponent class. It also allows you to specify class-level and ! method-level attributes for the component in order to define things such as ! transactional behavior, queuing, etc. </listitem> ! <listitem> ! <classname>Spring.Enterprise.EnterpriseServicesExporter</classname> corresponds ! to a COM+ application, and it allows you to specify list of components that ! should be included in the application, as well as the application name and other ! assembly-level attributes </listitem> ! </itemizedlist> ! </para> ! <para> Let's say that we have a simple service interface and implementation class, such as ! these: </para> ! <programlisting><![CDATA[namespace MyApp.Services { public interface IUserManager --- 1,82 ---- + <?xml version="1.0" encoding="UTF-8"?> <chapter id="services"> ! <title>.NET Enterprise Services</title> ! ! <sect1 id="services-introduction"> ! <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 ! mean classes that do not inherit from a specific infrastructure base class ! such as ServicedComponent..</para> ! ! <para>You can leverage the IoC container to configure the exporter and ! service endpoints. You may also opt to not use the IoC container to ! configure the objects and use Spring's .NET Enterprise Services classes ! programmatically, as you would with any third party library.</para> ! </sect1> ! ! <sect1 id="services-servicedcomponents"> ! <title>Serviced Components</title> ! ! <para>Services components in .NET are able to use COM+ services such as ! declarative and distributed transactions, role based security, object ! pooling messaging. To access these services your class needs to derive ! from the class ! <classname>System.EnterpriseServices.ServicedComponent</classname>, adorn ! your class and assemblies with relevant attributes, and configure your ! application by registering your serviced components with the COM+ catalog. ! The overall landscape of accessing and using COM+ services within .NET ! goes by the name .NET Enterprise Services.</para> ! ! <para>Many of these services can be provided without the need to derive ! from a ServicedComponent though the use of Spring's Aspect-Oriented ! Programming functionality. Nevertheless, you may be interested in ! exporting your class as a serviced component and having client access that ! component in a location transparent manner. By using Spring's ! <literal>ServicedComponentExporter</literal>, ! <literal>EnterpriseServicesExporter</literal>and ! <literal>ServicedComponentFactory</literal> you can easily create and ! consume serviced components without having your class inherit from ! <literal>ServicedComponent</literal> and automate the manual deployment ! process that involves strongly signing your assembly and using the ! <literal>regsvcs</literal> utility.</para> ! ! <para>Note that the following sections do not delve into the details of ! programming .NET Enterprise Services. An excellent reference for such ! information is Christian Nagel's "Enterprise Services with the .NET ! Framework"</para> ! </sect1> ! ! <sect1 id="services-serverside"> ! <title>Server Side</title> ! ! <para>One of the main challenges for the exported to host a serviced ! component is the need for them to be contained within a physical assembly ! on the file system in order to be registered with the COM+ Services. To ! make things more complicated, this assembly has to be strongly named ! before it can be successfully registered.</para> ! ! <para>Spring provides two classes that allow all of this to happen. ! <itemizedlist> ! <listitem> ! <classname>Spring.Enterprise.ServicedComponentExporter</classname> ! ! is responsible for exporting single component and making sure that it derives from ServicedComponent class. It also allows you to specify class-level and method-level attributes for the component in order to define things such as transactional behavior, queuing, etc. ! </listitem> ! ! <listitem> ! ! ! <classname>Spring.Enterprise.EnterpriseServicesExporter</classname> ! ! corresponds to a COM+ application, and it allows you to specify list of components that should be included in the application, as well as the application name and other assembly-level attributes ! </listitem> ! </itemizedlist></para> ! ! <para>Let's say that we have a simple service interface and implementation ! class, such as these:</para> ! ! <programlisting>namespace MyApp.Services { public interface IUserManager *************** *** 93,171 **** } } ! }]]> </programlisting> ! <para> And the corresponding object definition for it in the application context config ! file: </para> ! <programlisting><![CDATA[<object id="userManager" type="MyApp.Services.SimpleUserManager"> ! <property name="UserDao" ref="userDao"/> ! </object>]]></programlisting> ! <para> Let's say that we want to expose user manager as an serviced component so we can ! leverage its support for transactions. First we need to export our service using the ! exporter <literal>ServicedComponentExporter</literal> as shown below</para> ! <programlisting><![CDATA[<object id="MyApp.EnterpriseServices.UserManager" type="Spring.Enterprise.ServicedComponentExporter, Spring.Services"> ! <property name="TargetName" value="userManager"/> ! <property name="TypeAttributes"> ! <list> ! <object type="System.EnterpriseServices.TransactionAttribute, System.EnterpriseServices"/> ! </list> ! </property> ! <property name="MemberAttributes"> ! <dictionary> ! <entry key="*"> ! <list> ! <object type="System.EnterpriseServices.AutoCompleteAttribute, System.EnterpriseServices"/> ! </list> ! </entry> ! </dictionary> ! </property> ! </object>]]></programlisting> ! <para>The exporter defined above will create a composition proxy for our SimpleUserManager ! class that extends <literal>ServicedComponent</literal> and delegates method calls to ! SimpleUserManager instance. It will also adorn the proxy class with a ! <literal>TransactionAtribute</literal> and all methods with an ! <literal>AutoCompleteAttribute</literal>. </para> ! <para>The next thing we need to do is configure an exporter for the COM+ application that ! will host our new component: </para> ! <programlisting><![CDATA[<object id="MyComponentExporter" type="Spring.Enterprise.EnterpriseServicesExporter, Spring.Services"> ! <property name="ApplicationName" value="My COM+ Application"/> ! <property name="Description" value="My enterprise services application."/> ! <property name="AccessControl"> ! <object type="System.EnterpriseServices.ApplicationAccessControlAttribute, System.EnterpriseServices"> ! <property name="AccessChecksLevel" value="ApplicationComponent"/> ! </object> ! </property> ! <property name="Roles"> ! <list> ! <value>Admin : Administrator role</value> ! <value>User : User role</value> ! <value>Manager : Administrator role</value> ! </list> ! </property> ! <property name="Components"> ! <list> ! <ref object="MyApp.EnterpriseServices.UserManager"/> ! </list> ! </property> ! <property name="Assembly" value="MyComPlusApp"/> ! </object>]]></programlisting> ! <para>This exporter will put all proxy classes for the specified list of components into the ! specified assembly, sign the assembly, and register it with the specified COM+ ! application name. If application does not exist it will create it and configure it using ! values specified for Description, AccessControl and Roles properties. </para> ! </sect1> ! <sect1 id="services-clientside"> ! <title>Client Side</title> ! <para>Because serviced component classes are dynamically generated and registered, you ! cannot instantiate them in your code using new operator. Instead, you need to use ! <classname>Spring.Enterprise.ServicedComponentFactory</classname> definition, which ! also allows you to specify configuration template for the component as well as the name ! of the remote server component is running on, if necessary. An example is shown below</para> ! <programlisting><![CDATA[<object id="enterpriseUserManager" type="Spring.Enterprise.ServicedComponentFactory, Spring.Services"> ! <property name="Name" value="MyApp.EnterpriseServices.UserManager"/> ! <property name="Template" value="userManager"/> ! </object>]]></programlisting> ! <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 objects, against well defined service interfaces, you ! can achieve true location transparency for your services through configuration. </para> ! </sect1> ! </chapter> --- 108,203 ---- } } ! } </programlisting> ! ! <para>And the corresponding object definition for it in the application ! context config file:</para> ! ! <programlisting><object id="userManager" type="MyApp.Services.SimpleUserManager"> ! <property name="UserDao" ref="userDao"/> ! </object></programlisting> ! ! <para>Let's say that we want to expose user manager as an serviced ! component so we can leverage its support for transactions. First we need ! to export our service using the exporter ! <literal>ServicedComponentExporter</literal> as shown below</para> ! ! <programlisting><object id="MyApp.EnterpriseServices.UserManager" type="Spring.Enterprise.ServicedComponentExporter, Spring.Services"> ! <property name="TargetName" value="userManager"/> ! <property name="TypeAttributes"> ! <list> ! <object type="System.EnterpriseServices.TransactionAttribute, System.EnterpriseServices"/> ! </list> ! </property> ! <property name="MemberAttributes"> ! <dictionary> ! <entry key="*"> ! <list> ! <object type="System.EnterpriseServices.AutoCompleteAttribute, System.EnterpriseServices"/> ! </list> ! </entry> ! </dictionary> ! </property> ! </object></programlisting> ! ! <para>The exporter defined above will create a composition proxy for our ! SimpleUserManager class that extends <literal>ServicedComponent</literal> ! and delegates method calls to SimpleUserManager instance. It will also ! adorn the proxy class with a <literal>TransactionAtribute</literal> and ! all methods with an <literal>AutoCompleteAttribute</literal>.</para> ! ! <para>The next thing we need to do is configure an exporter for the COM+ ! application that will host our new component:</para> ! ! <programlisting><object id="MyComponentExporter" type="Spring.Enterprise.EnterpriseServicesExporter, Spring.Services"> ! <property name="ApplicationName" value="My COM+ Application"/> ! <property name="Description" value="My enterprise services application."/> ! <property name="AccessControl"> ! <object type="System.EnterpriseServices.ApplicationAccessControlAttribute, System.EnterpriseServices"> ! <property name="AccessChecksLevel" value="ApplicationComponent"/> ! </object> ! </property> ! <property name="Roles"> ! <list> ! <value>Admin : Administrator role</value> ! <value>User : User role</value> ! <value>Manager : Administrator role</value> ! </list> ! </property> ! <property name="Components"> ! <list> ! <ref object="MyApp.EnterpriseServices.UserManager"/> ! </list> ! </property> ! <property name="Assembly" value="MyComPlusApp"/> ! </object></programlisting> ! ! <para>This exporter will put all proxy classes for the specified list of ! components into the specified assembly, sign the assembly, and register it ! with the specified COM+ application name. If application does not exist it ! will create it and configure it using values specified for Description, ! AccessControl and Roles properties.</para> ! </sect1> ! ! <sect1 id="services-clientside"> ! <title>Client Side</title> ! ! <para>Because serviced component classes are dynamically generated and ! registered, you cannot instantiate them in your code using new operator. ! Instead, you need to use ! <classname>Spring.Enterprise.ServicedComponentFactory</classname> ! definition, which also allows you to specify configuration template for ! the component as well as the name of the remote server component is ! running on, if necessary. An example is shown below</para> ! ! <programlisting><object id="enterpriseUserManager" type="Spring.Enterprise.ServicedComponentFactory, Spring.Services"> ! <property name="Name" value="MyApp.EnterpriseServices.UserManager"/> ! <property name="Template" value="userManager"/> ! </object></programlisting> ! ! <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 ! objects, against well defined service interfaces, you can achieve true ! location transparency for your services through configuration.</para> ! </sect1> ! </chapter> \ No newline at end of file Index: web.xml =================================================================== RCS file: /cvsroot/springnet/Spring.Net/doc/reference/src/web.xml,v retrieving revision 1.24 retrieving revision 1.25 diff -C2 -d -r1.24 -r1.25 *** web.xml 21 Aug 2007 19:38:56 -0000 1.24 --- web.xml 10 Oct 2007 03:03:28 -0000 1.25 *************** *** 20,25 **** view elements.</para> ! <para>Having said that, there are many good things about ASP.NET. ! Server-side forms and controls make developers significantly more productive and allow us to significantly simplify page markup. They also make cross-browser issues easier to deal with, as each control can make --- 20,25 ---- view elements.</para> ! <para>Having said that, there <emphasis>are</emphasis> good things about ! ASP.NET. Server-side forms and controls make developers significantly more productive and allow us to significantly simplify page markup. They also make cross-browser issues easier to deal with, as each control can make *************** *** 32,39 **** development.</para> ! <para>For all these reasons, we decided that instead of developing a new, "pure and true MVC" web framework as part of Spring.NET, we should take a more pragmatic approach and extend ASP.NET in such a way that most, if not ! all of its shortcomings are eliminated.</para> <para>As we said earlier, event handlers in code-behind classes really --- 32,46 ---- development.</para> ! <para>For these reasons, we decided that instead of developing a new, "pure and true MVC" web framework as part of Spring.NET, we should take a more pragmatic approach and extend ASP.NET in such a way that most, if not ! all of its shortcomings are eliminated. It should be noted that with the ! introduction of a 'true MVC framework' being added to .NET, with extension ! points for IoC containers such as Spring, Spring will continue to play a ! role within a MVC based model once that functionality is available from ! Microsoft. It is worth noting that Spring Java has a very popular MVC ! framework and much of that experience and added value can be ! transliterated to help developers be more productive when using .NET ! upcoming MVC support. </para> <para>As we said earlier, event handlers in code-behind classes really Index: remoting.xml =================================================================== RCS file: /cvsroot/springnet/Spring.Net/doc/reference/src/remoting.xml,v retrieving revision 1.20 retrieving revision 1.21 diff -C2 -d -r1.20 -r1.21 *** remoting.xml 24 Sep 2007 11:50:17 -0000 1.20 --- remoting.xml 10 Oct 2007 03:03:28 -0000 1.21 *************** *** 6,44 **** <title>Introduction</title> ! <para>The main goal of Spring.Services is to provide location transparency ! for business services. We believe that users should be able to implement ! services the simplest way possible, using service interfaces and ! implementations in the form of plain .NET classes. We also think that ! decision on how a particular service is exposed to clients should be a ! configuration concern and not an implementation concern.</para> ! <para>In preview status is support for exposing a plain .NET object as a ! <link linkend="webservices">web service</link>, ! System.EnterpriseServices <link ! linkend="services-servicedcomponents">serviced component,</link> and ! remoted objects. By "plain .NET object" we mean classes that do not ! inherit from a specific infrastructure base class (such as ! MarshalByRefObject) or infrastructure attributes (such as WebMethod). The ! current implementation relies on your plain .NET object to implement a ! business interface. Spring's .NET Remoting exporters will automatically ! create a proxy that implements MarshalByRefObject. On the server side you ! can register SAO types as either SingleCall or Singleton and also ! configure on a per-object basis lifetime and leasing parameters. ! Additionally for SAO objects you can export an object that has had AOP ! advice applied to it. On the client side you can obtain CAO references to ! server proxy objects in a manner that promotes interface based design best ! practices when developing .NET remoting applications. An remoting specific ! xml-schema is also provided to simplify the remoting configuration, ! although you can still use the standard reflection-like property based ! configuration schema.</para> ! <para>If you want to use these features please get the code from CVS ! <ulink ! url="http://opensource.atlassian.com/confluence/spring/display/NET/Project+Structure">(instructions) ! </ulink> or from the nightly release vailable from the following <ulink ! url="http://www.springframework.net/downloads/nightly/">download ! page</ulink>. A sample application, often referred to in this ! documentation, is under the directory ! "examples\Spring\Spring.Calculator"/></para> </section> --- 6,34 ---- <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 ! 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 ! register SAO types as either SingleCall or Singleton and also configure on ! a per-object basis lifetime and leasing parameters. On the client side you ! can obtain CAO references to server proxy objects in a manner that ! promotes interface based design best practices when developing .NET ! remoting applications. The current implementation requires that your plain ! .NET objects implements a business service interface. Additionally you can ! add AOP advice to both SAO and CAO objects.</para> ! <para>You can leverage the IoC container to configure the exporter and ! service endpoints. A remoting specific xml-schema is provided to simplify ! the remoting configuration but you can still use the standard ! reflection-like property based configuration schema. You may also opt to ! not use the IoC container to configure the objects and use Spring's .NET ! Remoting classes programmatically, as you would with any third party ! library.</para> ! <para>A sample application, often referred to in this documentation, is in ! the distribution under the directory "examples\Spring\Spring.Calculator" ! and may also be found via the start menu and selecting the 'Calculator' ! item.</para> </section> *************** *** 219,229 **** <title>IIS Application Configuration</title> ! <para>If you are deploying a .NET remoting application inside IIS there is a ! <ulink url="http://forum.springframework.net/showthread.php?t=469">sample project </ulink> ! that demonstrates the necessary configuration using Spring.Web.</para> ! <para>Spring.Web ensures the application context is initialized, but if you don't use ! Spring.Web the idea is to start the initialization of the Spring IoC container inside ! the application start method defined in Global.asax, as shown below</para> <programlisting> void Application_Start(object sender, EventArgs e) --- 209,222 ---- <title>IIS Application Configuration</title> ! <para>If you are deploying a .NET remoting application inside IIS there ! is a <ulink ! url="http://forum.springframework.net/showthread.php?t=469">sample ! project </ulink> that demonstrates the necessary configuration using ! Spring.Web.</para> ! <para>Spring.Web ensures the application context is initialized, but if ! you don't use Spring.Web the idea is to start the initialization of the ! Spring IoC container inside the application start method defined in ! Global.asax, as shown below</para> <programlisting> void Application_Start(object sender, EventArgs e) *************** *** 421,425 **** <para>On the client side a CAO reference is obtained by using the ! <classname>CaoFactoryObject</classname> as shown below </para> <programlisting><object id="calculatorService" type="Spring.Remoting.CaoFactoryObject, Spring.Services"> --- 414,418 ---- <para>On the client side a CAO reference is obtained by using the ! <classname>CaoFactoryObject</classname> as shown below</para> <programlisting><object id="calculatorService" type="Spring.Remoting.CaoFactoryObject, Spring.Services"> *************** *** 434,438 **** <interfacename>IAdvancedCalculator</interfacename> interface. (As always, that doesn't mean the client should treat the object as if it was an ! in-process object). </para> <para>Alternatively, you can use the remtoing schema to shorten this --- 427,431 ---- <interfacename>IAdvancedCalculator</interfacename> interface. (As always, that doesn't mean the client should treat the object as if it was an ! in-process object).</para> <para>Alternatively, you can use the remtoing schema to shorten this Index: index.xml =================================================================== RCS file: /cvsroot/springnet/Spring.Net/doc/reference/src/index.xml,v retrieving revision 1.73 retrieving revision 1.74 diff -C2 -d -r1.73 -r1.74 *** index.xml 21 Aug 2007 03:08:52 -0000 1.73 --- index.xml 10 Oct 2007 03:03:28 -0000 1.74 *************** *** 15,18 **** --- 15,19 ---- <!ENTITY overview SYSTEM "overview.xml"> + <!ENTITY psa-intro SYSTEM "psa-intro.xml"> <!ENTITY remoting SYSTEM "remoting.xml"> <!ENTITY web SYSTEM "web.xml"> *************** *** 22,27 **** <!ENTITY threading SYSTEM "threading.xml"> <!ENTITY pool SYSTEM "pool.xml"> - <!ENTITY windows-service - SYSTEM "windows-service.xml"> <!ENTITY preface SYSTEM "preface.xml"> --- 23,26 ---- *************** *** 58,62 **** <releaseinfo>Version 1.1 RC1</releaseinfo> --> ! <pubdate>Last Updated August 20, 2007</pubdate> <authorgroup> <author> --- 57,61 ---- <releaseinfo>Version 1.1 RC1</releaseinfo> --> ! <pubdate>Last Updated October 9, 2007</pubdate> <authorgroup> <author> *************** *** 259,268 **** <para> This part of the reference documentation covers ! the Spring Framework's integration with .NET technologies ! such as .NET Remoting, Enterprise Services, ! Web Services, and Windows Services. </para> <itemizedlist> <listitem> <xref linkend="remoting" /> </listitem> --- 258,271 ---- <para> This part of the reference documentation covers ! the Spring Framework's integration with .NET distributed ! technologies such as .NET Remoting, Enterprise Services, ! Web Services. Integration with WCF Services is forthcoming. ! Please refer to the introduction chapter for more details. </para> <itemizedlist> <listitem> + <xref linkend="psa-intro" /> + </listitem> + <listitem> <xref linkend="remoting" /> </listitem> *************** *** 273,285 **** <xref linkend="webservices" /> </listitem> - <listitem> - <xref linkend="windows-service" /> - </listitem> </itemizedlist> </partintro> &remoting; &services; &webservices; - &windows-service; </part> <part id="index-vsnet"> --- 276,285 ---- <xref linkend="webservices" /> </listitem> </itemizedlist> </partintro> + &psa-intro; &remoting; &services; &webservices; </part> <part id="index-vsnet"> |
