It all started with a tweet by SAP Mentor John Appleby (@applebyj)...
Quite a few people responded in short order via twitter with their thoughts on the topic. Aside from John being well known (and followed on twitter), this is surely indicative of the level of interest in the technology. Kudos to SAP for getting the community excited with their products! On a complete tangent, I just love how twitter has this ability to stimulate such exchanges in 140 characters or less!
So far so uncontroversial. Many of the conceptual architecture diagrams I have seen at TechEd and elsewhere follow this approach - like this one from MOB130 at TechEd 2011:
However, my position on the matter was a little different:
Go for Integrated Deployment
My response runs counter to the recommendation made in the admin guide quoted by John Moy, so let me try to explain why I feel an integrated (i.e. remote) installation of NetWeaver Gateway is usually most appropriate architectural choice.
NetWeaver Gateway is not that different
Like others, I generally see Gateway in much the same way as the SOAP Runtime or the Proxy framework which already exist in ABAP systems – an add-on to an existing system which provides interfaces by facading internal APIs like RFCs and BAPIs. Gateway provides another set of doors alongside the existing SOAP-based openings through which other systems can gain access to the data and functionality of the Business Suite. Those consuming systems need not worry about the proprietary protocols required for RFC communication but can choose to interact using open standards. Gateway simply provides another, different open standard in the form of OData to complement existing SOAP-based interfaces.
From what I saw during our hands-on work on the NW Gateway 1.0 “beta” program, and from keeping abreast of the evolution of this into v2.0, the product isn’t complex enough to warrant a separate installation in my opinion.
NetWeaver Gateway is not middleware
Gateway’s raison d’etre is to expose representations of internal resources (in the REST sense) from Business Suite systems. However, it doesn’t provide any tools for building OData representations by composing or re-composing existing data from multiple systems, or even from multiple different BOR objects, into a new aggregate representation. Essentially, anything which isn’t a subset of a single BAPI return requires custom ABAP code to be written.
In a central, stand-alone installation as shown on conceptual architecture diagrams like the one above, this ABAP code would have to get data from the various underlying sources from which the single exposed OData resource is composed from. How would this work? Gateway doesn’t (yet) provide any mechanisms for consuming SOAP enterprise services and only relies on RFC calls. Not nice. In order to call SOAP web services, I would have to write custom code to aggregate the returns of multiple calls to ABAP consumer proxies into something the Gateway runtime can then transform into OData. So lots of "glue code". Of course, anything is possible using custom code, but I would expect some actual tooling here if the vision of a central, stand-alone Gateway deployment is to be realised. Middleware systems like PI do provide such tooling and don't require developers to write lots of mundane glue code...
This leads me to conclude that a single, detached layer of Gateway composing OData resources from a variety of backends is essentially wishful future-state thinking rather than something which customers can adopt right now using Gateway 2.0 and without much fuss and coding. I do have some ideas on what I’d love to see in Gateway 3.0, but that’s the subject of a future blog...
Efficiency wins!
One of the appeals of designing APIs in accordance with REST principles is their greater simplicity compared to SOAP and the associated WS-* mess. To me, any kind of “application gateway”-style translation or bridging – such as building up a RESTful representation by making 3 SOAP/RFC calls to the same backend – negates a lot of the efficiency benefits of REST. One could even argue that it makes things worse by adding another layer of complexity/failure.
When all else fails...
Security, rate-limiting and auditing benefits of a stand-alone instance are pretty weak arguments here as well. Maybe I’m being cynical here, but I only ever see these come up once all other arguments have been exhausted.
I struggle to see customers exposing any ABAP stack to the Internet without some kind of application gateway or reverse proxy in front of it. Once you have that layer, the security arguments espoused in the admin guide become moot. Those specialised tools are much better at security, auditing and rate limiting than Gateway or any other general-purpose system is ever going to be. It’s their bread and butter after all! Specialist vendors like apigee, Layer7 or Mashery offer API gateway products with very impressive features around load balancing, throttling, DoS protection, SLA enforcement and versioning of Internet-facing APIs. Companies are likely to want only one such API gateway because there are economies of scale here. And since they will likely want to provide APIs from non-SAP systems as well, using Gateway for this role does not seem attractive.
Go for the simple option!
So in my mind, installing Gateway on each Business Suite system is preferable as it is the simplest option and provides some advantages over a stand-alone deployment.
Companies with multiple systems such as CRM, ECC and SRM may end up with multiple Gateway installs. But because Gateway is pretty painless to install and configure and essentially runs itself, this should not cause any discomfort.
If there ever is a requirement for a stand-alone instance, and the product has some decent tooling which makes such a thing worthwhile, then this can always be retrofitted to result in a hybrid landscape. Nothing wrong with that. In my mind, that is no different to modern SOA deployment architectures, whereby most systems have SOAP stacks which may (or may not, depending on your beliefs) be supplemented with a central SOAP stack in the form of an ESB.
...but it depends...
One big hurdle right now is the fairly demanding version requirements. Unless you’re running NetWeaver 7.02 SP7 or later in your Business Suite system, an integrated install is a non-starter. However I am sure this will change for the better; it was mentioned in passing at TechEd that Gateway is planned to be on its own release track in the future and this could improve the situation, or (fingers crossed!) even result in it becoming available for older releases?
If you must have NetWeaver Gateway right now and your Business Suite does not meet the version requirements, then a stand-alone install on a small ABAP stack is always an option, and it’s great that SAP have provided a choice here. However, I would only ever regard this as a tactical solution.
The above does not apply to the Sybase Unwired Platform in my mind. SUP is a much more complex (read fully-featured) product with its own architecture, persistence, management mechanisms, etc. and is not closely coupled to any backend implementation in the same way NetWeaver Gateway is. In my opinion, SUP is well deserving of its own installation, and I can see a single instance serving all connected mobile devices and backends.
Thanks are also due to my colleagues John Moy (@jhmoy) and Jacek Klatt (@yatzeck) for being passionate and knowledgeable discussion partners in an email exchange of views on John Appleby’s tweet which ultimately led to this blog.
- SAP Managed Tags:
| User | Count |
|---|---|
| 53 | |
| 5 | |
| 4 | |
| 4 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 |
