Web services Thursday, May 08 2008
I just finished creating an implementation of a standard called ALE (Application Level Events) created by EPCGlobal (an organization managing EPC standards for RFID). The ALE standard (it's actually still a proposed standard, up for minor review) is a way to retrieve data agnostically out of a number of various RFID devices. ALE provides a webservice interface and thus a WSDL and XSD representing the documents to be passed in and out of the service. This is the first time I've ever created a webservice from a WSDL. The process wasn't terribly difficult:
* Use XSD.exe to create objects out of the XSD documents.
* Tweak the objects to look nicer (properties, new names, etc) but keep the XML serialization attributes the same so they produce the original XML.
* Use WSDL.exe with the /server option to create a WebService class that you can import into your project and implement.
My first problem communicating with pre-build java clients and servers were that .NET had little things slightly wrong, forcing me to tweak the XML serialization attributes. My second problem, and harder to address (harder to discover, easy to address) was that ASP.NET requires the HTTP header SOAPAction to be set with a fully qualified action name. The SOAP spec, however, states that a missing SOAPAction header means the server should inspect the SOAP message for the action, which MS clearly ignored. The fix was just publishing that information to the java clients and they tweaked their side to accomodate.
I used to consider webservices, WSDL, and XSD the kind of thing that nobody should ever look at; the things that toolkits should produce and consume for you, thus leaving you in your happy world of .NET or Java or Python or whatever. This left me to simply create my webservices after the fact and without much thought to the structure of what I was doing. Thus, I was ignoring the design of the web services and favoring the design of the code that ran the web services. The fact that I'm ignoring the design of something is actually quite appalling to me now. Why would I ignore the design of my web services? I don't ignore the design of my database. In fact, I put quite a lot of work into designing a "correct" database structure for my data, regardless of the objects I am going to put on top of said data. Why would I ignore another data representation mechanism of my system?
I've read into Service Oriented Architecture, and I've never thought very much of it. In fact, I still don't. It's simply a way to dumb down the complexity of a large system or subsystem into a set of consumable services. While that may be harsh, it is definitely true. Just as true as a relational database is a way to dumb down the complexity of my large set of domain objects into tables and columns. My database doesn't hold any functionality other than being a convenient way for me to store my data; a web service doesn't hold any functionality other than being a convenient way to expose my data to a technology-agnostic set of clients.
I responded earlier to a question by someone on a mailing list. The question was basically "why do I have to add public default constructors and setters on my properties to expose my objects through webservices? I assume that pushing the existing object's data into an xml serialization/web service specific object before is a bad idea.".
(part of my response)
Realize that web services are a document-based communication mechanism. As much as you want to imagine your objects being magically transformed to XML and back to your objects again, what is really going on is your objects are converted into an XML document that can be sent to clients that can receive XML documents. Regardless of technologies, you still have a document as a transport mechanism. That said, it does make sense to have a special facade on top of your domain objects to represent them in a document-based form. While this can be a real PITA, it's not a terrible design decision since you keep your privates private and your publics public. The only downside is that now you have two representations of your objects, the good ones and the document-friendly ones (although, that's not too different from using a relational database and manually mapping data in it to objects).
(end)
What is apparent to me now, that used to not be, is that my webservices give me structured data and nothing more. That data still needs to be reformatted to fit in with the rest of my system and processed accordingly (and conversely, I need to adapt the rest of my system into a data structure appropriate for return from my web service) as opposed to just pusing my domain objects through the webservice (because frequently, a domain object isn't appropriate for a document-based system and I need to go through the manual step of creating an appropriate document structure to fit it into).
* Use XSD.exe to create objects out of the XSD documents.
* Tweak the objects to look nicer (properties, new names, etc) but keep the XML serialization attributes the same so they produce the original XML.
* Use WSDL.exe with the /server option to create a WebService class that you can import into your project and implement.
My first problem communicating with pre-build java clients and servers were that .NET had little things slightly wrong, forcing me to tweak the XML serialization attributes. My second problem, and harder to address (harder to discover, easy to address) was that ASP.NET requires the HTTP header SOAPAction to be set with a fully qualified action name. The SOAP spec, however, states that a missing SOAPAction header means the server should inspect the SOAP message for the action, which MS clearly ignored. The fix was just publishing that information to the java clients and they tweaked their side to accomodate.
I used to consider webservices, WSDL, and XSD the kind of thing that nobody should ever look at; the things that toolkits should produce and consume for you, thus leaving you in your happy world of .NET or Java or Python or whatever. This left me to simply create my webservices after the fact and without much thought to the structure of what I was doing. Thus, I was ignoring the design of the web services and favoring the design of the code that ran the web services. The fact that I'm ignoring the design of something is actually quite appalling to me now. Why would I ignore the design of my web services? I don't ignore the design of my database. In fact, I put quite a lot of work into designing a "correct" database structure for my data, regardless of the objects I am going to put on top of said data. Why would I ignore another data representation mechanism of my system?
I've read into Service Oriented Architecture, and I've never thought very much of it. In fact, I still don't. It's simply a way to dumb down the complexity of a large system or subsystem into a set of consumable services. While that may be harsh, it is definitely true. Just as true as a relational database is a way to dumb down the complexity of my large set of domain objects into tables and columns. My database doesn't hold any functionality other than being a convenient way for me to store my data; a web service doesn't hold any functionality other than being a convenient way to expose my data to a technology-agnostic set of clients.
I responded earlier to a question by someone on a mailing list. The question was basically "why do I have to add public default constructors and setters on my properties to expose my objects through webservices? I assume that pushing the existing object's data into an xml serialization/web service specific object before is a bad idea.".
(part of my response)
Realize that web services are a document-based communication mechanism. As much as you want to imagine your objects being magically transformed to XML and back to your objects again, what is really going on is your objects are converted into an XML document that can be sent to clients that can receive XML documents. Regardless of technologies, you still have a document as a transport mechanism. That said, it does make sense to have a special facade on top of your domain objects to represent them in a document-based form. While this can be a real PITA, it's not a terrible design decision since you keep your privates private and your publics public. The only downside is that now you have two representations of your objects, the good ones and the document-friendly ones (although, that's not too different from using a relational database and manually mapping data in it to objects).
(end)
What is apparent to me now, that used to not be, is that my webservices give me structured data and nothing more. That data still needs to be reformatted to fit in with the rest of my system and processed accordingly (and conversely, I need to adapt the rest of my system into a data structure appropriate for return from my web service) as opposed to just pusing my domain objects through the webservice (because frequently, a domain object isn't appropriate for a document-based system and I need to go through the manual step of creating an appropriate document structure to fit it into).
I was wondering where I can find an ALE specification document. Can you provide me a pointer?