Notification Classes
When the WSDL file defines a notification or a solicit-response service, additional classes are generated. Assume the addition of the following definitions for a notification service to the example WSDL file:
<portType name="NotifySkiReport"> <!-- 1 -->
<!-- For notification, an operation with only an output -->
<!-- For solicit-response, an operation with an output
followed by an input -->
</portType>
<binding name="NotifySkiReportSOAPBinding" <!-- 2 -->
type="tns:NotifySkiReport">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/> <!-- 3 -->
...
</binding>
<service name="NotifySkiReportService"> <!-- 4 -->
<port binding="tns:NotifyReportSOAPBinding"
name="NotifySkiReport"> <!-- 5 -->
<soap:address location="http://localhost:8080/etc"/>
</port>
</service>
The client-side classes for notification mirror the usual server-side classes. There is a skeleton class whose name is based on the binding name (line 2) with the string NotificationSkeleton appended. The resulting class name would be NotifySkiReportSOAPBindingNotificationSkeleton. Then there are an implementation base class and a sample implementation class whose names are based on the portType name (line 1), resulting in the classes NotifySkiReportNotificationBase and NotifySkiReportNotificationImp.
On the server side, there is just a proxy class whose name is based on the binding name (line 2) with the string NotificationProxy appended. The resulting class would be NotifySkiReportSOAPBindingNotificationProxy.
