We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
SOA
user-pic

Are Web Services Protocols Such as SOAP and REST and AJAX Effective for Building SOA Off of Mainframe, Large Systems or Legacy Environments?

Vote 0 Votes
From Joe McKendrick: Are Web services protocols such as SOAP and REST and AJAX effective for building SOA off of mainframe, large systems or legacy environments?  Or is message-oriented middleware more advisable?

8 Replies

| Add a Reply
  • In terms of SOAP and REST, absolutely (I see AJAX as more a front end technology that will use SOAP and REST based services). Why go through multiple MOM layers to get at data on these systems when you can use SOAP over REST and HTTP to get at the data. We use both protocols to get data from DB2 into Excel for example. We have found that organizations spend a lot of resources building applications to take data from their mainframe databases such as DB2, ADABAS or VSAM, which are then written to a file, downloaded to a PC and then uploaded into Excel at which point the data is out of date. Using REST to access this data allows a report in Excel to be built for example and then refreshed to get the most up to date data.

    Large systems also hold hundreds or thousands of business functions that are critical to the functioning of a large organization. What better way to reuse these functions than to use SOAP (or REST) to make these functions callable from Java, .NET or whatever other framework is being used on the front end.

    Using a message-oriented middleware simply introduces complexity where it is not needed. If you have an online transaction that needs to complete, you need a request/response protocol. MOM based implementations are useful if you don't need an immediate response but even then, we can use SOAP and REST over MOM based implementations (such as EntireX and MQ Series) which can store up the requests when the back end database or system is not available. When it becomes available, the REST and SOAP requests may then be processed.

    Very much a case of horses for courses....use the right tool for the job. We are now in the 21st century and we should be using 21st century tools and standards to get the job done.

    Best regards,

    John

  • Ask the application what it wants to be, and you will have your answer.

    The truth is you need to choose architectural style and infrastructure to meet the requirements of the problem. I’m a huge advocate of Message-Oriented Middleware (I even co-authored a book on JMS, now in remainder bins everywhere), but you should only use it when you want to leverage the key characteristics that make it unique: things like queuing (with prioritization, message tracking, etc), publish subscribe models, guaranteed one-time delivery, asynchronous delivery models, message correlation, abstraction of network infrastructure, etc. At the message-level, you can certainly run SOAP messages over this infrastructure—I have many customers who do. I suppose you could even do a REST-like model over this using MOM headers, but you wouldn’t really be leveraging the architecture of the Web which is really the underlying idea behind REST. The point is however that MOM offers some very robust and proven features, decoupled from message formats, that make sense if that’s what your need to solve your business problem.

    In contrast, SOAP over HTTP forces you to pull in a lot of WS-* protocols to approach the same characteristics. This places a lot of functionality burden on clients and servers and ultimately may not give you the same robustness or potential for interop because it’s simply had less time to mature. Nevertheless, the tooling and infrastructure is constantly evolving so there may come a time when there is complete functional parity between SOAP/HTTP and MOM. But that isn't now.

    The brilliance of REST (and AJAX for that matter) lies in it’s ease of use, simplicity, and leveraging of existing Web infrastructure. It’s the right choice if you can work with a request/response synchronous model, you don't need complex data types sent in both directions, hardcore reliability is not a requirement, a queuing model is unnecessary, etc. It sounds like a lot of restrictions, but in reality this suffices for an awful lot of apps. You just need to determine if this is the case for yours.

    • I would very much agree with you in terms of MOM based infrastructures when this is what is required. I would never attempt to use the WS-* protocols to emulate what JMS or other MOM based infrastructures can do. They do this very well and if these are the characteristics you want, you should use a MOM based infrastructure.

      In most cases, these large 'legacy servers' are transaction based so when a request is issued, you need an immediate response or the service is down. For this direct request/response mechanism, SOAP over HTTP is ideal as it is relatively lite (you don't need lots of WS-*) and in fact once a service is published from the mainframe using a WSDL, the tools on your client system understand this 'out of the box' and can thus use these services with no knowledge of what is servicing the request. Another advantage is that there is no installation required on your client systems. This is a huge advantage in today's world where thousands of of client PCs have been deployed. To the best of my knowledge, all of the MOM based inforastructures require a foot print on the client systems. At the same time, I would agree that this is very worthwhile if a MOM based interface is what the application requires.

  • This is a core strength of Software AG and we have hundreds of examples of customers using Mainframe systems in this manner with AJAX, REST and very modernized environments.

    What may be more significant is to modernize not just the user interfaces but to expose the mainframe capabilities as SOA services.

  • I would take this a bit further into the Enterprise Mashup and Situational Applications domain, where SOAP and REST are excellent ingredients for implementing attractive and cost effective situational applications that leverage the robustness and business logic of Mainframe applications. I consider MOM’s as significantly more heavy duty tools that would be useful in non-interactive applications with a good business case, typically for Core Applications. Mashup platforms such as Convertigo can easily expose Mainframe resources as web services using programmatic integration (good old screen scraping with added reliability) and compose them into Mashup applications of the “WebX.0? style, offering a very compelling ROI in line with the present business imperatives.

  • REST is not a Web Service protocol, it's an architectural approach that is represented in it's most popular form by HTTP. The REST approach also implies that you are identifying resources though a URI. However, I believe the tone of the question does imply a comparison of traditional MOM versus Web-Oriented messaging. And, frankly, the answer is ... it doesn't really matter. WS-* can be bound to either, so it's an orthogonal issue. With regard to HTTP for data transfer to/from the mainframe, it's no more or less reliable then communicating with a Windows 2003 server. Finally, today's mainframes are really nothing more than big virtualization environments running multiple OS and offer a multitude of ways to get to the legacy VSAM data locked up there. One note, I did find it easier with AS/400 to use ODBC to move data across DB/400.

  • Short Answer: they have to be or they are unfit for their intended purpose.

    All kinds of legacy-interaction protocols exist, but most tried to fashion legacy transactions into some other technology. Best example is JDBC drivers and JCA. While they are better than point-to-point proprietary interfaces, they are not designed for rich service architectures. SOAP & WSDL are well-suited. REST, less so due to the lack of declarative typing. But still more language and technology neutral than other approaches I've seen.

  • Good question - as it is of course so open to interpretation and many different answers. So many customers of course have their long standing and new core applications running on mainframe systems - plus systems put into production yesterday can be seen as legacy.
    To me the question is how should business leverage those assets in the most effective way. I don't think I would advise a business to blindly follow any technical solution simply to be architecturally pure. We have many examples of customers using WebSphere solutions - such as WebSphere MQ or one of our ESBs to connect to and reuse mainframe and other assets.
    But equally those same assets can be quickly and easily modernized with tooling from our Rational portfolio.
    Our customers find any combination of these solutions can be the right one depending on their business needs, skills profile and time pressure. Flexibility shouldn't just be the business goal - should be the IT goal as well.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT