InterOp Technical Notes Scott Neumann December 1, 2009

Purpose The purpose of this presentation is to capture notes and lessons learned from the IEC 61968-9 InterOp testing effort This material may be factored into the following: IEC 61968-9 2Ed IEC 61968-1-1 (proposed) InterOp Test Plans InterOp ESB

WSDL Namespaces must be respected, use of a different namespace is essentially a different interface SOAP action should include namespace, e.g. ‘http://www.iec.ch/61968/Request’ Document (not RPC) style is used for web services, as is common for SOA WSDLs should be migrated to support WSDL 2.0 WSDLs currently imply use of SOAP 1.1 WSDL 2.0 should provide a common WSDL for both Java and .Net implementations, with WCF compatibility

WSDL - continued Note that products that use web services operations MUST generate and accept SOAP messages that conform to the standard WSDL, but at the same time there is no requirement that a product vendor in fact uses the standard WSDL in the construction of their product While not a problem for InterOp or related WSDLs, it is important to remember that each WSDL operation must have a different signature, and that they can’t just have different names

SOAP Tests used SOAP 1.1 Would want to move to SOAP 1.2, where this should be explicitly specified in the WSDL SOAP version is a simple configuration option in TIBCO

Payload XSDs Profile definitions would be better if they defined concrete complex types for each element Some cases where types need minor corrections, e.g. string->DateTime Namespaces must be respected, use of a different namespace is essentially a different interface Note that XML for payloads MUST conform to the standard XSDs, but at the same time there is no requirement that a product vendor in fact uses the standard XSDs for generating or consuming the XML Note that there is no requirement that product vendors use the standard XSDs in construction of their product

XML Message Content Need to be sure all required elements are supplied in messages Null elements should not be sent in messages, e.g. no empty tags like ‘<tag/>’ or ‘<tag></tag>’ XML tags must be namespace qualified, e.g. ‘<mes:Verb>’ Elements identified as required in XSDs MUST be supplied and conform to restrictions imposed by the XSD Tags and enumerations defined in an XSD are case sensitive

Web Services Need to solidify strategy/pattern/technologies for notifications, e.g. consider use of WS-Notification or continue with PublishEvent operation (note that both approaches require a loosely coupled web service approach as is used for the InterOp and identified by the proposed 61968-1-1) Could consider option for JMS as a transport WS-I compliance is important WCF compatibility is important Security (see separate slide) Should option for REST be considered?

JMS Message types should be XML Text JNDI is not needed for connections Don’t forget to ‘start’ the connection in Java code JMS connections are in the form: ‘tcp://<host>:<port>’ For async reply patterns, ReplyAddress should be in the form ‘queue:<queue name>’ or ‘topic:<topic name>’ Need to identify policy for setting and use of JMSExpiration Could consider implementing services based on WSDLs that use JMS transport

Message Envelope Add more complex error reporting structure (see associated PPT and Message2.xsd) Note that enumerations for nouns are all lower case, so lower case nouns are required Some time-related elements (e.g. StartTime, EndTime) should to be changed from a string to dateTime (see Message2.xsd) Should test payload compression

Security No security was implemented for tests Minimally need to add use of SSL/TLS Any web service security needs to be WS-IT compliant, to be compatible with both Java and .Net Use SSL for JMS connections with authentication Need to better leverage OASIS standards Security profiles are a whole topic in itself

Patterns Need to clearly document async reply pattern, see related PPT Need option for clients to specify timeouts on sync request/reply

Test Approaches Vendors using web services should unit test with soapUI prior to connectivity testing, providing a ‘neutral’ test stub

Testing with soapUI Both free and commercial versions are available Free version used to assist connectivity testing for web services TIBCO can consume an abstract WSDL and generate a concrete WSDL that can be consumed by soapUI

More Information UISOL web site: http://uisol.com EPRI web site: http://www.epri.com E-mail: sneumann@uisol.com