"Is there a market for people who want to do mashups of parts catalogues, flight details, account balances, store inventory, share trades etc. with only cursory security, and what the issues are with data consistency, update etc." – Mark Cathcart
I argued last week on mainframe blog that many developers are SOAP dodgers, and prefer RESTful interfaces so IBM should offer native XML access to mainframe data not just SOAP-mediated mechanisms.
SOAP is one thing-but in many respects native XML is more interesting because it potentially enables more RESTFUL development and data access models. If I am a mainframe shop that wants to offer an online information service, its likely to get more consumers if I offer a more lightweight API, rather than forcing everything through SOAP. SOAP is anathema to many Web 2.0 developers, and IBM definitely needs to position z for Web 2.0. IBM needs to think more about XML data sources not just XML Web Services.
I got a little pushback from Mark, the guy that taught me much of what I know about mainframe architectures. So what’s the story?
I believe that developers are smarter than I am, and will find interesting things to do with data if its available.
Maybe Sabre Geek has some idea – Sabre probably does all kinds of weird stuff with its TPF data… what do the APIs look like?
The basic question, however is probably not down to grassroots developers but to large enterprises and service providers that have interesting data on mainframes. This is a data governance and innovation, rather than technical question. All in all though – I tend to think the eBay experience is salutary. You can bring a developer to your API library but you can’t make them wash their mouth out with SOAP.
Corporate development shops will be hobbling themselves, from an innovation perspective, if they only provide SOAP access to data for developers. I don’t think the mainframe is any different from other platforms in this respect.
In answer to Mark’s question about security and data consistency I was thinking primarily of read-oriented applications.
So what do you think?
Tags: REST, zSeries, SOAP, WS-*, WS-I, SOAP dodgers, Sabre Geek, Mark Cathcart, XML
Ric says:
May 10, 2006 at 5:21 am
We have (not necessarily with much forethought) so far tended to use REST for internal (i.e. Intranet) access to data, and SOAP for external. Behind the firewall Mark’s security concerns are minimised, and the “ceremony” required for what is primarily ‘read’ access is less.
Dan Davies Brackett says:
May 10, 2006 at 5:34 am
SOAP is not the problem.
SOAP is a very well designed envelope format, and it should be more widely used (yes, even with RESTian interfaces). If your application ever needs to store data on behalf of someone else (that is, if you have any message-passing components) you’re going to need a message format, one that gives you metadata if you need it and stays out of your way if you don’t. SOAP is as good an envelope format as any, and it’s certainly better than coming up with your own. I mean, it’s right there!
The problem is that, for the reasons I have above, SOAP is used as the message format for RPC–I mean, CORBA–I mean, RMI–I mean, WS-*. And it’s *that* that I object to as a developer. There are two big problems I see with object oriented remoting standards:
(1) they hide the network from developers
(2) they try to be everything to everyone.
(1) is a big, huge, ENORMOUS problem. A fantastically large amount of effort is going into “making remote interfaces act the same as local ones”, which ultimately is the point of all the technologies derived from WSDL. The issue with that is that *the network is there*. You can hide it, but that doesn’t mean it goes away. And when you design to hide it, that means that the first time an application written with JAX-WS (I’ll stick to Java-land, since I don’t know .Net very well) fails because of a network error, now the poor sod on whose lap it landed HAS TO LEARN ABOUT THE NETWORK ANYWAY. And network failures are not rare. Therein lies the downfall of Object Orientation On The Network.
(2) is something that results from the technologies involved being too enterprisey from the start. There are so many stakeholders involved in the first rev that there have to be little bells and whistles on the standard for anyone who might, at some point in the future, want to think about using it — which does Make Hard Things Possible, yes, but only at the expense of Making Easy Things Hard. I can describe in 3 sentences how to write a program that consumes a RESTian web service, but to do so with JAX-WS requires page after page of “now set the parameters on *this* object *that* way so the framework can write a bunch of code for you”. Instead of being a generalizable, but specific, set of technologies it’s a general-purpose general-purpose platform platform.
…but you’ve already heard all these arguments from better spoken people than I. I just wanted to point out that SOAP is more like the baby than the bathwater — which doesn’t mean that bathwater doesn’t need to be *catapulted* offa my Internet 😉
Juliao Duartenn says:
May 13, 2006 at 2:07 am
Disclaimer: most of my work life was spent in banking and insurance. YMMV in other industries, I’ve been involved in some areospace projects, sattelite data collection and such, and in a number of telco gigs, and REST does seem more appropriate in those environments. But today I’m writing from a financial services point of view.
Even for read interfaces there are – more often than not – security requirements. Not everyone can read all data, not all servers can consume all interfaces, some people have access to aggregate figures but not to individual items. And with this need for control – be it real or just perceived by the users, but, after all, they’re your customers, most people don’t just code for fun – there comes a need to make control centralized and enforcable. It just doesn’t make sense to have every single application, every single service, every single datasore implement their own versions of access control, permissions, data visibility, and auditing.
I agree that WS-* is something of a mess. It was designed by commitee, it was design with no regard for practicality, I know all the excuses. But the same problems have existed in all call interfaces that came before, and most of the time it was even worse. Having a bandwagon join behind WS-* would, at least, have the benefit of doing what CORBA could not do, defining a worldwide call-interface standard.
But, as I’ve said so many times, the “good” thing about standards is that there are always (at least) two (thinks ASCII and EBCDIC, 220 and 110 volts), and human kind has again fulfilled this promise. Even before WS-* was fully deployed and understood, a number of “smart” fellows decided they could always “cut some corners” and came up with REST. Of course it’s potentially slower. Of course it’s more complicated. If I think about solving only MY problems I can always come up with something faster and easier.
But it doesn’t cover a lot of people’s needs – needs that have driven WS-* to be – at least partly – as not-simple and not-fast and not-easy as it is. And it’s because of those people that REST can not be a universal solution – unless people start grafting other features upon REST, and end up having another WS-*, which they will always claim is better, because it’s their WS-*, not someone else’s.
Some of us have been around long enough to see all this happen before. Me, i’m still an optimist at heart. I really had hopes that WS-* could be “the one to rule them all”. Not that I like it, but I was willing to concede personal liking to standardisation. Apparently, a lot of people didn’t agree. Another chance missed – history, again, repeats itself.
Mark Cathcart says:
May 13, 2006 at 4:40 am
James, thanks for the opportunity to discuss. I guess I’d rather avoid the emotional and practical discussion comparing REST/SOAP for now. When I posted to your m/f System z and SOA blog entry I really wanted to hear some ideas on how you though m/f data could be exposed directly via XML and what uses it would be put to.
I assumed when I proposed it, that the relevant subsystem designers would be all over XML as it was such an obvious thing to do, even though IBM did not formally adopted XML until 9/�99. Their initial response was based purely on the state of XML back then and the related performance concerns of parsing XML, in what are high performance transactional subsystems. Over the next few years when ever we looked at specific requirements there seemed to be more suitable alternatives, often not requiring XML at all.
The requirement to simply expose XML still seems obvious, if anything, more so given many of the innovative new WEB 2.0 world. However, when you look at the real business requirements/needs, once again an alternative(Java or J2EE connector, CGI, etc. etc.) seemed to be the answer. I posted in the DB2 link in my original comment deliberately. First to show that accessing DB2 data directly via SOAP wasn�t that tough and second because in many cases the data these potential RESTful apps need is actually stored in DB2, so bypassing the transaction manager(IMS, CICS) might be more judicious.
Now, I haven�t looked at getting XML out of DB2 via REST yet, but can�t see why it can�t be done given the work I know the DB2 development team have put into storing, handling, processing etc. XML over the past 2-years. Assuming that�s the case, then its back to looking at what gets made available/exposed?
Are we simply talking about making relational data available via REST or exposing transactional applications as services in a SOA environment? It�s my view that the later is more appropriate for SOAP style applications although generalising is always dangerous.
Finally, in the era of Sarbanes/Oxley et al. I simply don�t accept that Intranet requirements for security and data consistency/accuracy are less so than Internet access. Are there really lower security/access requirements for read only data than update? You’ve no problem me reading your credit card data just so long as I can’t update it??
Yes developers are people too, they lead busy lives and are often under extreme pressure to deliver on backlogs, but all that means is that they need the appropriate function and ease of use built into the tools they already use rather than having more requirements and interfaces pushed onto them, no matter how simple.
Maybe I’m part of the problem by always insisting that these issues are considered first…
Comments?