Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate decision processes with a no-code business rules engine
Build mobile apps for iOS, Android and Windows Phone
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
I have been reading a few articles on the internet and in various documents that tend to come to the conclusion that web-services and BPEL are the answer to all problems, in much the way that CORBA, RMI, J2EE (insert technology of choice) were touted in previous years. I would suggest to the contrary that there is a swing away from this viewpoint. Twelve months back web-services were the key thing, I cannot tell you how many people I spoke to said that they had made every object a web-service, followed by a knowing smile that all was right with the world. Now I am starting to hear that those same people are adopting a different approach to SOA infrastructure because the overhead of web-services is too high. Again similar statements were heard after the initial implementations of CORBA and other remoting technologies as people went from theoretical to practical.
Why is the overhead too high? Because every invocation is across the network, XML tends to be heavier than its compiled cousins, such as J2EE. Now apply that cost to every fine grained operation, such as transformation and the overhead of the web-services invoked will soon be higher than the business process that is being implemented. There is also a dollar cost to web-services that many people tend to ignore, such as that associated with hardware load balancers, XML firewalls etc. Now all the web-services that a developer created using their favorite build tool, suddenly do not appear so cheap by the time I get it into production and buy expensive hardware for maintenance.
The key with SOA as with any technology is to ensure it is composed in the correct manner, and a good architect will always strive to do just that. Architects understand the various tradeoffs with each technology and make them fit together for a complete solution. That said, no one technology will solve all the problems, and as such we should remember that SOA is really a way to achieve agility in the enterprise and that comes with some sort of cost. Let's face facts, if we wanted performance over agility we would all be writing in assembly language.
Good software engineers/architects will always be that as long as they apply the reasons that they were good in the first place: keeping an open but skeptical mind. Use SOA for what it is best for; orchestrating various technologies at various levels within the enterprise and more importantly, starting to break down the corporate / technology boundaries to better serve the business. A good solution will consist of more than BPEL and web-services to get the right blend of agility, federation and performance.
View all posts from David Millman on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.