Now that a few months have passed since SAP released NetWeaver Gateway, and we’re starting to see more implementations of it in the wild, I’m seeing more and more discussions in the community about the finer points of Gateway and REST in general.
One opinion I have come across is that NetWeaver Gateway should be merged with PI rather than remain as a separate product with its own technology stack. That way, PI will remain SAP’s “go to” integration hub and customers can avoid standing up further systems and the maintenance overhead that entails.
As a relatively recent convert to the ‘religion’ of RESTafarianism, and having done a bit of PI work over the past few years, I of course have an opinion here: “Don’t do it!”.
Let me explain:
REST is not a Protocol
REST is an architectural style; a way of architecting system interfaces rather than a formal protocol which one can implement. REST defines a set of principles and constraints. When we design interfaces within these boundaries, then we have something which is RESTful. This can take many shapes of course, as there is no check list or W3C standards document or reference implementation which someone can comply with.
SOA is another, different architectural style. It requires system interfaces to be self-contained services, with defined inputs and outputs, which are separable, minimise side effects, etc. It does not require per se the use of Enterprise Service Buses, UDDI directories, etc. - these things usually appear in specific implementations of an architecture following the SOA style.
There are other architectural styles pertaining to system integration of course. Message Oriented styles come to mind, and there are others which are (unfortunately?) still used such as database integration. In fact, Wikipedia has a list of some.
Of Adapters and Middlewares
SAP NetWeaver PI has been designed from the ground up as a message oriented middleware product with some ESB features. Over time, these ESB features have grown as SOA architectures became more common and desirable, and that’s A Good Thing. A good middleware product can speak as many protocols as possible, because there are many different implementations of those message-oriented architectural principles. It’s also likely that your middleware product will need to talk to another middleware product, and lots of protocol adapters help bridge the divides between two different implementations of the same architectural style.
But REST is not a protocol, and that is why the idea of a “REST adapter” doesn’t make sense to me. How do you write an adapter into a different architecture? If all you need is to simply send one request to one RESTful endpoint, PI already has the HTTP adapter which will be perfectly suitable for some simple scenarios. But beyond that, the fundamental differences between the SOA and MOM (Message-Oriented Middleware) architectural styles in PI’s DNA, and those of a good REST API, will be simply too great to bridge with an adapter.
Let me try to explain this gap by way of some examples:
- REST talks about clients and servers, and doesn’t talk about middleware. PI is middleware.
- RESTful APIs present hyperlinks to clients, which follow the links to modify state. How would PI do this?
- REST mandates no content format. In fact, it allows any content format you can think of. PI really only handles XML.
- REST requires clients to keep state in interactions with the server. PI is not good at that. (NW BPM will probably change this. NetWeaver BPM as a REST adapter? Now we might be onto something...)
- PI works best with asynchronous processing. REST does away with abstraction layers providing asynchronicity and relies on natural request/response mechanisms.
Now, I do think that PI should have the ability to interact with RESTful APIs; as middleware, its job is to talk to as many other things as possible. But the fundamental differences between these two worlds will preclude such an approach from being comprehensive or good for all use cases. It may work for really simple things, but it won’t be nearly enough to position PI as the “REST Adapter” into SAP systems. And that’s okay. We don’t need one integration hub to rule them all!
For my money, the NetWeaver Gateway team made the right architectural choices: hosted on an ABAP stack and with good tooling for accessing BAPIs, custom code, database tables and other APIs internal to an ABAP-based SAP system, rather than loosely coupled to the backend, hosted on a Java stack, or designed around existing functionality of existing products.
That’s not to say that Gateway is perfect, and there are some features which I would dearly love to see in the product. But in my opinion, SAP got the basics right by avoiding the temptation to make PI do something which it wasn’t designed for.
Image by Derick Bailey. Thanks for the Creative Commons license mate!
