Recommended
More Related Content
What's hot
What's hot (20)
Similar to Developing and Hosting SOAP Based Services
Similar to Developing and Hosting SOAP Based Services (20)
More from StephenKardian
More from StephenKardian (20)
Recently uploaded
Recently uploaded (20)
Developing and Hosting SOAP Based Services
- 1. Developing and Hosting SOAP Based Services
- 2. Developing and Hosting SOAP Based Services • Creating SOAP based Service Endpoints • Create a WSDL and associate it with a SOAP based Service Endpoint • Importing an existing service Goals
- 3. Developing and Hosting SOAP Based Services • WSDL • What is a WSDL document? • Hosting WSDL documents in Neuron ESB • Using WCF bindings • Custom bindings and behaviors • SOAP Services • Creating SOAP services in Neuron ESB • Importing SOAP services into Neuron ESB • Inspect and write SOAP headers and cookies • Basic security using Certificates, Username/Password, Integrated Authentication and OAUTH Lesson Plan
- 4. Developing and Hosting SOAP Based Services WSDL • 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 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 • Extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate
- 5. Developing and Hosting SOAP Based Services Six Elements of a WSDL • 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: https://msdn.microsoft.com/en- us/library/ms996486.aspx#understand_topic2
- 6. Developing and Hosting SOAP Based Services Hosting a WSDL • WSDL documents are hosted in Neuron ESB through the Repository tab of the Neuron ESB Explorer • Several ways of entering WSDL: • Manual Entry • Copy/Paste • Import from File (*.wsdl) • Service Import Wizard
- 7. Developing and Hosting SOAP Based Services Associating a WSDL with a Client Connector • WSDL documents are associated with client connectors on the Client Connector tab of the service endpoint • Can be accessed in several ways: • From an external location (URL) • From the Neuron Explorer Repository • From a file location
- 8. WSDLs : Demo Purpose: Familiarize users with hosting WSDL documents in the Neuron ESB Explorer. Objectives: Acquaint users with the following areas of SOAP/WSDL : • Creating WSDL documents manually • Importing WSDL documents into the Neuron ESB Explorer • Hosting a WSDL
- 9. Developing and Hosting SOAP Based Services WCF Bindings • Specify the communication details required to connect to a WCF endpoint • In its simplest form, a binding must specify the transport (i.e. HTTP or TCP) to use • In the Neuron ESB Explorer, bindings are managed on the General tab of a service endpoint • WCF bindings use the SOAP 1.2 protocol • BasicHttp supports the SOAP 1.1 protocol for compatibility with ASP .Net based services
- 10. Developing and Hosting SOAP Based Services WCF Bindings Bindings Default Settings BasicHttp All Reader Quota values set to maximum value. ReceiveTimeout set to infinite REST No default values set WSHttp All Reader Quota values set to maximum value. ReceiveTimeout set to infinite WSFederationHttp All Reader Quota values set to maximum value. ReceiveTimeout set to infinite NetTcp All Reader Quota values set to maximum value. ReceiveTimeout and InactivityTimeout set to infinite NetMsmq All Reader Quota values set to maximum value. ReceiveTimeout set to infinite BasicHttpRelay ReceiveTimeout set to infinite WebHttpRelay ReceiveTimeout set to infinite WS2007HttpRelay ReceiveTimeout and InactivityTimeout set to infinite NetTcpRelay ReceiveTimeout and InactivityTimeout set to infinite NetOneWayRelay No default values set NetEventRelay No default values set
- 11. Developing and Hosting SOAP Based Services WCF Bindings : Security Models Binding Supported Security Models BasicHttp HttpBasic, HttpDigest, HttpNtlm, HttpWindows, Transport:None, Transport:Basic, Transport:Digest, Transport:NTLM, Transport:Windows, Transport:Certificate, TransportWithMessage, Message:Certificate WSHttp None, Transport:None, Transport:Basic, Transport:Digest, Transport:Ntlm, Transport:Windows, Transport:Certificate, Message:Username NetTcp Transport:None, Transport:Basic, Transport:Windows, Transport:Certificate, TransportWithMessage, Message:Windows, Message:None, Message:IssuedToken, Message:Certificate, Message:Username REST HttpBasic, HttpDigest, HttpNtlm, HttpWindows, Transport:Digest, Transport:Basic, Transport:Ntlm, Transport:Windows, Transport:Certificate
- 12. Developing and Hosting SOAP Based Services Custom Configurations • Custom configurations can be leveraged on the Bindings tab of service endpoints • Custom configurations are used when you need additional (or to override) WCF settings for your service endpoint • Custom Configurations are rarely needed as most changes can be made to the Neuron configuration files.
- 13. Developing and Hosting SOAP Based Services Custom Bindings When built-in bindings are not sufficient, custom bindings can be added to Neuron ESB through the Service Bindings node of the Connection tab, inside the Neuron ESB Explorer. • Manually enter XML for custom binding in the “Binding XML” text area • Once created (and saved), custom bindings are available to service endpoints via the Bindings dropdown on General tab • Use them when the default Neuron ESB settings are not enough
- 14. Developing and Hosting SOAP Based Services Custom Behaviors • Service Behaviors: Used with client connectors only • Endpoint Behaviors: Used with both client and service connectors • Custom behaviors: can be added to Neuron ESB through the Service Behaviors node of the Connection tab, inside of the Neuron ESB Explorer. • Creating a new custom behavior will require pasting the XML into the Neuron ESB Explorer • If a custom behavior is used (ie: a dll) it must also be registered in the esbservice.exe.config and the neuronendpointhost.exe.config files. • The behavior extension assembly needs to be placed in the instance directory (i.e. <program files>NeudesicNeuron ESB v3DEFAULT) • Once created (and saved), custom behaviors are available to service endpoints via the Behavior dropdown on the General tab
- 15. Custom Bindings and Behaviors : Demo Purpose: To familiarize users with custom bindings and behaviors in the Neuron ESB Explorer. Objectives: Acquaint users with the following aspects of Custom Bindings and Behaviors • Creating a custom binding • Creating a custom behavior • Registering a custom behavior
- 16. Developing and Hosting SOAP Based Services Creating SOAP Based Service Endpoints • SOAP Service Endpoints can be created in the Service Endpoints section of the Connections tab • Any binding, other than REST, will create a SOAP service
- 17. Developing and Hosting SOAP Based Services Importing SOAP Based Services • In addition to creating SOAP service endpoints manually, Neuron ESB supports importing SOAP services from an existing URL, file or UDDI store • Importing a service will automatically create a service connector with the proper URL, bindings and security options • Importing a service will import all documents hosted by the service • Imported services do not have a subscriber associated with them, and are disabled by default until this information is provided
- 18. Creating SOAP Based Services : Demo Purpose: To familiarize users with creating/importing SOAP services in the Neuron ESB Explorer. Objectives: Acquaint users with the following aspects of SOAP Services: • Creating a SOAP service • Importing a SOAP service
- 19. • Contain application specific information (authentication, payment, etc.) about the SOAP message • The attributes defined in the SOAP Header defines how a recipient should process the SOAP message • Does not require the namespace as part of the key • Can be read in language editors in business processes or workflows • context.Data.Soap.Headers[<Key Name>] • Can be written to in language editors in business processes or workflows • context.Data.Soap.Headers[<Key Name>] = <Value> • Can be accessed from the Client API • ESBMessage.Soap.Headers[<Key Name>] Developing and Hosting SOAP Based Services SOAP Headers
- 20. Developing and Hosting SOAP Based Services : Lab Purpose Create a REST client connector and create a SOAP client connector (if business requirements dictated that you must) and send data through it to be captured in our data store. Objectives • Creating a REST Client Connector • Testing the Client Connector at runtime
- 21. Developing and Hosting SOAP Based Services Review • A WSDL is an XML format for describing network services as a set of endpoints operating on messages • WSDLs can be hosted in the Neuron ESB Explorer Repository • Hosted WSDL documents can be associated with SOAP based Client Connectors • SOAP based Service Connectors can be manually created or imported from existing services • SOAP headers can be accessed via Language Editors
Editor's Notes
- 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.
- 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
- 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).
- 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.
- 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.
- 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
- 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
- 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
- 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
- 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
- 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.
- 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.
- 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>].