|
|
article page | 1 | 2 | 3 | 4 | 5 |
the “bragging rights” are often strident. But SOA using advanced RMI and .NET techniques while powerful, has a significant drawback. These technologies require both expert Architects and master Developers. A proper SOA must be designed from the ground up with a strong understanding of both the functional activities of the problem and the component decomposition efficiencies. Perhaps the biggest hurdle, as was shown in the work of the TMF NGOSS red team, it also requires a consistent and shared data model (and a good understanding of the business). So a pure SOA is the best approach when you are building greenfield or undertaking a problem with specific known boundaries and scope.
Otherwise, the next best thing is …
Web Services
In the mid-nineties, message bus technology appeared as an implementation of the
|
|
practically the choosing of a message bus vendor was a long term lock in to a single source infrastructure. Over time, and through many vendor mergers, this industry reinvented itself as Enterprise Service Bus (ESB). This did mean that tool products worked together and the bus infrastructure could be managed. However, lock-in and expense are still big problems. Yet today, ESB is the dominant paradigm for business integration.
But as frustration with bus technology increased, another technology was coming out of the W3C and the IETF. Web services extended the migration of internet-based technology into IT. Adopted early on by both IBM and Microsoft, web services had strong research and standardization budgets. It is easy to see that IBM and Microsoft quickly promoted web services over traditional SOA because web services (like the promised but unrealized wish in buss technology) promised
|
|
|
|
|
publication/subscription approaches being pioneered in the IETF. At that time service providers were beginning to feel the poison of stove-pipe approaches to products and accompanying OSS. Also, using System Integrators to build custom interfaces was getting outrageously expensive. Architects and managers understood that applications needed to be linked-up and coordinated both vertically and horizontally. As early implementers and strong proponents of the massive benefits to be reaped from solving these issues, we both attacked the problem: Wedge creating the first NGOSS architectures that were based around message buss technology coupled with workflow managers, and Barbara using multi-threaded applications and clustered data stores. Both approaches did work. However, neither worked as well as expected. Integration still involved costly matches of applications. The message buss products were fraught with troubles and were so over sold that support was difficult to come by. While pub/sub was standards based, the implementations were quite different and
|
|
a simple external interface that could wrapper existing products and “integrate” them to the whole world. It would not be necessary to re-engineer big applications since web services could provide a gateway from the application to all the other web service enabled applications. And better than SOA, since a universal data model was not required. In practice, web services had a rocky early implementation history. Web services had no managed or guaranteed delivery of messages between applications; and to get it managed, you had to select one single vendor. But the size and importance of the problem meant that the community needed to solve these problems and most early issues are now things of the past.
Perhaps one of the greatest strategies adopted by the web service community was their open-mindedness, and ability to move past the “Not Invented Here syndrome”. They became great borrowers from other promising technologies. They adopted the management architectures originally
|
article page | 1 | 2 | 3 | 4 | 5 |
|
|
|
