Skip to main content

old object models to new object models....

I've spent the last couple of days researching the hot trend in software service enablement that is made possible by the idea of web services. I remember back in 2000, when I was still working as a network and pc support technician reading a book on the emerging tool of xml. At this time, the growing needs of web sites to store and provide content thanks to the exploding number of individuals coming online to buy, trade and interact necessitated a way to stream line content creation, transformation and delivery to different locations in different formats. Xml was the magic bullet that was able to provide all these things when used cleverly. I soon found myself during my free time at work, reading the chapters on how xml worked and how to perform xsl transformations. I became convinced that xml related technologies were the future and with that conviction in mind began a secret hunt for a job while I was still working at the bank. I was able to get a job with in a matter of weeks and was sufficiently enthusiastic and competent to get the job. While at I got to experience first hand the revolution of xml and the power of it as weilded over the problem of controlling web content. In the system I worked on, nostalgically called "rosebud" by the designers, xml were the rails upon which the content of the site rolled. Several simple relationships between xml content blocks and pages to be rendered in the StoryServer development environment, alone with a distribution method to multiple outbound locations, file or ftp allowed the site to publish content in house and then distribute it in various forms to outside partners (for a fee) as well as to the main web sites of the company. The experience of building many of the xml feeds that brought revenue to the company convinced me further that xml was the future. I imagined a system that could be used as an xml nexus, taking in content in the form of xml , transforming it for the needs of the system and then transforming it again to desired output formats for delivery to external partners. Though we did do this to an extent at it was not the jist of the companies business, which was to provide financial news and commentary, the content distribution was only a side effect of the businesses goals. I saw xml as more than just something useful for financial news content management, I saw it as something that could potentially manage any outbound or inbound data interaction between disparate systems. As I continued to work at TSC, the proposals to use xml as a lingua franca of data transmission between different platforms was born. Wrapped into the moniker of "web services", these xml grammars would allow systems to speak a common language that could be used by remote systems to authenticate, request method or object acces to various entities on remote systems and recieve the requested data in synchronous or asynchronous fashion. Since then web services as flowered with various protocols for ensuring certain tasks are performed in efficient and safe ways for their use in the enterprise. Security being chief among them as covered by the ws-security protocol.

Today, web services form the backbone of another raging buzz word in Information technology in the last few years, SOA. Web services are what make SOA's possible by providing the underlying fluid interface for mediating data and object requests between applications internally and between enterprises externally. Unfortunately, with all this new use of xml to do things that it was not originally designed to do comes one major issue, complexity. The web services protocols are not very intuitive but once it is realized that all they do is allow remote applications to talk to one another, then old dinosaurs who are familiar with older acronyms like CORBA, DCOM or COM will know just now to deal with the new parts once they are mapped to their object model equivalents. The key difference between web services and the previous object models however is how agnostic they are of the platforms that they run on. The industry has actually succeeded in providing a deep level of platform neutrality that has enabled enterprises to enable a new level of efficiency as far as remote data mediation is concerned. There are still many issues to work out in the areas of security, and still many things that are done inefficiently by the inherent nature of the use of an xml grammar to do them (like sending files) but these are finding solutions. The complexity of these new solutions must be absorbed and abstracted just as was done for the old component object models, through late nights and lots of coffee but the promise of infinitely interoperable systems free from lockin is actually palpable. Is this current round of an object model technology going to be the last one? Or in a few years, will web services be deemed old news and replaced by another new fangled technology that does the same old job in a new way? Only time will tell...


Popular posts from this blog

Highly targeted Cpg vaccine immunotherapy for a range of cancer


This will surely go down as a seminal advance in cancer therapy. It reads like magic:

So this new approach looks for the specific proteins that are associated with a given tumors resistance to attack by the body's T cells, it then adjusts those T cells to be hyper sensitive to the specific oncogenic proteins targeted. These cells become essentially The Terminator​ T cells in the specific tumor AND have the multiplied effect of traveling along the immune pathway of spreading that the cancer many have metastasized. This is huge squared because it means you can essentially use targeting one tumor to identify and eliminate distal tumors that you many not even realize exist.

This allows the therapy for treating cancer to, for the first time; end the "wack a mole" problem that has frustrated traditional shot gun methods of treatment involving radiation and chemotherapy ...which by their nature unfortunately damage parts of the body that are not cancer laden but …

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…

AgilEntity Architecture: Action Oriented Workflow

Permissions, fine grained versus management headache
The usual method for determining which users can perform a given function on a given object in a managed system, employs providing those Users with specific access rights via the use of permissions. Often these permissions are also able to be granted to collections called Groups, to which Users are added. The combination of Permissions and Groups provides the ability to provide as atomic a dissemination of rights across the User space as possible. However, this granularity comes at the price of reduced efficiency for managing the created permissions and more importantly the Groups that collect Users designated to perform sets of actions. Essentially the Groups serve as access control lists in many systems, which for the variable and often changing environment of business applications means a need to constantly update the ACL’s (groups) in order to add or remove individuals based on their ability to perform certain actions. Also, the…