SOAP Component

[mageshbk]

I have added a SOAP Component to SwitchYard that has barebone facility to invoke/host WebServices. The README has more info on this. Code is published here:

https://github.com/mageshbk/soap

Please, let meknow your comments/suggestions/questions/feedback.

thanks,

Magesh

[kcbabo]

Thanks for blazing the trail here, Magesh.  I was able to compile and test your code after making two changes:

1. Tom C's recent check-in changed MockHandler so that the _messages field is private.  This causes a compilation error in one of your test classes.  Once I changed the test to use getMessages() instead of _messages everything was cool.
2. Your test class binds to a port < 1024, which requires sudo privs and is inside the IANA well-known ports range.  My recommendation would be to make this configurable via system property and default to something high and unreserved (e.g. 48080).

I scanned the code and I think this is a good start.  I plan on wiring this up to the bean component to see what explodes. :-)  Some initial comments:

• It works ... yeah!  :-)
• The current structure appears to be that a SOAPGateway instance is created for each WS endpoint you want to consume or provide.  Eventually, I expect that we will have a single SOAPGateway instance which creates and manages the lifecycle of multiple consumer and provider instances.
• Why are you using bytecode generation to create the provider instance?  You should be able to use an implementation of Provider<SOAPMessage> directly when you create your endpoint.
• What do you envision as the use case for pluggable MessageComposer and MessageDecomposer instances?  I noticed you accept this as a config parameter and there's code in InboundHandler and OutboundHandler to resolve it.
• DefaultMessageComposer and DefaultMessageDecomposer assume String as the message payload format.  Shouldn't this be XML?
• InboundHandler looks like it's called each time a SOAPMessage is received by the Provider implementation.  If that's the case, then the _response variable can be polluted if multiple requests come in over different threads.

cheers,

keith

[tcunning]

I blame checkstyle!

[mageshbk]

Thanks Keith!

The port was just a test, to show that SOAPGateway can be configured with a custom port. By default it uses 8080, if none specified. I will update the test to use higher ports. Eventually I guess the SwitchYard configuration would be the final one to configure these, so we can defer the system property.

SOAPGateway instance which creates and manages the lifecycle of multiple consumer and provider instances.

I mentioned in the README that throttling has not been thought of. I had a thought that we can magically make components extend some lifecycle interface that a separate Lifecycle Manager would handle. Shouldn't the lifecycle and throttling have common factors for any component?

Why are you using bytecode generation to create the provider instance?

To override the wsdlLocation, serviceName, portName through the @WebServiceProvider annotation. This to create a Class file for deployment if we take that route in future.

What do you envision as the use case for pluggable MessageComposer and MessageDecomposer instances?

In future if users want to customize the way the SOAPMessage is transformed into Message and vice versa. Maybe they want some proprietary  SOAP Headers to be transformed into the Message's context unlike the way we will do by default.

DefaultMessageComposer and DefaultMessageDecomposer assume String as the message payload format.  Shouldn't this be XML?

It is easy to work with Strings, thanks to XMLHelper . As explained above we can configure the Composer/Decomposer pair to handle them as XML payload if necessary.

_response variable can be polluted if multiple requests come in over different threads.

Yes, I need to redesign this.

Magesh

[kcbabo]

The port was just a test, to show that SOAPGateway can be configured with a custom port. By default it uses 8080, if none specified. I will update the test to use higher ports. Eventually I guess the SwitchYard configuration would be the final one to configure these, so we can defer the system property.

Yes, the service configuration will set the port, but it should be possible to unit test the SOAP Gateway (as you do today) without a switchyard configuration.  That's why I mentioned the system property - it's a convenient way to override the default settings used by your unit tests between build environments.  I would *not* expect this to be use in the actual runtime - just the test scaffolding that sets up the gateway.

I mentioned in the README that throttling has not been thought of. I had a thought that we can magically make components extend some lifecycle interface that a separate Lifecycle Manager would handle. Shouldn't the lifecycle and throttling have common factors for any component?

I think we crossed wires here.  There will be a single SOAP Gateway that is responsible for creating SOAP consumers and providers (InboundHandler and OutboundHandler in your impl) in response to deployment activity.  It will also be responsible for starting and stopping these consumers and providers in response to lifecycle events (e.g. stop application "HelloWorld").  The SOAP component will not be implementing its own deployment or lifecycle framework, but it will be responsible for doing the needful in response to events generated by our common deployment and lifecycle framework (which will really just bridge to the containing platform -- AS, OSGi, etc.).

In any case, there's no need to change anything on this front now.  Just pointing out that once we sort the deployment, lifecycle, and management contracts we will need to revisit this aspect of SOAP Gateway.

To override the wsdlLocation, serviceName, portName through the @WebServiceProvider annotation. This to create a Class file for deployment if we take that route in future.

I think it would be best to address the separate deployment case if/when it's required.  For now, can we remove the bytecode generation and just use an implementation of Provider?

In future if users want to customize the way the SOAPMessage is transformed into Message and vice versa. Maybe they want some proprietary  SOAP Headers to be transformed into the Message's context unlike the way we will do by default.

Yeah, fair enough.  If it's a very specific issue related to composition of the SOAP message, then I can see that use case.   For general purpose transformation of the message body (say between String and XML format), then this is not the mechanism to use.

It is easy to work with Strings, thanks to XMLHelper . As explained above we can configure the Composer/Decomposer pair to handle them as XML payload if necessary.

Default for SOAP Gateway should be accepting and producing XML.  We will have functionality in place to convert message formats in a simple/declarative way based on the service definition, so the fact that it's easy to deal with Strings shouldn't be relevant to which format SOAP Gateway uses for payloads.  Another consideration is that if the person consuming a message from the SOAP Gateway wants XML, they now need to parse the XML out of the String.

[mageshbk]

Keith Babo wrote:

Default for SOAP Gateway should be accepting and producing XML

Do you mean that it works with org.w3c.dom.Document or a javax.xml.transform.Source?

Keith Babo says:

Assuming you are using Provider<SOAPMessage>, the SOAP Body will be accessible as a DOM Element. Might make sense to start there. This also has some relevance to MessageBuilder and transformation, which is why I would like to chat about it in the forum.

[mageshbk]

Made a few updates on the repo:

Modifed to work with DOM Element as Message content
Updated test to use org.switchyard.saop.webservice.port System Property
Deleted Provider Class generator 

[mageshbk]

Made InboundHandler ThreadSafe