Software Architecture
 Internet Architecture |
|
Software Architecture |
||||
|
||||
| Physical View | ||||
Not too long ago, this picture of Client-Server represented a vast majority of PC applications in the business world.
Products like Visual Basic and PowerBuilder made it easy to hook a fat client program up to a back-end database. Communications protocols were simple, proprietary database connections. It was common in this model to put business logic and rules into database stored procedures. That made them available for reuse by any number of applications, and gave data administrators some ability to control how data was accessed and used.
This structure had some problems: Memory-intensive connections to the database, deployment and configuration headaches, compatibility issues with other desktop applications are just a few.
Transaction processing monitors provided an interesting alternative. The "3-Tier" or "N-Tier" name counts the TPM as an architectural entity between the client and the database server. N > 3 when a TPM talks to another TPM or application server instead of a database. The benefits of connection pooling alone gave TPMs tremendous scalability and performance gains over two-tier Client-Server in some situations. Of architectural interest, components on the middle tier are available to any number of clients of various types.
Tuxedo is one example of a high-performance TPM. On the negative side, the protocols for calling the TPM are still proprietary.
In shops with a large "legacy" investment in mainframe processing, a model like this may be more common:
I have built several applications using IBM CICS as a TPM. CICS is a killer good TPM! But there are some negatives. Protocols between the client and mainframe are more complicated than the simpler Client-Server model, maybe distributed CICS, APPC over LU 6.2 or asynchronous messaging. The number of database connections is drastically reduced, but the deployment and configuration problems on the client remain.
About the time TPMs were really getting good, Object Request Brokers came along and stole the industry's attention.
An ORB enables distributed object oriented programming. An object on the client can create and use an object on the server with minimal house-keeping to handle the remote connection. The protocol is usually proprietary, but well encapsulated to keep things easy.
A number of software companies formed a consortium called the Object Management Group, which maintains a standard called CORBA. The promise was that compliant clients and ORBs from any vendor could interoperate to build complex combinations of distributed objects. While binary compatibility is far from perfect and the general perception was that CORBA was too complex to be worth while, CORBA ORBs are very effective, and can still be found under the covers of other technologies. The OMG remains a very active standards body in significant object modeling and distributed development projects.
Microsoft pushed their desktop Object Linking and Embedding off the workstation as Distributed Component Object Model. MS tools make distributed work relatively easy, but many developers feel that Windows solutions do not handle large-scale applications, and DCOM is not widely used. The latest incarnation of MS distributed processing is called Dot Net. As it is delivered over the next few years, it may win the hearts and minds of the business again.
The platform with all the buzz today is Java 2 Enterprise Edition. J2EE includes the Enterprise Java Beans specification. An EJB server is an ORB that facilitates distributed object oriented programming in Java. Where CORBA is multi-language, multi-vendor and MS solutions are multi-language one platform vendor, J2EE is one language, multi-vendor. The popularity of Java and the relatively good compatibility between vendors have helped J2EE take off very quickly.
All of the N-tier and distributed object servers provide services and APIs to the applications they host. J2EE has a good collection of services around transactions, security, session state management, and managed data persistence. These services automate a lot of work that developers had to do by hand in CICS or Tuxedo.
Forte is another ORB vendor I cannot leave out. Forte was conceptually years ahead of the world in distributed object oriented applications. Initially it was so far ahead that there were no standards to follow, and it got a bad reputation for being too proprietary. Later versions put standard COM and CORBA interfaces on the server, making it about the most open N-Tier solution available. Forte has been purchased by Sun, and is a strong player in the Java market but the original 4GL product is riding off into the sunset.
EAI is a fascinating part of Enterprise and Application Architecture. Through mergers and acquisitions, or just from a long history of business units developing in silos, we often have many disparate platforms. Standards like CORBA and J2EE are great for communication between like environments, but it's much harder to get different platforms talking to each other.
One good solution is the concept of a message bus. Message based middleware, like MQ-Series or Pipes, connects many different hardware and operating system combinations out of the box, and the number is growing steadily. It is possible to build language bindings to allow new languages to call - or be called by - common messaging service APIs.
Besides connecting different platforms, a message bus offers a nice layer of abstraction. A service consumer only needs to know the service (or queue) name, input structure and output structure. The message bus hides the service's location, operating system, programming language, object model, etc. Instead of coding a point-to-point direct call from client to service, the client just puts the message on the bus and gets the response back.
There are interesting categories of complex services. For example, an aggregator service might call two other services, in sequence or in parallel, and combine the results. A router function might look inside a request message and evaluate the data to choose one of several servers. Special EAI products, like IBM's MQSI, provide platforms for such services. They may use meta-data to perform versioning or data transformation.
XML is a wonderful format in EAI because it is understood by many clients and it is easy to manipulate with parsers and XSL translators.
| Internet Architecture |
