A paper on Mercury Communications Limited's early experiences with DCE by:
and
18 January 1995
The page's web-counter says that you are visitor number
since 28th November 1995.
Table of Contents
This paper was written to accompany a presentation on the use of three-layer architectures and DCE within Mercury, but it can be read on its own.
It was prepared by Alasdair Arthur and Peter Burke of the IS Strategy and Architecture Group.
Peter Burke and Alasdair Arthur were technical architects within Mercury when this paper was written. Peter has a billing background and was the Billing Technical Architect for several years. Alasdair worked within the Strategic Requirements Group and was responsible for setting up the DCE laboratory which pioneered the use of DCE within the company.
Thanks are also due to Ian Armstrong, John Norris, Stefan Jensen, and Colin Slater, who conceived of and built all the actual code and tools covered here.
The travel agent represents a real world parallel to the concept of the three-layer architecture. In this example, the customer is equivalent to the front-end application, the agent to the middle-layer logic, and the various reservation systems to back-end IT systems.
A customer makes a simple request to the agent, perhaps asking for the cheapest fare to a destination. The customer does not have direct access to airline guides or booking systems, but the agent does, and will transform the customer's query into a series of enquiries to different systems, compare and consolidate the results, and give the customer the answer. If a service changes(the advent of the Eurostar booking system for example) only the agent needs to be aware of this, the customer can be completely unaware of it and yet can still benefit from the services which it offers.
This concept of having an "agent" to act on behalf of applications is one of the powerful architectural ideas which is made possible by the three-layer architecture as opposed to a simple client/server design.
There are many different approaches to application architecture which fall under the heading of client- server. In Mercury's case, the approach adopted is based upon a distributed services model.
A distributed services approach involves the creation of a set of processes which implement business functions and which can then be used by any other process which needs that function. Examples of the functions involved include looking up a customer balance, updating address details, changing an employee's status etc. This type of business logic has traditionally been built into individual applications, and has not been accessible from outside those applications. This has led to the "legacy systems" problem which we have today.
The following diagram illustrates the concept of many applications sharing a range of services.
As can be seen, this model requires a communications infrastructure to provide the connection between the front-end applications and the services which they need to access.
This layer is more than simply a physical network and a communications protocol, although it includes both. The infrastructure must also provide a number of other facilities such as security, including validation and authorisation of clients, network logons etc., and directory services so that applications do not need to be aware of the actual location of the services which they call. There may also be a need to convert data, for example from EBCDIC on an IBM to ASCII on a UNIX or PC platform. These are the types of facilities which DCE provides.
With such an infrastructure in place, it is possible for any application to access any service which it has authority to use, no matter where or on what platform the service is implemented. The applications can be isolated from the details of the services' implementation, and the services in turn can be re-used by any application.
The infrastructure described above has many advantages, but it does still rely on each client application being aware in advance of the services which it needs to call. For example, the developer would have to code in a call to the "find customer balance "service if he wanted to use it. He would not need to know whereon the network the service would be performed, but he would need to know that that particular service was the one which would satisfy his data requirement.
In simple cases this requirement will not be too onerous. However, it is likely that more complex requirements will arise. In the above example, it may be that rather than wanting to know a customer's balance in a single system, the need is actually to get a picture of their overall balance with the company across all the product lines (and associated billing systems). In such a case, the developer's job is considerably more complicated. Even assuming that each of the relevant legacy systems has an easily-accessible API (Application Programming Interface), the developer must know about each one, and must call them all explicitly to gather the data.
There might conceivably be a dozen function calls just to satisfy the apparently simple balance request. These calls would have to be replicated in any other applications which needed to access the same information.
In order to cut down upon the complexity and duplication of effort which this would entail, it is proposed that a higher level of functional abstraction be employed - an "agent" layer.
The purpose of the agent is to act as a request broker or middleman, receiving a high-level request and carrying out all the tasks required to satisfy it. It will be comprised of modules designed to respond to specific requests, such as the customer balance lookup described above. The agent module would "know" which individual services it needed to call in order to satisfy the request. When asked for a customer balance, it will call each of the dozen systems required to provide part of the answer, consolidate the result, and return it to the calling application. That application will therefore have no need to call the services individually, and will simply make one request of the agent.
The use of the agent layer will allow applications to be completely insulated from the implementation of the business logic. It will also allow applications to be shielded from any changes to the underlying services, since only the agent modules would need to be altered.
The end result of this approach is an architecture comprised of client applications, the agent, and the services and data repositories. The principal benefits are as follows:
The demands of greater systems integration mean that there are an ever-increasing number of new applications which need to gain access to data and functions in other systems. Since the validation and business logic is locked away inside these existing systems it cannot be used by external applications. There are three common ways around this problem at present:
The distributed services model offers a way to overcome these problems. Instead of each application concealing its rules and logic from the outside world, these are "published" as documented and standardised functions. These functions are then used, not only by the original application, but by any other application which needs that service. This has several advantages:
The challenge now within Mercury is to take the concepts and the technologies of the three-layer model and DCE from the lab into the real world of applications development and deployment.
This is partly a battle for hearts and minds, and partly a matter of training and investment.
Like any company with a variety of different platforms and systems, we have a variety of skill sets to go with them. In the past, this has created problems ranging from the cost of re-training, to resistance or inability to change. One of the benefits of the new architectural thinking is that it allows us to employ the full range of existing skills productively, and at the same time to introduce new ones.
People who are quite content to carry on with COBOL or FORTRAN developments can continue to play a perfectly useful role, not just maintaining legacy systems, but adding value to them by making them accessible to the outside world.
On the other hand, we now have the flexibility to be able to employ specialists in areas like GUI design, without having to worry whether they are familiar with our particular mixture of databases, operating systems and platforms.
The fact that the architecture is layered has been very useful in arranging the roll out of DCE-based services. It has allowed us to carry out piecemeal implementations, rather than having to co-ordinate a big-bang roll-out across all platforms and applications. That sort of approach would be bound to create problems in any large company, and the fact that things don't have to be done that way is a great boon.
We will initially be installing DCE services into a major customer-facing application which was already built to a three-layer model. This means that we can have a controlled introduction of the new technology on a subset of our PCs, UNIX boxes and VAX's (the platforms for each of the three layers in this case).
The main advantage here is that each of the groups involved (developers, support team, systems and operations staff etc.) have a manageable amount of adjustment and novelty to deal with.
We would strongly recommend taking this sort of step-by- step approach.
Mercury has many disparate systems. There is no realistic possibility of integrating these on a single platform, so we must have a way of integrating application components across platforms.
By definition, the solution will be better the more widely supported it is. DCE is not the only cross-platform RPC mechanism - there are alternatives such a Netwise and the original OEC tools, as well as RPC offerings from companies such as Oracle. Mercury have chosen DCE instead of these alternatives because of it has the broadest base of support across the industry; initially from vendors and increasingly from end-users as well.
As DCE users, we wish to help DCE succeed. Joining the OSF is a part of this; not only does it give us access to support(both moral and technical) but also sends a message to suppliers that we are serious about DCE.
The project that could be positioned as the first 3LA project within Mercury was the "Captain America" project. This was initiated as a result of attendance at a conference hosted by Dr. Donovan (Cambridge Technology Group).
The application's purpose was to shield the users from knowing where the data that was displayed on their GUI workstation had come from.
Whilst the application did support a "middle layer" this was in order to manipulate the data before giving it to the presentation layer.
The development took place over the summer of 1993 and used screen-scraping technology to access VAX and IBM/CICS systems.
The screen-scraping approach lead to a number of problems, the greatest being that we could never be sure that it would work twice in a row!
The security administrators were never very happy about the idea of using a "concentrator" so that one IBM logon id would support many users. In retrospect this was because the application developers never really explained to Security what the 3LA was all about and how the change of culture from "protecting data" to "protecting services" did not mean that anyone could get hold of anything.
Because of the problems with screen-scraping and the unwillingness of security to sign off the application it never went into production.
Between summer '93 and autumn '94 we continued to investigate the use of DCE and refined our definition of what a 3LA meant.
We set up a laboratory with hardware from a number of suppliers( Sun, HP, IBM, Digital)with the intention of showing that interoperability was a fact rather than a sales chat-up line.
We refined our thoughts about the 3LA until we came to the conclusion that we should view the middle layer as a collection of services(e.g. "Retrieve all reported faults for this customer", "update all systems with the new customer address")rather than a simply a masking device to hide the back-end systems from the presentation layer.
Thus in autumn 1994 we decided that the time was right to attempt to create another 3LA application based upon our proposed technical architecture.
As with Captain America the project was time-boxed into a 4-week period. This time we spent considerable time with the security area discussing how service security differed from datasecurity and what implications this had.
The key technical differences from Captain America are -
The application works successfully in the lab and is being used as the basis for a 300-500 user project that will commence in March.
The roll-out of HPP is still being discussed - the decision depends more upon how well the application fits the work pattern of the customer service assistants than technical considerations.
This project will be the first DCE-based application to go live within Mercury. It will support 200-300 users and it will part of a mission-critical application.
The development has taken 3 months but that is not "from scratch" since it is built upon the previous work in the lab.
The existing application is Windows-based and implements access to VAX systems via a DDE link to a Reflection- based terminal emulation session. The new DCE features replace this with automated procedures using DCE, SQL and C and FORTRAN programs.
The application is currently in acceptance testing and is due to go live by the end of January.
The following diagram shows the basic technical architecture of the applications:
The second method has proved to be faster since SQL calls over the network involve more handshaking than local calls.
DCE is based upon a simple idea - the ability to distribute applications and services seamlessly across disparate platforms - but it is not yet quite so simple to use for everyday developers. Recognising this we have set out to create some in-house tools to insulate developers from as much of DCE as possible.
Ideally we would like to arrive at a situation where developers have to do little more that add the relevant procedure calls to their programs, and not have to worry about generating UUIDs, including IDL files, creating MAKE files etc.
We also want to make DCE services easier to manage at an operational level by providing monitoring and control information to operators and support teams.
We have started down this path with the creation of code generators which take an IDL file as input and produce the following:
At the workstation end, we have created DLLs which act as the interface between the client-end DCE code and the front-end tool. This means that the same DCE services can be used by any Windows tool which can use DLLs. Users can access corporate mainframe data from their Excel spreadsheets, Word documents or Powerbuilder applications.
We have also produced a series of performance monitors for DCE services which allow us to monitor not just the fact that a service is still running, but to see how well it is performing.
Another tool which is potentially of great usefulness is a DCE service which runs under Windows and can receive messages from the outside world. This allows a single-tasking Windows machine to behave as if it had a multi- tasking machine's ability to always be listening for unexpected interrupts. This facility alone will allow us to dispense with expensive polling of database-based work queues in one of our major applications.
The question that we have often been asked is "if the 3LA is such a good idea then how come we haven't done it before?". The answer that we give is that "the tools to support RPC interoperability (i.e. DCE) were not around before".
This simple answer suggests that all is "sweetness and light"; unfortunately it isn't quite that simple. We found that to get a PC talking to a middle-layer box was a non-trivial exercise and one that taxed the minds of our best "hackers". Even today, we do not have many people who understand and can support the very low level detail code that we have had to write.
We hoped to be able to take DCE out of the box and use it straightaway. Perhaps in future releases of DCE it will be as easy as that, but at the moment it's a bit more of a struggle. (Our membership of OSF proved useful here- we are able to call upon the DCE "gurus" to provide advice that might have taken us weeks to solve if we had been left on our own).
Having a working version of DCE on one's own premises and accessing" real" systems is better than any number of presentations to managers and sceptical "techies".
The DCE lab within Mercury had a mixture of bought and borrowed equipment (special thanks to IBM for their RS/6000 loan and Oracle for the loan of the Procedural Gateway software) and was staffed by people who were determined that a proof of concept would succeed.
Once we were able to demonstrate that a Powerpoint presentation could be turned into a working system then people quickly came" on-board" and began to see the possibilities and opportunities for themselves.
One note of caution - it is important to distinguish between a 3LA and a DCE proof of concept. Many vendors and systems integrators are keen to demonstrate that they can provide a 3LA solution using their own middleware glue rather than one based on DCE.
The DCE lab starting by looking at using three of the DCE components RPC, CDS and Kerberos. It was only when we took the decision to concentrate on the RPC component that we began to make rapid progress up the learning curve.
The first implementation of DCE within Mercury - "Pilot Light" will only use the RPC. In the next release we will incorporate CDS. We plan to wait until the release of DCE 1.1-based products before implementing Kerberos, simply because of the steep learning curve which exists at present for both developers and operations staff. Having said that, the security architecture that has been put in place is designed with an eye to migration to Kerberos at a later date.
Having worked with DCE and 3LA for a number of months we initially had problems in presenting our work. We had forgotten how much we had learned and much the 3LA had changed our way of thinking about application development.
We realised that ensuring the people understood the implications of the 3LA was a "slow-burn" exercise and would need constant re-enforcement.
Even today, after 3 months of being "on the road" there is still confusion in some people's minds as to what the difference is between 3LA and DCE and whether either or both mean that we have to re-engineer all our of existing applications onto a 3LA.
Within Mercury, it is the 3LA that is the "big idea", using DCE is just the means to an end.
Our biggest challenge, apart from getting DCE to work, has been in trying to understand ourselves and educate others in the consequences that result from the shift from the old paradigms of the "simple" client- talks-to-server or one-mainframe-for-everything to the" new world" of 3LA.
Examples of the changes are:
At nearly every presentation that we did, the question would be asked "but don't all these calls make for poor response times?".
Having read all the papers (including IBM white papers distributed at the last DCE SIG) we were fairly confident that this wouldn't be a problem but we didn't know for sure until we built our first system and tested it on the Mercury network.
In our experience (and we are at the final stages of performing soak testing for "Pilot Light") the performance is surprisingly good. This might be because the Mercury LAN/WAN set-up is particularly efficient or because we have got the design right first time. In any case, this is one area where we are likely to get seek some external help in reviewing our designs and implementation so that we can solve any problems before too many applications are written.
We have adopted the approach of gradually introducing services into the middle layer. During the migration period (which maybe years rather than months) some users will still have to login to the "back-end" systems to access data via the native screens.
Our approach for creating services has been:
The first two are pro-active, the third one is reactive.
There is an awful lot of useful, fully debugged and working code within the old legacy systems. Rewriting all of it to become true services would achieve little.
We have adopted the approach of "wrapping" a service layer around the old systems so that developers access the old systems as if they were services. The easiest example to explain is when we wrap a service around an existing CICS program. By making a few small changes to the CICS code it accepts its input either from a screen (via a BMS map) or from an APPC call (usually via a TDQ). The code that deals with the validation of the input and the updating of the data stores remains unchanged.
In fact, most of the time we have found that the legacy systems are very good at what they were designed to do, the problem is that we are now trying to use them for purposes that they were not really intended for. Going back to the travel agent example- it is hardly the fault of the application that supports the British Rail timetable that it can't compare itself with the British Airways timetable. This is where the middle layer comes in - it can provide added functionality rather than simply replacing existing functionality.
Having one or two 3LA/DCE applications will not mean that all the rest "fall into line". We need to ensure that the applications that are being designed and built today are implemented in a way that enables migration to a service based approach to happen.
We are not currently saying that ALL applications must be 3LA/DCE based since we don't get have a production 3LA application but our confidence is such that we are planning for success.
We encourage people to think and design around "service-based" terms - the use of database stored procedures and the concept of encapsulation are useful stepping stones.
We don't expect to get 100% re-use of our services. We would expect to design the service the first time, amend it
significantly the first time it needs to be re-used and from the second time onwards re-use with only minor amendments.
The alternative approach would be to do more analysis when the service is initially created to understand what the future
requirements are likely to be. In practice we feel that this may lead to "analysis paralysis" and the importance of getting
something "out the door" outweighs the possible rework that may be needed later.
The first implementation of a 3LA application will go ahead without clearly agreed processes and procedures for the configuration control of the services and the establishment of cross-application libraries.
We are anticipating that the implementation will lead us to address the issues as they occur. The reason for this approach rather than the more usual one of getting everything sorted out beforehand is that we have been unable to find other organisations who can demonstrate suitable models on which to base our procedures and processes.
This is probably a refection of how new the 3LA concept is and we hope that we are quick enough on our feet to solve the problems before they become critical.
Once we have a production DCE application then we anticipate the adoption of CDS and Kerberos will be easier rather than, as one might think, more difficult. The fact that we have something to test our CDS and Kerberos models against should make it easier for us to decide what is best for Mercury as opposed to trying to do it from a purely theoretical and paper viewpoint.
As we mentioned before, we see the adoption of CDS as relatively simple whereas we are not rushing to use Kerberos!
At first the concept of a "services-based" architecture may seem novel, but in fact we soon realised that we actually had quite a rich set of services in place already in the form of CICS transactions and Oracle stored procedures. We also have libraries of standard routines written in FORTRAN - the so-called Hg (shorthand for Mercury!) library.
It is quite easy to provide a DCE "wrapper" for such routines - the beauty of this approach is that there is no reason to disable the original interfaces to these services - a single CICS transaction can carry on doing its old job as well as joining the shiny new world of DCE.
Using this approach may well enable you to gain a head start in building up a portfolio of services.
We anticipate that the "Pilot Light" release will identify a number of issues to do with performance and reliability. We hope that our soak testing and OA testing will drive most of them out but we can't be sure - we will let you know at the next DCE SIG!
As for inter-operability we will continue to look at other ways of getting hold of data and functions on non- DCE platforms. In particular there are two areas were we need to continue work -Firstly, since we are in no hurry to move to MVS5.1, we need to continue looking at how we bring the CICS world into the frame, at the moment we are happy with the APPC route. Secondly, there are a large number of Macs within Mercury and DCE does not currently run on this platform. We will need to make a decision soon about using other RPC mechanisms to enable Mac-based applications to call the services that have been developed for the PC-based applications.
Security has been mentioned a few times - will we move to Kerberos or some other product (Tivoli?) and if so, when?
So far our 3LA work has not required the use of a TP monitor in the middle layer. This is probably because we have been building" simple" services rather than because we don't need one. Now that we have got a stable DCE infrastructure we will start to look at what our requirements are of a TP monitor and which ones are contenders. This is another example of where we have tried to solve one problem at a time rather than worry about everything all at once!
--- End of document---
©Mercury Communications Ltd 1995
Alasdair Arthur 
Peter Burke