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
Build mobile apps for iOS, Android and Windows Phone
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Automate decision processes with a no-code business rules engine
There's lots of industry noise about Service-oriented architecture (SOA) and the expected benefits, but in many cases SOA is an implementation of procedural programming that may be implemented in Object Oriented (OO) technologies such as Java or .NET. That said, I cannot really see anything OO in a basic BPEL or Web Service implementation; have we all forgotten that OO was promising the benefits of reuse, etc., as well? What if we could improve our SOAs by implementing the OO paradigm in them and using techniques such as polymorphism?
What would a polymorphic service be in SOA? And more importantly, what would be the advantages? One of the most common tasks that occurs in any SOA project is the ability to transform data, e.g. convert a document from one format to another, for which many technologies are currently used, such as XSLT and java binding technologies like Castor and XML Beans (to name a few). While each of these technologies provide the ability to transform one document to another, they do not provide the ability to dynamically implement transforms without further hand coding.
Now what is a polymorphic transformation going to actually implement? Well, unlike an object model, I have no base implementation that I can derive from and no guarantee that my transforms are going to execute in a single environment. And what I don't want to do is deploy a specific XSLT wherever a transformation is required because if the format or the data in the input document changes for some unforeseen reason, then the XSLT is essentially invalid. Therefore, the service that I want to deploy will take in any document and transform it into the target type without having to understand how it is implemented, and if for some reason the transformation service cannot convert the inbound target, then an exception is thrown.
Now I am sure that some of you may see this as being a good idea, but what are the benefits of this? If one of the significant costs of a SOA is the time and money of transformation, being able to insert a single polymorphic transformation service in multiple places could severely reduce TCO of any implementation and reduce the number of errors; how many developers do you have working on essentially the same transformation? For a more tangible example, in the world of Software-as-a-Service (SaaS), what if adding a new partner was no harder than ensuring the partner’s request document can be managed by the OO transformation service. Suddenly the ability to get a return on investment on smaller traffic customers who are making money on fractions of a penny per transaction allows a new market to be tapped.
Is this possible today? Absolutely. Products such as SI provide this polymorphic transform services, especially when coupled with ESBs that do not have to be strongly typed.
SOA What? Developers can spend more time developing business logic and less time writing complex transformations, which I am sure they like. But also your SOA infrastructure becomes more agile, allowing you to react to customer and market demands. And if your looking into SaaS to provide the ability to make money on smaller customers, imagine the benefits if all the points of mediation were polymorphic?
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 or appropriate markings.