Imagine extending the type of reflection built into Java objects to whole applications. Just as Java objects can be interrogated to determine fields, methods, interfaces, inheritance, so to can applications be developed that provide similar information. All that is required is a common means of expressing such information.
Obviously XML would be a prime candidate as a language to express reflective application metadata. WSDL does enable something like reflection but it is targeted at web services.
Before universally reflective applications can talk there must exist a universal means of communicating between applications no matter what technologies are use to implement those apps. CORBA attempts to bridge application to application communication but has had many issues. JEE attempts to make this same bridge by using containers. HTTP enables web servers to communicate with each other and with browsers. Everyone has agreed to follow the HTTP standard. What is needed is something equivalent to HTTP for applications in general, not just web servers, to communicate.
Will that standard simply be implemented on top of tcp/ip stack? Could everyone agree on a standard XML schema, on the exchange protocol, common ports, etc.
Friday, April 02, 2010
Sunday, December 13, 2009
When did code become a dirty word? SOA merely moves the logic
SOA has been heralded as a panacea. Why, so we can avoid changing code or the need to write code?
In SOAs, using the service interface pattern to achieve loose coupling merely moves the logic for determining which implementation of a service or component of code is used during any given invocation of such interfaces from code to system configurations, contracts, protocol definitions, UDDI registries, standards definitions, metadata dictionaries, etc, etc. not to mention compliance and monitoring because at some point in a system, logic must be exercised to determine the routing of method calls to concrete implementations. SOA is supposed to make it so that implementations can be changed by manipulating these SOA elements without changing code.
If code became a dirty word because it was decided that changing code is too expensive and/or time consuming then why would you replace it with something that is even more complex, expensive and time consuming such as aforementioned SOA elements?
Also, the last time I checked the specialties needed as far as personnel in SOA systems like SO Architects, system architects, etc. and those needed to maintain monitoring and compliance are much more expensive than software engineers.
If all of the time and money that has been spent on SOA were to have been spent on concrete components and systems such as AspectJ that allow instrumentation at the code level and other capabilities that serve as glue or connectors at the code level or technologies that allow easy linking of applications across computer language boundaries, then software and systems engineering would be in a far better state.
Even though the links in a system really do define it, as is often the case, they are either completely ignored or not even recognized as entities in and of themselves. Links are instead seen as constraints or guides but not as essential parts themselves. In steel fabrication the links in the system are the welds. They are treated as special entities that require special attention to the point of using x-rays when the welds must be without defect to some high tolerance. In the area of search, Google has recognized the significance of links as a part of their page ranking system and treated them with special attention. It is time for software and system engineering to stop "defining" the links between applications and start building the links as efficient hard technologies not abstract protocols and frameworks. These technologies are of necessity built anyway but it is done in such a way as to create a concrete representation of protocols or frameworks instead of with an eye toward efficiency and optimization to the task at hand. Or else they are created as part of a vendor's application or SOA stack that is only optimized in the context of the rest of said vendor's stack. In the end, if you want to change the behavior of a system you must change something in the system or in its environment. When changing the environment becomes more complex and expensive than just changing the system, then just change the system, just change the code.
In SOAs, using the service interface pattern to achieve loose coupling merely moves the logic for determining which implementation of a service or component of code is used during any given invocation of such interfaces from code to system configurations, contracts, protocol definitions, UDDI registries, standards definitions, metadata dictionaries, etc, etc. not to mention compliance and monitoring because at some point in a system, logic must be exercised to determine the routing of method calls to concrete implementations. SOA is supposed to make it so that implementations can be changed by manipulating these SOA elements without changing code.
If code became a dirty word because it was decided that changing code is too expensive and/or time consuming then why would you replace it with something that is even more complex, expensive and time consuming such as aforementioned SOA elements?
Also, the last time I checked the specialties needed as far as personnel in SOA systems like SO Architects, system architects, etc. and those needed to maintain monitoring and compliance are much more expensive than software engineers.
If all of the time and money that has been spent on SOA were to have been spent on concrete components and systems such as AspectJ that allow instrumentation at the code level and other capabilities that serve as glue or connectors at the code level or technologies that allow easy linking of applications across computer language boundaries, then software and systems engineering would be in a far better state.
Even though the links in a system really do define it, as is often the case, they are either completely ignored or not even recognized as entities in and of themselves. Links are instead seen as constraints or guides but not as essential parts themselves. In steel fabrication the links in the system are the welds. They are treated as special entities that require special attention to the point of using x-rays when the welds must be without defect to some high tolerance. In the area of search, Google has recognized the significance of links as a part of their page ranking system and treated them with special attention. It is time for software and system engineering to stop "defining" the links between applications and start building the links as efficient hard technologies not abstract protocols and frameworks. These technologies are of necessity built anyway but it is done in such a way as to create a concrete representation of protocols or frameworks instead of with an eye toward efficiency and optimization to the task at hand. Or else they are created as part of a vendor's application or SOA stack that is only optimized in the context of the rest of said vendor's stack. In the end, if you want to change the behavior of a system you must change something in the system or in its environment. When changing the environment becomes more complex and expensive than just changing the system, then just change the system, just change the code.
Tuesday, June 23, 2009
On Software Engineering: coupling and cohesion, meaningless academic abstractions
In computer science and software engineering, the concepts of coupling and cohesion are meaningless academic abstractions that only serve to increase the cost of software engineering and decrease both performance and simplicity. In these times of rapid churn in terms of technologies and tools used to implement large software systems, the goals of maintainability and readability touted by proponents of so called loose coupling and high cohesion should come far behind goals involving performance and time to develop, when any given implementation may be outdated before it is even fully completed.
Furthermore, coupling as a concept taken outside of its goals does not stand to simple facts related to the nature of communications between two software modules. At the very least, in order for two modules to work together, they must share a common language, an agreed upon format for the data that they communicate to each other. They are at a minimum coupled to a common format or interface. It does not really matter what means are used to define that shared interface in measuring the degree to which the two modules are coupled. If that interface is changed then one or both modules using the interface will have to change. If the content or meaning of the data is changed and neither side needs to change then that part of the interface that changed must be superfluous whether the interface is defined in XML or a binary format or in terms of some programming language’s object, it does not matter.
Further still, cohesion as a concept does not deliver in terms of performance or any other meaningful measure of software engineering quality related to real world issues and not academic contrivances of what is pure and well formed. The more cohesion that modules exhibit in a system, the more communications will be required to connect those modularized chunks together so that the system can accomplish its requirements. For example, it may seems like well structured design to have all points in a system access some resource through a common module that implements such actions in one location but this requires two extra communication hops for every access executed against said resource, one to the common module then one from that common module to the resource, then two more coming back out to the calling module. Why not let every module that needs to access the resource do so in its own code inline maybe through some shared abstract interface since maintainability is almost a moot point in the face of modern IDEs that offer all sorts of refactoring utilities.
Going to extremes just to achieve high cohesion and loose coupling is a waste of time and resources and often results in reduced performance and increased complexity.
Furthermore, coupling as a concept taken outside of its goals does not stand to simple facts related to the nature of communications between two software modules. At the very least, in order for two modules to work together, they must share a common language, an agreed upon format for the data that they communicate to each other. They are at a minimum coupled to a common format or interface. It does not really matter what means are used to define that shared interface in measuring the degree to which the two modules are coupled. If that interface is changed then one or both modules using the interface will have to change. If the content or meaning of the data is changed and neither side needs to change then that part of the interface that changed must be superfluous whether the interface is defined in XML or a binary format or in terms of some programming language’s object, it does not matter.
Further still, cohesion as a concept does not deliver in terms of performance or any other meaningful measure of software engineering quality related to real world issues and not academic contrivances of what is pure and well formed. The more cohesion that modules exhibit in a system, the more communications will be required to connect those modularized chunks together so that the system can accomplish its requirements. For example, it may seems like well structured design to have all points in a system access some resource through a common module that implements such actions in one location but this requires two extra communication hops for every access executed against said resource, one to the common module then one from that common module to the resource, then two more coming back out to the calling module. Why not let every module that needs to access the resource do so in its own code inline maybe through some shared abstract interface since maintainability is almost a moot point in the face of modern IDEs that offer all sorts of refactoring utilities.
Going to extremes just to achieve high cohesion and loose coupling is a waste of time and resources and often results in reduced performance and increased complexity.
Subscribe to:
Posts (Atom)