Friday, April 02, 2010

Beyond SOA and EAI, Reflective Apps

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.

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.

Thursday, November 19, 2009

"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.