views:

403

answers:

4

We have some standalone devices that will send XML messages to arbitrary processing software (may be developed by us, may be 3rd party) over HTTP. The messages are relatively simple, and will conform to an existing schema. No specific reply is necessary.

I suddenly find myself lost in a world of web service technology jargon. I'd like the following:

  1. To keep the devices as simple as possible, and not tied to any particular technology like SOAP (unless it's beneficial).
  2. To make it as simple as possible to consume the messages. For instance, I could just send XML over HTTP, but then the receiver would have to manually process the message (I think). It would be great if anyone could use WSDL-like tools to easily create consumers in any language.

Please help fill in the giant gaps in my understanding...and point me in the right direction. Thanks!

UPDATE: I should have made myself a little more clear. I'm not against using any "technology", I'm just looking for advice to strike a good balance. The standalone devices will have very limited capabilities, but enough to send an XML message over HTTP -- I don't want to complicate these things any more than I have to.

Then I can certainly just consume and manually process the XML messages..... but it would be neat if there was a way to generate this code (the way I can generate code from WSDL). What I've got is an .xsd describing the messages themselves, nothing more.

A: 

Could you programatically do a form post of the XML?

C# Programmatic Form Post

Pete Nelson
I don't see much mention of XML at that post. Can you clarify?
Robert Harvey
Rather than "string postData = "item1=11111" you would do something like "string postData = "xml=<MyXmlData><Hello>World</Hello></MyXmlData>";
Pete Nelson
@Robert Harvey: Since XML is just a string, all the server needs to do is accept a string and (possibly) return a string (ex. a XML response). Won't win any contests for cleverness, but it works and would be compatible with anything that can talk over HTTP (Java, C#, Delphi, etc)
KevinRF
+2  A: 

I know you said you want to stay away from particular technologies like SOAP unless they're beneficial, but one of the main benefits that well-defined technologies have are sets of tools for parsing messages in a consistent manner. Having said that, I don't think SOAP is right for you.

I would aim for a RESTful architecture since the messages are just plain XML and there are libraries for emitting and consuming REST-style messages in a variety of languages. You can typically hit the ground running faster with REST than with comparable technologies like SOAP, but there are still paradigms to learn.

Edit: You could describe your service using WADL which describes the RESTful architecture and includes any relevant schema. You could then use the WADL2Java tool or another WADL tool to generate the endpoint stubs. I think this approach is the closes to what you want to do while leveraging your existing schemas and not having to change your client code. Here is a sample WADL file and a little bit of info on it.

Zach
The nice thing about REST and the fact that it's really only XML is that the clients can be extremely simple. Generate your XML however you like and do a HTTP POST to your targeted resource. While RESTful services are typically used when access to resources is the number one priority, they have an additional benefit of being simple for the client. The service side can be as simple or complex as you like. JAX-WS (https://jax-ws.dev.java.net/) supports REST for Java servers. Spring Web Services (http://www.springsource.org/spring-ws) supports REST, as do other parts of the Spring framework.
Zach
Sorry, that link is broken for Spring Web Services. Here is one that works: http://static.springsource.org/spring-ws/sites/1.5/
Zach
+1  A: 

It seems to me that you want two contradictory things here. Anything that provides tools will be a particular technology.

However one possibility is this:

Apache CXF has a plain XML-over-http binding.

But it won't create consumers in any language. For that I really can't suggest anything except SOAP or REST.

bmargulies
I guess what I might be looking for is a way to generate a consuming service based on the schema (XSD) of the message. I don't want to have to "SOAPify" the messages being sent.
Boden
If you already have the schema of the message, then you're already about 75% of the way to SOAP. You could create a trivial WSDL embedding that schema, and use WSDL2Java to have a service endpoint generated. The hard part is writing the WSDL scaffolding, but not even really that hard (IMO).
Zach
@Zach - thank you. Do I have to modify the message at all? Changing the sender to alter the message in this case is the hardest part. If not then how is it SOAP? Is there a way to do what I want without modifying the message itself?
Boden
All SOAP does is wrap your XML is a pretty simple envelope. However, if you hate that, use JAXB directly, or XMLBeans, or something.
bmargulies
@Boden, I see what you're looking for now. If you used SOAP, you would have to modify your client code to wrap the outgoing XML payload in a SOAP envelope. See my edit to my answer above for information about WADL, which is the route I think you should take.
Zach
WADL is REST. (cxf also does that).
bmargulies
+1  A: 

Following on the comment above about WADL, you can also try WSDL 2.0. While not widely adopted yet, WSDL 2.0 does contain good support for REST style services. WSDL 2.0 is supported in Apache Axis2, which I think includes support in its WSDL2Java tool.

Lawrence Mandel
I just read an article about WSDL 2.0 a few minutes before reading this response. Good timing! :) I think it might fit.
Boden