IIOP and CORBA
Came across this interesting article on the IIOP specification: http://www.blackmagic.com/people/gabe/iiop.html
Ok- Interface Definition Language is a means to exposing functionality written in languages like C, Java, Smalltalk etc. in a language-independent way. The method level details are written in IDL, which can be accessed using Object Request Brokers.
However, different kinds of ORBs could not talk with one another- so there was a need for standardization there. the GIOP, or General Inter-ORB Protocol, was developed for this by the Object Management Group. GIOP maps different ORB calls with network transport mechanisms, such as HTTP, SMTP, etc, and is basically a collection of requests that an ORB can make on a network. IIOP is a derived form of GIOP, and it allows translation of ORB calls with HTTP. The Environment Specific Inter-ORB Protocol, or ESIOP, allows translaion of GIOP messages into a proprietary system like the OSF's DCE.
IIOP allows faster communication by allowing transmission of binary objects, such as arrays, over the network. The problem with IIOP and standards whcih support it, like CORBA, COM, RMI etc., is that it is not standardized. While SOAP is. Also, SOAP can pass through firewalls, while CORBA requires ports which are typically blocked by firewalls.
Java on the Desktop
While trying to find out how much they pay to write on java developer's network (guess what? They don't!!), I came across this article- Java on the Desktop: Javaland Seems Divided * FEEDBACK Special *- summarizing the response to Alan Williamson's original piece ("Does Sun's Desktop System 'Hijack' the Java Brand?").
Well- these are some thoughts raised, and my views.
1. Sun is coming out with a desktop. That in itself is something- because Sun is typically not considered a user-experience oriented company, and user experience is a very important factor in desktop applications. Easy of use and simplicity are two of the top reasons for the success of Microsoft products in almost all consumer-categories. Also, since most of the applications that will actually constitute the desktop are already present, Sun is essentially doing a bring-it-all-together job. The key to such an exercise is identifying how successfully the existing functionality can be bundled and packaged to the end user. In the end, even if all Sun does is package an installable out of existing components and products, and does it well, it can pull this off. "Pull it off" means it will get an entry into some of the desktop boxes, in at least the developer community where people spend more time in front of geeky code than playing mp3s or buying grocery from amazon.com. The latter category of "casual users" will not take up the Java Desktop any time in near future. But this entry chance gives Sun an excellent chance to prove that they can make usable things. I just hope they don't give a right click menu option which says "debug this library and rebuild the OS".
2. Sun is using the java name. Someone shouted that they are better off keeping the java name "neutral", allowing other parties a stake in it as well. The theory is that this works better- like it has for the Linux brand, which is evangelized extensively by all major product vendors (except MS, of course). Calling Java their own has an exclusivity effect, and other players are less likely to take up the Java cause with the same fervor. My take? Well, this is true to a certain extent- Java is not just a name. It is a brand in the tech circles.
It is associated with a sense of freedom of engineering what you feel like, and doing it using a platform not owned by anyone. This is the underlying psychology behind the popularity of the open source movement- the feeling that you are using something initially built by techies, currently supported by techies, and collectively owned by cool and forward thinking people like you who like making new things. As against business people who are into it for money. The java brand is also associated with a sense of power and control over what you are doing, and this is intimately tied in with a feeling of trust. All of us feel a sense of ownership for this Java brand. This ownership is the reason why community-based open-source software development happens on this platform.
Calling their product the Java Desktop System has the effect of taking this sacrosanct brand and putting it on the anvil. If the product succeeds, fine-it'll be a boost to Sun's image, as mentioned above. But if it doesn't, or has only limited acceptance which fizzles out with time, then Java as a brand will suffer.
3. Sun has renamed this project for the umpteenth time. Yes, that is detrimental to the project's success. I think one reason for this is that Sun never took up the Desktop initiative as a product development exercise. It was never planned, never managed like one. It was more of a by-product exercise, and hence the haphazardous route to release. It is almost open source within Sun- people who like the idea take it up, rather than it being a strategic initiative.
Struts and Cocoon
Very very interesting to find out exactly what are Struts and Cocoon- and the difference between the two.
First, Struts. It is a framework developed under the Apache Jakarta Project, and it facilitates the development of web applications. And it does so by implementing the Model View Controller design pattern for such systems. The MVC pattern tells us how to separate the presentation (view), presentation control (controller) and logic components (model) of an application. This concept was encapsulated for web applications in the Model 2 approach- a conceptual framework which encourages complete segregation of the three functions outlined above. So, for example, Struts allows us to implement the View or presentation component using JSPs, the controller component using Servlets, and the Model or logic component using EJBs. It provides a number of classes for integrating these components, as well as configuration mechanisms using XML files. These classes include ActionForms for taking inputs, ActionMappings for passing the inputs to the right Action servlets, and ActionForward classes for choosing the right output component. See http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html for a couple of good diagrams on this.
Cocoon. Cocoon is also a product of the Apache software Foundation, and the project homepage describes it as "web glue for your web application development needs" (http://cocoon.apache.org/). It uses the concept of component pipelines for achieving separation of concerns. Now that's not very useful. Here's what it basically means in English, and we would have to into some depth to appreciate the need for a framework like Cocoon.
HTML allows you to draw things on the webpage. And there are tools to work with HTML. So what you see is what you get. But what you see is all you get (from http://cocoon.apache.org/2.1/introduction.html - an excellent introduction to Cocoon). XML, o nthe other hand, allows you to embedd meaning into the data, through its set of standardized tags. Cocoon 1.0 did just this- it used a set of transformation rules to convert XML to HMTL. As an extension of this transformational system, we can form contracts (component pipelines) between different logical components of the system. So a contract would say that indicates that the value of name is to be displayed here. Where and how is taken care of by the Style component. In the end, Cocoon allows us to present our date in a neat, methodical and systematic manner. It uses Generators, Transformers and Serializers to process the data through the pipeline.
Struts and Cocoon. Well, on the face of it- both seem to be similar things. Both are frameworks. Both separate the logic from the presentation in their own manner. While Struts starts from the MVC design pattern, Cocoon starts from the idea of separation of concerns. While Struts is a all-tier framework which spans from the presentation layer (JSPs) to the Servlets to the deployment of Beans, Cocoon is in the end a web publishing mechanism. It primarily deals with the pushing of content in a systematic manner to different contexts. In that sense, Struts is a more complete framework.
For example, this page, http://www.twdata.org/struts/ , describes an example where cocoon is used to publish the content Forwarded by struts.
LDAP and namespaces
Continuing my foraging into mainframes and legacy systems, I found this interesting presentation explaining LDAP: Intro to Directories and LDAP, Contents Page.
A LDAP - based directory has both the information model and the protocol to access that information. It is used, for example, to store data whcih can then be used for authorization and authentication purposes in an enterprise system. Since LDAP is an open standard, it provides for gateways with other protocols like X.500 (which essentially is a heavyweight DAP), HTTP, e-mail etc.
A namespace is a mechanism to define a domain-specific vocabulary- a collection of terms that have a specific meaning in that field. They are needed in XML to standardize usage of tags, and to provide readymade starting points for makign descriptive XML documents.
While DTDs define a document as a whole, namespaces can be used to selectively qualify individual elements. This makes it possible for us to create documents from various sources.
Gateways!
Trying to understand the legacy system of a potential client, I came across this interesting article on Gateways: SunWorld Online - November - The golden gateway.
The Encina Monitor was developed to assist in the deployment and integration of legacy systems, into the client-server model. It is interesting to read how n-tier applications were a novel idea then, and compare it to the SOA-related excitement today.
Java Editions!!
I was trying to get the latest version of the Java SDK, and visited the Sun page- Java Downloads Home.
There is a whole lot of versions of different components available for Java. The SDK itself, for example, is available in 4 different versions, which are ceremoniously named with subscripts as long as a kangaroo's tail. It is sometimes unnerving. They should instead have a main downloads page with the Latest Version shown on it, ad a link to Older Versions. This will hide away some of the complexity for the casual user trying to get some innocent java-based software running on his machine. The naming could be simplified too. This is actually a part of the bigger philisophy that the Sun community follows of not being very user centric. I will write about that some other time.
On another note, one good way of showing off your technical suavity is to learn the names and significance of various versions. That would be handy to talk about at a techie's party!
Web Services for Remote Portlets
Portlets are applications that portals get information from. They are typically located on a different machine from the portal itself, in which case they are called remote portlets.
OASIS has come out with a standard called WSRP for letting portals access information from remote portlets using Web Services technologies. Basically the portlet exposes a WSDL interface which portals can tap into.
There is nothing terribly exciting about this development- I just wrote it as a follow up to my earlier post about RDF Site Summary- another syndication mechanism.
Some thoughts on the state of IT industry
In this article,
Business Standard .. McNealy: Stop IT mixing and matching, Sun chief Scott Mcnealy speaks at the Oracle world conference about the danger of overengineering by end users of application software. His argument is that people should seek to buy or lease the service in an integrated manner from experts rather than trying to put together or engineer components sourced from various vendors. He compares this scenario to the automobile industry- and asks whether you would like to build your own custom car or sit in one built by an expert in the job. He also says the IT departments of the future are going to be smaller.
His vision is driven primarily by the complexity problem of the IT industry. ALthough claimed to be in its nascent stage, already the enterprise computing industry is such a complicated marketplace of technologies, standards, vendors, outsourcing models etc., that it is increasingly difficult to make strategy related decisions. CTO or CIO level people find themselves in the unenviable position of having to peep into the future of an industry whose present itself is not well defined. The truth of this matter is this, and the sooner we realise it the better: the IT industry is like no other. Even the lowest rung people- the software engineers- are completely unlike the factory workers in old economy industries. They have to understand thousands of concepts, keep up with developments mushrooming faster than a hydra.
The big daddies of today's computing world have helped make this complexity, and made zillions in the process. IBM, Microsoft, Sun, Oracle are the players who have had the most voice in IT developments- and they have tried all kinds of vertical integrations- building their applications on their middleware on their operating systems on their hardware...Digital Equipment was the first to break out of this model, and try out its VAX cluster computing environment- and it sold like pancakes. Today's utility computing models being developed by all the names mentioned above are a similar attempt. The problem is that making a utility computing system which will also support the utility computing models of other players is not easy. It will lead to all kinds of integration and performance problems.
So what is the likely outcome of the complexity problem? Basically, CIOs will make a decision if it helps them do away with this complexity. They would like to know that their million dolar IT budget will not go down the drain. The Service Oriented Architecture is one way of ensuring this, and it is already a taken-for-granted by most companies. Utility Computing is another. And Scott Mcnealy is damn right- people will buy things that are built by experts, because things are going to get too difficult to understand at the componenet level. Ironically, the same companies will now make zillions in avoiding the complexity they themselves help built.
RSS - a syndication standard
I have always wondered how news portals are able to gather bits and pieces of news from various sources and put them on their sites. This article reference provided an insight:
New Zealand govt. RSS initiative
The article describes New Zealand govt.'s efforts towards coming out with a syndication (the process of publishing your data to various destinations) standard known as RSS. RSS stands for RDF Site Summary. It allows sites which put together information from various sources (known as "aggregators") to hook upto a "RSS feed"- a kind of a channel of information which typically refreshes itself periodically. This is done be defining an XML schema (a high-level description) which the two parties (aggregator and syndicator) agree on. This one time standardization is necessary- because there are no global standards for RSS.
The reason why every the govt. had to come out with its own namespace is that there are no global standards and the schema has to be domain and requirement specific. A news site would require a different tag library from an image collection, and so on. The original RSS 1.0 specs ship with 3 such namespaces.
So what? Well, this allows different government agencies to create their own feed to the central server, which becomes a one-point information portal for citizens. This is definitely a model to be followed in countries like India, where e-governance provides a short-cut towards improving administrative inefficiencies.
testing- start of blog. circa sept. 2003.
