import SOAP-WSDL 2.00_27 from CPAN

git-cpan-module:   SOAP-WSDL
git-cpan-version:  2.00_27
git-cpan-authorid: MKUTTER
git-cpan-file:     authors/id/M/MK/MKUTTER/SOAP-WSDL-2.00_27.tar.gz

lib/SOAP/WSDL/Manual.pod

@@ -12,7 +12,7 @@ SOAP::WSDL::Manual - Accessing WSDL based web services
 
 =item * Create WSDL bindings
 
- perl wsdl2perl.pl -b base_dir URL
+  perl wsdl2perl.pl -b base_dir URL
 
 =item * Look what has been generated
 
@@ -37,7 +37,7 @@ The results of all calls to your service object's methods (except new) are
 objects based on SOAP::WSDL's XML schema implementation.
 
 To access the object's properties use get_NAME / set_NAME getter/setter
-methods whith NAME corresponding to the XML tag name / the hash structure as
+methods with NAME corresponding to the XML tag name / the hash structure as
 showed in the generated pod.
 
 =item  * Run script
@@ -91,7 +91,7 @@ and you may even want to add custom typemap elements.
 
 There should be a bunch of classes for types (in the MyTypes:: namespace by
 default), elements (in MyElements::), and at least one typemap (in
-MyTypemaps::) and one ore more interface classes (in MyInterfaces::).
+MyTypemaps::) and one or more interface classes (in MyInterfaces::).
 
 If you don't already know the details of the web service you're going to
 instrument, it's now time to read the perldoc of the generated interface
@@ -111,7 +111,7 @@ included perldoc will be, too - if not, blame the web service author.
  print $result;
 
 The above handling of errors ("die $result if not $result") may look a bit
-strange - it is due to the nature of
+strange - it is due to the nature of the 
 L<SOAP::WSDL::SOAP::Typelib::Fault11|SOAP::WSDL::SOAP::Typelib::Fault11>
 objects SOAP::WSDL uses for signalling failure.
 
@@ -144,12 +144,12 @@ generated classes - while generated classes may be many, you probably will
 only implement a few by hand. These (precious) few classes may get lost in
 the mass of (cheap) generated ones. Just imagine one of your co-workers (or
 even yourself) deleting the whole bunch and re-generating everything - oops
-- almost everything. You got the point.
+- almost everything. You get the point.
 
 For simplicity, you probably just want to use builtin types wherever possible
 - you are probably not interested in whether a fault detail's error code is
 presented to you as a simpleType ranging from 1 to 10 (which you have to
-write) or as a int (which is a builtin type ready to use).
+write) or as an int (which is a builtin type ready to use).
 
 Using builtin types for simpleType definitions may greatly reduce the number
 of additional classes you need to implement.
@@ -230,6 +230,17 @@ L<SOAP::WSDL::Manual::Parser> will tell you how to create a typemap class.
 
 =back
 
+=head1 Creating a SOAP Server
+
+Creating a SOAP server works just like creating a client - just add the 
+C<--server> or C<-s> option to the call to C<wsdl2perl.pl>.
+
+ perl wsdl2perl.pl -s -b BASE_DIR URL
+
+Note that SOAP::WSDL only includes a basic CGI based SOAP servers by now -
+while more advanced servers (like standalone or mod_perl based) are no big
+deal, no base implementation is included yet.
+
 =head1 Troubleshooting
 
 =head2 Accessing HTTPS webservices