Additional Blogs by Members
Showing results for 
Search instead for 
Did you mean: 
0 Kudos

Over on Bluefin Solutions, DJ Adams wrote a great blog on the history of SAP Integration, finishing up with a discussion on Project Gateway. You can find his blog here.

I have to admit that I'm a little skeptical of what Gateway will bring. Admittedly, I've never touched it, and have only seen it in action at Tech Ed, but the buzzwords that I keep hearing are Atom, OData and RESTful. This sounds great, but surely the questions to ask are why Atom, why OData and RESTful - are you sure?

Firstly, Atom as a representation has proved itself to be valuable outside its original domain of news articles and blogs. Almost everyone has an Atom library, and its metadata allows clients to add searching and sorting etc without needing to understanding the source of the data. That said, should every list be a feed and each item an entry? Doesn't this generic representation of the data confuse the original meaning. We work hard in our code bases to use intention revealing names derived from our Domains. Should we just accept that we will lose this in the Atom representation of our data. Surely parsing XML or JSON is not a complicated task, so why should our only representation be Atom (In saying this I admit that I'm unaware of any other representations - other that Atom as JSON - being supported by Gateway at this time - can I custom code a simple XML representation of my resource - no idea - happy and hopeful to be proved wrong). I guess the crux of the point is this - Why use Atom when its not an appropriate representation for your resource, adding overhead when its not required. I'd like to have this type of choice with Gateway. If I just want a list, I want to be able to get just a list.

My other concern is the adoption of OData. OData, like GData, is an extension of Atom. While GData is used specifically for Google APIs, OData is being pushed out to the community by Microsoft as the Open Data Protocol. What do I get from using OData? I get a lot of stuff in a Microsoft namespace - and metadata that is based on the Entity Data Model (does anyone really use that???). Apparently if you are rolling your own OData messages, the EDM Metadata is optional, but if you plan on generating Proxies, some form of Metadata is needed. I'd assume that it's the same Metadata that is driving the code generation tools shown at Tech Ed. Will this be a mandatory step in Gateway, or if I never plan on generating a proxy/iPhone app, can I just build a Atom representation without this additional metadata?

Assuming you want the additional metadata, in OData the easy way to build this Metadata is the EDM - has SAP built a similar tool in Gateway to build this? Are we looking at another repository to add to the growing set in our landscape? Are we modelling Resources in the REST sense, or Entities in the Domain sense - we may choose to represent our domains in different ways and expose them to the world, but the list of what is considered a Resource is much larger that what is considered an Entity. Can we model both in Gateway?

Atom schema extension through OData (and maybe SData if this is what SAP choose to call their protocol) need to be considered carefully. Extensions need to be done in such a way that they help specialised clients that understand the extension, but don't break generic clients. My concern is that we'll go down the specialised client path if the impacts of our extensions aren't understood by those using the tools.

Finally, the OData protocol breaks REST in a number of ways - will Gateway be the same? Is it really RESTful, or is it just Atom (with extensions) over HTTP. The OData protocol doesn't use the standard HTTP interface (MERGE is added via the HTTP header), its Batching capability breaks Caching, and the OData query language does some nasty things with URIs rather than just using Forms and Links - which may mean ongoing maintenance as resource locations change - it also means Clients may be building URIs which is not really a good thing...

And I know this is for backward compatibility, but I have to admit that when I saw the screen scraper being used to activate a transaction for use via Gateway I was a little uncomfortable. I'm hoping that while all this is going on, SAP is also addressing the application architecture such that there is no business logic in the GUI, so tools like Gateway and WebServices can operate at the Application/Services layer rather than at the GUI layer. This will help both those SOA and ROA people to access the underlying SAP data and functionality.

I guess we'll need to wait and see - right now Gateway is just a word with much promise - hopefully it will deliver some of this - I'm just hoping that its done right, and not already compromised.