Saturday, May 3, 2014

Encoded vs. Literal & RPC vs Document WSDL Types

This article http://johnderinger.wordpress.com/2009/10/25/wsdl-binding-styles/ pretty much spells it out. The Takeaway is that Document Literal Wrapped makes the most sense because while staying WS-I compliant by having only one element under body, that element is the method name, so the method parameters, which in RPC style were separate messages, are wrapped in the method name (note "wrapped" actually refers to the fact that the method parameters are not shown in the WSDL message 'part' but "wrapped" or in other words exist implicitely by virtue of element reference to corresponding element of method in attached schema) in both the WSDL message and WSDL types schema under a complex type. Note, in Document Literal the complex type contained no method name neither did the actual soap message (the message as seen being sent by the client over the wire, not the portType/message WSDL elements) so the message could not be validated or dispatched properly.
So my take is:
RPC encoded - not JAX-WS compliant (must use JAX-RPC or AXIS)
RPC encoded and literal - both easily dispatched because method name is in soap mesage body, but soap message cannot be validated
Document literal - not easily dispatched because there's no method name in the soap message body -- the fact it can be validated doesn't mean much then
Document literal wrapped - best of both worlds: method name included in both soap message body and in type schema

Monday, April 28, 2014

Undefined vs. Null

Was asked this. Presumed it's JavaScript. Answer here: http://saladwithsteve.com/2008/02/javascript-undefined-vs-null.html
Basically one must keep in mind that an uninitialized variable (var a;) is undefined NOT null.
To be accurate when comparing, i.e. if to determine whether is undefined (unset) or null (set to null) use ===, i.e. if (a===null) or if (a===undefined); don't use (a==null) because that will be true regardless of null or undefined due to type coersion.

Saturday, April 19, 2014

Singleton vs. Transient

In the context of an IoC container (see http://docs.castleproject.org/Default.aspx?Page=LifeStyles&NS=Windsor&AspxAutoDetectCookieSupport=1) singleton is created once and reused for injection to dependent components when needed. Transient dependencies are created anew each time they are injected. Transient objects are released when the dependent object is released unless the dependent object is the root of the graph (the root of the graph is not managed by the container), i.e. Resolved explicitely -- in which case the transient must be Released explicitely or face potential memory leaks.

The transient keyword in the context of Java indicates to the writeObject method of the ObjectOutputStream that the field should not be considered part of the object state and thus not serialized.

Wednesday, March 19, 2014

SEI = "Service Endpoint Interface"

"Interfaces are better for sharing with the developers who will be responsible for developing the applications consuming your service. ... The service endpoint interface (SEI) is the piece of Java code that is shared between a service and the consumers that make requests on it."
https://cxf.apache.org/docs/developing-a-service.html

example of SEI: http://www.mkyong.com/webservices/jax-ws/jax-ws-hello-world-example-document-style/ - see step 1