Mahesh Kolari
Unregistered
|
|
** Key is: ** Designing the application covering all functional and no-functional requirements considering extensibility, supportability and maintainability and not to over complicate the application development. Reusability and loose coupling are also very important to the target organization on a longer term and it saves time and money for future developments. Modules can be SOA enabled at a later point in time when there is requirement/time/money to do so.
** Simples SOA: ** An application module exposed to external systems via HTTP/HTTPS protocol with a well defined XML schema for IN/OUT parameters will be a classic example of a simplest form of SOA enabled interaction. This will support loose-coupling/Robustness/Interoperability/Reusability/Security requirements at appropriate levels.
Stateful interactions could be implemented within SOA enabled applications by programming to remember the state of each transaction. As the author correctly states, Webservice is not the only way of implementing SOA. Probably SOA should not encourage Stateful implementation since it reduces the modularity and reusability of the services.
** Does the promise of SOA in delivering software reuse live up to reality? **
Yes - It is not only a question of if we can ever reuse all of very old code implementations that are written badly. It's also about how well we can implement the newer application applications to make them more reusable. SOA enables us to reuse 10%-25% of the legacy interfaces. With refactoring it should be possible to SOA enable another 20% of those interfaces. There are lot of projects going on where SOA is used for migrating from Client-server architecture to a Thin-client (Web based) architecture. Underlying business object implementations (C/C++, Java, COBOL etc.) are reused by building a bridge using Tuxedo/Jolt, Messaging frameworks/products or Webservice.
Mahesh Kolari
Tech Architect
mkolari@gmail.com
|
hsheil
Unregistered
|
|
Hi
the reason that I moved to JMS as my default simplest implementation is that I have implemented messaging layers on top of HTTP in the past and have always found that I try to implement JMS-like (or I guess WS-*) semantics on top of the HTTP layer. So I figured I would cut out the middle-man this time and move straight to JMS. For most JEE applications I feel that this choice is more suitable.
>>Probably SOA should not encourage Stateful implementation since it reduces the modularity and reusability of the services.
If SOA does not support stateful conversations or at the very least stateful semantics, then it simply won't last very long as a programming model. Imagine where the JEE specifiction would be without HttpSession?
>>Yes - It is not only a question of if we can ever reuse all of very old code implementations that are written badly <snip/>
The percentages you quote must vary from project to project - if application X was written 15 years ago with no thought given to modularity or reusability, then simply put, 10 - 25% of the codebase will not be reusable.. I see the point you are trying to make, but I do not agree with it.
Regards
Humphrey
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
