Build, protect and deploy apps across any platform and mobile device
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile 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
Last week Jeremy Suratt made an interesting point on the Infor Tech Talk blog. He says that event-driven architecture (EDA) is different from traditional service-oriented architecture (SOA) in the manner in which applications are related - or not related. In particular he says "key to event-driven SOA is the ability for decoupled, asynchronous operations." I agree wholeheartedly with Jeremy and think this point is one of the least well understood aspects of modern enterprise architectures and the complexity inherent in large integration projects.
There is a great book on this topic entitled "Software Fortresses" by Roger Sessions. Though the book doesn't mention the term SOA (it largely predates SOA and the current hype), it does point to the fundamental need for decoupling of systems through asynchronous messaging. In the book, one of the golden rules is "never let transactions cross software fortresses." I may be misquoting this a bit ... but the essential point is that between application domains, which are referred to as fortresses, you should allow for no dependencies which might block a transaction's completion. This rule flies in the face of what most SOA infrastructure advocates today suggest is the very purpose of this new architecture. Aren't we to just make a Web Service call when we want to leverage components in other systems? Roger says - just because you can doesn't mean you should. Once you grok these simple architectural best practices and the power it brings through "isolation", you're fast on the road to understanding the difference between traditional SOA and event-driven SOA. The latter abides by the golden rule by inverting the control of intra fortress communications - using an event publishing rather than a service invocation model. The former decouples the applications and the latter couples them - albeit loosely through Web services.
Perhaps this is a long winded "dah" moment for you, but for many organizations it's still something they wrestle with daily. Progress chose this decoupled model for the design of our integration backbone, Sonic ESB. As a result, applications integrated with Sonic ESB are naturally decoupled. This means you can shut down any application without impact to the overall operation of the other applications. Unlike systems that link through traditional SOA request/reply invocation... Sonic ensures that messages get through when the application comes back online. Now this is very different from other ESBs on the market or available through open source today. These ESBs employ a "traditional SOA" architecture - meaning that applications connected through them are coupled via service-proxy rather being decoupled through asynchronous message forwarding. I don't want to belabor the point, but a loose coupling of Web services is an insufficient architecture for large integration projects. If you're not familiar with this type of ESB, I encourage you to download our latest Sonic ESB 7.6 version and go through the tutorial on "batch to real-time" processing - which shows the power of event-driven integration in the form of a continuous pipeline processing example.
View all posts from Jon Bachman 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.