1. InterOp Technical Notes
Scott Neumann
December 1, 2009

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

3. WSDL
Namespaces must be respected, use of a different namespace is essentially a different interface
SOAP action should include namespace, e.g. ‘
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

4. 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

5. 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

6. 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

7. 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

8. 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 )
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?

9. 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

10. 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

11. 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

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

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

14. 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

15. More Information UISOL web site: http://uisol.com
EPRI web site: