WSDL Refresher

Powered by Qumana

<xsd:element> defines the elements, and can include complex types within it. One style/pattern of defining the elements is:

Style1

complex type 1

complex type2

element1 uses complex type1

element 2 uses complex type 2

then inside the wsdl:message the element is referenced using

wsdl:part name="anyname" element=element1

OR one can directly DEFINE the element inside the message as in style2

Style2

<wsdl:message>

element1 uses complex type1

</wsdl:message>

once the message is defined using the xsd types and user defined complex types, the message is used as part of an operation

<wsdl:operation>

<wsdl:input  message= messagename1 >

<wsdl:output  message= messagename2 >

One/group of operations form a porttype

<wsdl:porttype name=    operation=>

A porttype is thus a grop of technology independent interfaces.

However interfaces in the end need to be implemented using technology. A possible way of calling/using the interface is using SOAP (technology)

To take it to this next level, a binding is used.

<wsdl:binding type=portname>

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name=opName>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>

and same for o/p

but how will the binding be called? for SOAP its through a URI. This forms the service

<wsdl:service name="srvname">
<wsdl:port name="SOAPbindingname" binding="tns:TravelOneServiceSOAP">
<soap:address location="http://localhost:xxx/URL"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

<wsdl:message>

JNDI resource eferences and resource environment references

Powered by Qumana

The client/server app can have coded entries that are seperate from the FINAL environment JNDI entries. This helps in differentiating coding from application assembly.

So inside the code you may have ctx.lookup("java:env/jms/blah1") but using the concept of "Resource References" and "Resource Environment References" you can map it up to "java:env/jms/blah2". The blah2 should be valid in the actual production environment. This avoids the need to change code or deployment descriptors.

Take a situaiton without them: the coder puts in blah1, but the server has blah2 which is being used by other programs already! now either has to change!- thatz where this comes in.

The funny part is that ResourceReference supports DB, Qconnections etc but does not support Queues. The support for JMS Queues (and their reference mapping) is covered under Resource Environment References.

The resource reference covers AS administered only and hence queue is dropped out.