REST facilitates the last mile of integration. This may be from within the enterprise to foster enterprise mashups or to be consumed from afar across the internet in ways unforeseen.
The simple fact is that you may need/want to rely on Rest on the edge, but you may also want to leverage SOAP’s security mechanisms as you get closer to your enterprise foo (ERP, CRM, etc.).
I was recently introduced to the notion of Anemic Objects while discussing schema first or POJO first xml definition. I come from the camp of schema first and considered the resulting java objects to be just a normal side effect from this approach. The alternative has scary ramifications from a system design/interoperability perspective.
Before I get into my thoughts on either approach, lets cover what an anemic object is. According to Martin Fowler, they’re an anti-pattern.
The fundamental horror of this anti-pattern is that it’s so contrary to the basic idea of object-oriented design; which is to combine data and process together.
The service, or business, objects are responsible for extracting the required bits and performing everything from validation to the actual business logic.
So is schema-first really a cause for this problem? Casually speaking, yes, but I believe it’s mostly due to the ease of code gen and focus on ease of development. For most developers, learning WS-Schema is not a simple undertaking, just like learning any language or standard. If I know Java, and a tool will create the required artifacts for me, then I can ignore what’s generated as long as it keeps in sync with my domain model.
Keeping in sync with a domain model can be challenging when a developer doesn’t control the underlying schema. Think about experiences of mapping a robust database schema to an object model. The relational/object impidence has resulted in numerous frameworks, Hibernate, JDO, JPA, EJB, Toplink and many more, to handle these differences. Even then, all allow for a way to just use plain SQL and do the mapping yourself. The same mismatch applies to XML Schema as well. There are various frameworks, JAXB and XMLBeans for example, that help out in this area as well.
It’s easier to allow the Domain Model to drive these models or to just consider any schema-first output as a second class object or bit bucket. I’ll admit to subscribing to the latter. As an enterprise architect, it’s easier to think in terms of data schema and service endpoints that act on it. WS-* and REST both encourage this type of behavior. For the developer on the ground, this can be limiting as it does not help promote OO design.
Indeed often these models come with design rules that say that you are not to put
any domain logic in the the domain objects.
But it doesn’t have to be that way.
I’ll pick on the automated build process for a moment. I think what happens is that the auto-gen of either Schema or POJO gets baked into the build process and developers forget. The output is a secondary though that is constantly sync’d with their domain. The problem is that those external parties that rely on those artifacts are also treated as second class. A developer changes and external interface contract without even thinking. This is the part that is scary
The middle ground is to use the schema gen once and lock it down. Put it in the repository and protect it with the walls of governance. The auto-gen can still place, but it needs to also verify that it has not broken the contract. This way, a schema that started from a POJO and given an official approval as the external interface is protected form unwarranted change, and the developer is granted the ability to grow the POJO into the rich domain model they want.
This approach places constraints on the evolution of a domain object so it’s not recommend that some time be taken to get the domain object as close to the use case/user story as possible. Any evolution will be quickly detected and signal integration or legacy concerns immediately.
Anemic models can be address with a slight change in build process and a stronger embrace of the binding tools that typically generate them.
I cam across this article on InfoQ, written in August 28th, 2006, with Mark Baker, a proponent of REST. I don’t think I ever understood what being RESTful is about until I read Mark’s statement about not using custom XML. (emphasis mine)
InfoQ: So to be clear about this - does this mean that if I want to develop a RESTful application, I can only use standardized message formats? Some custom XML format of my own would be ruled out?
MB: Strictly, yes, but remember that REST is an architectural style for very large scale systems. If you’ve got a proprietary data format that you need to use, say, behind your firewall, or even between two companies that long ago agreed to use this format, then you can still gain a lot by moving *towards* REST (by adopting the uniform interface, URIs for identification, etc..), but you won’t quite reach it in this case because of the data. And there’s nothing wrong with that per se. All it means, and all that REST is telling you, is that the data in these messages won’t mean much to the outside world.
I’ve always held that belief that REST is great as a last mile/common ground for B2C services. If you need massive reach, then REST is probably the most approachable “architectural style” out there.
However, there are massive scale systems internal to an organization. Where it makes sense, XML has been standardized (FIX comes to mind) and could be used in a RESTful architecture. However, I’m sure this protocol was born out of interbank transfers and A LOT of discussion. Architectures built using SOAP can leverage these standard interface and provide interfaces that specific to a particular business context. URI are just as important in WS-* as they are in REST.
I think that creating a custom infoset for a particular service is very important regardless of WS-* or REST. If anything, REST has made me more aware of this fact.
I’m finding this discussion about the importance of the URL for RESTful APIs quite interesting.
I, somewhat naively, thought one of the major goals of a RESTful design is creating a URL that is human readable. According to Hugh Winkler, this isn’t necessarily a pattern that should be practiced.
“You don’t say this explicitly, but it sounds like “designing an API” means, you are designing a formula that programmers of client programs can use to construct a query url.
If that is what you mean, well, I wish we’d do less of that.”
Hugh, goes on to discuss the use of XForms to present a user with an interface to create the query that follows the http://example.tld/path?query1=foo&query2=bar. Again, I’m kinda amazed to see this recommendation coming from the REST camp.
If this advice is followed, it doesn’t seem like a far jump from using the XForm runtime to generate a SOAP envelope and simply deliver it to a WebService. I guess, the only difference is that you don’t use an action other than the implicit GET/POST/PUT/DELETE.