Developing and Hosting SOAP Based Services

Editor's Notes

• #5: A WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. Operations and messages within a WSDL are described abstractly and then bound to a concrete network protocol and message format to define an endpoint. Abstract definitions of ports and messages are separated from their concrete use or instance, allowing the reuse of these definitions. WSDLs are extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.
• #6: There are six elements to a WSDL document that you should familiarize yourself with in order to understand them better. Types Data type definitions used to describe the messages exchanged. Message Describes the data being exchanged between the web service providers and the consumers portType A set of abstract operations. Each operation refers to an input message and output messages. Binding Specifies concrete protocol and data format specifications for the operations and messages defined by a particular portType. Port Specifies an address for a binding, thus defining a single communication endpoint. Service Used to aggregate a set of related ports. Additional documentation on WSDLs and their major elements can be found at the link provided in this slide
• #7: The Neuron ESB Repository provides a place for WSDL documents to be hosted within your solution, so that they can be leveraged by SOAP based service endpoints. WSDL documents can be manually created, copy and pasted into the WSDL pane, imported from a *.wsdl file, or generated via a service import (which we will talk about later in this presentation).
• #8: WSDL documents can be associated with SOAP based client connectors on the client connector tab of the service endpoint. Clicking the Metadata button will launch the Configure Client Connector Metadata dialog window which will allow you to select the WSDL document you wish to associate. This can either be done by using a document that exists in the Neuron ESB Repository, referencing the file from an external file location or by providing the URL to an external WSDL document to use.
• #10: Neuron ESB is a .NET based platform and as such leverages many aspects of the .NET or Microsoft platforms. One such aspect is WCF which underpins service endpoints and how the operate within Neuron ESB. WCF bindings, used in the creation of a service endpoint specify the communication details required when connection to a WCF endpoint. In its simplest form, a binding must specify the transport, whether that be Http or TCP, to use. As discussed in the Introduction to API and Service Hosting presentation, the binding for a service endpoint is set on the general tab of the service endpoint.
• #11: Neuron ESB sets specific values for the Reader Quota, Receive Timeout and InactivityTimeout, depending on the binding, to the maximum value allowed (as indicated in the table shown). These are the default settings used when selecting a pre-defined binding from the bindings drop down list. If you need to adjust the values for these bindings you will need to use a custom binding, which we will discuss later in this presentation. https://docs.microsoft.com/en-us/dotnet/framework/wcf/bindings
• #12: The binding that you choose will also determine the security models that are available to you on the Security tab of the service endpoint, as each binding supports different security models. In the table above you will find the most common bindings and the security models that they support. However, a full accounting of the WCF bindings and their associated security models can be found at https://docs.microsoft.com/en-us/dotnet/framework/wcf/securing-services
• #13: Custom configurations give you the flexibility of providing endpoint and service behavior data at the point of deployment instead of at design time. These are most often used when one needs additional, or to overwrite, the WCF settings for a service endpoint. However, before creating a custom configuration it is important to look at the Neuron ESB configuration files, as the vast majority of changes can be made there, without the need for a custom configuration. https://docs.microsoft.com/en-us/dotnet/framework/wcf/configuring-services-using-configuration-files
• #14: As we mentioned earlier in this presentation if the built-in bindings are not sufficient to meet the needs of your organization it is possible for you to create a custom binding in the Neuron ESB Explorer. Navigate to Connections -> Service Bindings to create a new binding. There you can manually enter the XML for the custom binding in the Binding XML pane. Once created and saved, the custom binding is available to all service endpoints via the bindings drop down list on the general tab of the service endpoint. https://docs.microsoft.com/en-us/dotnet/framework/wcf/extending/custom-bindings https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/wcf/custombinding
• #15: Service behaviors are used only in conjunction with client connectors while endpoint behaviors can be used in conjunction with both client and service connectors. While there are no built-in behaviors that can be selected inside of the Neuron ESB Explorer it is possible to create a custom behavior for your service endpoint. Navigate to Connections -> Service Behaviors to create a new service behavior. Here you can manually enter your service behavior or copy and paste a service behavior into the Behavior XML pane. Once the custom behavior is created you must register it with the esbservice.exe.config file as well as the neuronendpointhost.exe.config files, as well as place the behavior assembly into the <neuron installation path>\Neuron ESB v3\<neuron instance> folder. https://docs.microsoft.com/en-us/dotnet/framework/wcf/extending/configuring-and-extending-the-runtime-with-behaviors
• #17: In the Introduction to API and Service Hosting presentation we discussed how to create a service endpoint. When selecting the binding for your service endpoint any binding other than the REST binding will create a SOAP based service endpoint.
• #18: In addition to manually creating a SOAP based service connector you can import one from an existing service, provided that it has a WSDL associated with it, by providing an existing URL or UDDI store. Importing the service will automatically create a service connector endpoint, or multiple endpoints depending on how many bindings are associated with the service, as well as import all documents hosted by the service into the Neuron ESB Repository (schemas, XSLTs, WSDLs etc). As the service being imported has no way of knowing whether or not you are using the service endpoint in the messaging system (or what provider to use if so) it will be disabled by default. You must manually select whether to use the service endpoint as part of the messaging system, and provide an appropriate subscriber is you chose to do so.
• #20: In the Introduction to Messaging presentation we discussed Neuron ESB Message headers and how they can be useful to processing a message In addition to the message headers found at the Header property level, there are SOAP headers which are found at the SOAP property level. These headers contain application specific information about the SOAP message and allow clients and servers to pass additional information with the messages. On top of the pre-defiend headers, such as Date, From and Host, custom headers can be added to this section as well by using the syntax <message object>.SOAP.Header[<Key Name>] = value in business processes, workflow definitions and applications using the Neuron ESB Client API. Those same systems can then read these custom headers using the syntax <message object>.SOAP.Headers[<Key Name>].