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.

"Attack Pattern", New Game App on BlackBerry App World

New application from DevSpring Software Inc. called Attack Pattern tests your ability to out think computer in terms of pattern creation. You must think ahead several moves in order to beat the computer on highest difficulty with largest game grid size. I could not beat it. You must create your random pattern before the computer creates its pattern. You get to color two squares per turn. You can either block the computer or try to complete your pattern.

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.

Java Virtual Clusters? Extend JEE Spec to Clusters

When will we get a real extension of the JEE specification to include clusters?
A specification to define things like:

• JMS behavior in a clustered environment to include issues like distributed queues and topics as well as message load balancing
• JNDI real-time namespace linking or sharing across a cluster or set of clusters, foreign JNDI providers
  
• UDDI cluster behavior
• RMI load balancing across clusters
  
• WS invocation load balancing across clusters
• Multiple JVM coordination, scaling, JVM lifecycle management
• Datasource management across clusters
• Security and Identity management, authentication across clusters
• Persistence and other state management or caching mechanisms
  

And anything else that causes so much customization to occur in JEE applictaions that write once run anywhere simply breaks down and is lost when it comes to JEE world.