![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
In 1855, 26-year-old Joshua Chamberlain, a rhetoric professor at Bowdoin College, gave a lecture posing the relationship between law and liberty, and the hazards of imbalance between the two. Law without liberty is tyranny, and liberty without law is chaos.
The management of a corporate information-systems department can foster excess law or liberty. An example of overextended laws would be the managerial directive to work with only one vendor, thereby exposing your systems to problems of extension or integration with potential corporate partners. With too many liberties, individuals or development groups are left to their own devices to pick technology that will again become difficult to extend or integrate if these technical gurus move on to "greener" stock options. One could be subject to the whims of a business environment.
Striving for environmental balance
A variety of environmental factors determines the laws in which our systems must exist. Systems existing within a business environment should have enough longevity to bring value to the company or customers. A system that consistently creates long-term value for an organization must deal with constant change. Mergers, acquisitions, new management, and market forces alter the environment of systems as well as the needs of the users who fulfill business processes through system use. Change is a constant and must be added to the evaluation equation. Certainly, we can't predict the future, but we can look at trends and try to design our systems so that lots of potential changes or system extensions can be accommodated with as little impact to the organization as possible.
To make proper decisions and evaluations, we need to understand the laws that govern the environment and the liberties our applications need to have within that environment. The most important law to understand is that our systems live within evolving organizations, whether business, governmental, or educational, and it is business issues that dominate the technical issues. Many architecture and platform evaluations have missed the main points. Often they entail standing two or more technologies side by side and comparing technical feature lists. Upon completion, most participants come to agreement because they are sick of dealing with the loudest, most adamant and powerful faction within the evaluation group. Obviously, this is not the most effective method for selection.
Determining key business issues
Translating business issues to the practical evaluation of organizational needs means that major consideration should be given to:
- The technical skill set within the organization
- A development environment that does not constrict programmers
- Run-time environments that do not impose restrictions on applications
- Licensing and legal issues of the run-time and development environments (the law of laws, so to speak ;-)
- Access to trained developers
- Access to affordable and knowledgeable consulting services
- Impact on organization's customers
- Impact on vendor or technology partnerships
- Organizational culture and politics
- Organization's upper management alliances
- Whether the "big boys" are talking acquisition or merger
- Who is sitting on the Board
These business issues will generally have more weight than, say, the thread-per-session versus. thread-per-request concurrency models. You can go into your boss's office and throw around enough tech talk to fill a software conference, but unless the needs of the organization are addressed, your points will sound hollow.
Let's now pit CORBA against these issues. CORBA is an open industry standard that is backed by over 600 companies working with the Object Management Group (OMG). These companies include hardware and software companies, telecommunication companies, financial companies, universities, medical institutions, and government agencies. The OMG does not implement their own specifications; they rely on vendor implementations that help target competition toward features, performance, and price as well as encouraging quality. The OMG is a vibrant and active organization in its own right with many of its officers writing articles and speaking at numerous conferences. Keep your eyes open and you will see they are always monitoring the changes that will affect their organization as well as yours.
With that said, CORBA provides a high degree of interoperability. This ensures that distributed objects built on top of different CORBA products can communicate with each other. Large organizations, therefore, don't need to mandate a single CORBA product for all development. The OMG has worked diligently to provide a greater level of portability by tightening up the CORBA specification. Be aware that portability of source code will remain elusive as vendors differentiate their products and developers push the limits. It should be stated that portability is substantially better than in previous versions and should continue to get better as the Internet Interoperability Protocol (IIOP) continues to develop a strong following and many alliances.
The discussion will soon turn toward Java technology, but first we should look at languages as a whole. A certain law of information systems is uncertainty itself. Java programming language might be the language of the day, but when will the next great language eclipse it? You know that someone is banging out a better language in their garage at this very moment. Therefore, CORBA's language independence will help you stay within this law of the information-systems environment for the long term. CORBA supports a classic and solid object model that will keep marching into the future. It has held up against the latest languages and continues to be extended to terrific new languages like Python.
Java programming language and others
Another certainty we can apply to this environment is that it will be regrettably complex. This is where Java technology comes in. It'll fit nicely because its simplicity will help to liberate development from getting bogged down in the underlying complexity. In many areas the Java language hides some of the fundamental details, but, overall, Java technology streamlines the entire process from analysis and design through execution.
It is crucial to be able to express your system and design patterns as uniformly and unambiguously as possible during analysis and design. The Unified Modeling Language (UML) has become the de facto language for expressing the design of your system. The development of UML is a great story in collaboration. UML also has an interesting path to standardization. The path UML took toward standardization went right through the OMG. The OMG recognized the need for a standard modeling language that would express distributed object models across languages and environments. The Java object model overlays the CORBA object model nearly perfectly, allowing your UML designs to be easily mapped to an implementation, and UML diagrams mapped to Interface Definition Language (IDL)-to-Java language implementations.
The objects that come out of the analysis and design phase will have interfaces that define how other components will call into your services. Those interfaces now need to be translated into an implementation language. Java technology again makes this easy. The IDL-to-Java language mapping is straightforward. The Java language and IDL each provide an interface keyword that helps to show the strong relationship between the data types expressed in each language. Java technology provides a reverse mapping from a Java interface to IDL. No matter which direction you choose, you should have your interfaces expressed in IDL; this affords you the power of all the other language mappings provided for IDL, and the language independence necessary for greater freedom in the future.
In addition to the design, the architectural structure of the system is important. Many system architecture issues deal with the inclusion of existing systems: databases, legacy systems, available objects, or applications that might be written in other languages. The Java and CORBA languages enable, rather than disable, the ability to bring these powerful systems to a greater audience of users. This is liberating -- many systems might have been around for years, proving their value. In fact, after all the pre-Y2K efforts to bring these systems into the new century, they might be around for years to come. Because of its compiled byte-code structure, the Java language will allow you to create portable objects and distribute them easily, while CORBA lets you connect and integrate them with the rest of your computing environment.
I do not mean to use Java and CORBA technology to the exclusion of the Java language's Remote Method Invocation, Enterprise JavaBeans technology, Microsoft's DCOM, or even DCE. The most liberating aspect of the Java and CORBA languages is that the OMG has worked overtime to ensure that CORBA objects can interact with a plethora of objects. Of course, some of these connections will be more difficult and might turn out to be fragile. Keep in mind that, many times, these types of connections have been made for architectural, cost, time, or business reasons.
Interconnection and communication in a heterogeneous system environment should be the goals. The laws we choose to work with should allow the freedom to use existing systems along with new systems to solve organizational needs. These laws should provide the greatest flexibility when changes are forced upon an organization in this shifting world. These laws provide a sphere of operations that limit our liberties such that it makes it difficult to fall into a state of random development.
Thank you for bearing with me. I am not a rhetoric professor, but a programmer, so in the next installment we will start with a simple example -- implementing a CORBA client and server using Java technology.
- Java Programming Language, Third Edition, by Ken Arnold, James Gosling, and David Holmes (Addison-Wesley)
- Barnett, Randy E., The Structure of Liberty, Oxford Press, 1998.
- "Recommended Best Industrial Practices for Software Architecture Evaluation," by Gregory Abowd et al, Technical Report CMU/SEI-96-TR-025, Software Engineering Institute, 1997
- The Object Management Group
- Software Engineering Institute
- Java technology
Residing in Berwyn, Pennsylvania, Dave Bartlett is a consultant and freelance author and lecturer. He is the author of Hands-On CORBA with Java , a 5-day course presented via public sessions or in-house to organizations. Presently, Dave is working to turn the course material into a book entitled Thinking in CORBA with Java , which will be free to download as it evolves. Dave has Masters degrees in Engineering and Business from Penn State. He can be reached at dbartlett@pobox.com.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
