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
As an ESB practitioner for the past 4-5 years I am often asked what is the best way to make a SOA project successful, my response 'An initial win, followed up by small successful iterations,' the main thing that people are taken back about in this statement is the lack of technology and standards in the response. Yes, technology and the supported standards will help dramatically with achieving this, but it is an aid to the vision of the business, architect, or other that is pursuing the SOA vision - without that vision the project will not be successful regardless of technology.
The initial win might in fact be the easiest part of this statement, as in many projects this might be a Proof of Concept or initial pilot that is built with little regard for the challenges that are about to hit the project. However, with a bit of planning and some guidelines for the development and layering of SOA applications, it is possible to achieve the statement 'followed up by small successful iterations.' To achieve successful iterations each subsequent iteration in the project should build directly on services built in the previous revisions.
To prove reuse and agility I recently created a simple demo for a distributed query across four databases, this was created in top down approach allowing the quick win to be achieved in which the sample end user portal could simulate requests within minutes of starting the project and before the databases were even defined. Then the data aggregation and connection level services were created in about another 2 hours, allowing essentially 3 phases in 21/2 hours. And now the unexpected benefits; for the next use case which was Remote Information Data, or given a document entering the ESB route it to the appropriate back-end datasources. This was done in about an hour as I not only reused some of the service instances, but the associated artifacts such as Integration Workbench projects etc.
For both use-cases I used 3 service types, 5 projects and 21 ESB Processes and not a single line of code (Java or .NET) and have the ability to reuse most of these as my demo is extended.
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.