Confidently build and protect beautiful business apps
Unleash the power of a high- performance 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 © 2015. Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved.