TechTalks Transcript
Where Are We With Middleware?
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Ken Klingenstein [KK] |
March 25, 1999
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
JB: Welcome to the CREN TechTalk series for Spring of 1999, and to this session on "Where Are We With Middleware?" You are here because it's time to discuss the core technologies in your future.
This is Judith Boettcher, your CREN host for today, and I'm pleased to welcome the technology anchor for TechTalk, Howard Strauss from Princeton. Howard is a well-know Web and all-around Information Technology expert.
Welcome, Howard.
HS: Thank you, Judith.
I'm Howard Strauss, the technology anchor for the TechTalk series of technology Webcasts. The job of the technology anchor is to engage our guest expert in a lively technical dialogue that will answer the questions you'd like answered -- and ask those very important follow-up questions. You can ask our guest expert, Ken Klingenstein, your own questions by sending e-mail to expert@cren.net anytime during this Webcast. If we don't get to your question during the Webcast, we'll provide an answer in the Webcast archives.
For this Webcast, as for all others, I prepared a list of potential questions and topics that might be covered and passed the list on to our guest expert and to several folks at CREN. Never has it been more difficult to create such a list! It is not that the topic of middleware is so difficult to understand -- it's that middleware seems to mean something quite different to different people. In fact, when I let our guest expert, Ken Klingenstein, preview my list, his response was that I had come up with many interesting topics that he agreed were middleware-related, but that the items on my list were not what he planned to talk about (so it'll be interesting to see what he does talk about today).
That was quite a surprise to me, since I had carefully researched my questions, asking the most knowledgeable sources I could find. I started, of course, with my mother, who informed me that hardware was what the knees of my jeans got when I was a child, but that she had no idea what middleware was and she was certainly not interested in me telling her.
Other people I talked with knew that the keys to middleware lay in understanding the alphabet soup of ORBS, CORBA, COM, DECOM, DCE, TINA, RPCs and the intricacies of NT architecture. The Web made it clear that knowing middleware meant understanding fat and thin clients and focusing on MIS applications. Ken suggested that I better look at ubiquitous computing, advanced applications, directory services, authorization, authentication and underware -- that's W-A-R-E on the end, which he insisted was just part of middleware.
Learning what middleware really was was like the six blind men of Indostan, trying to learn what an elephant was, in the fable by John Godby Saxe, which starts:
It was six men of IndostanWhatever middleware really is, it is clear that it is quite important, that zillions of dollars are being spent on it, that there seems to be some pressure to be doing it, and that it can be quite hard to do. But this fuzziness about middleware only makes this Webcast more important in our attempt to really understand it. As the poem continues,
To learning much inclined,
Who went to see the elephant.
Tho' all of them were blind,
That each by observation
Might satisfy his mind.
And so these men of IndostanPerhaps Ken's keen eyesight will be able to discern what this middleware beast is really all about as we discuss middleware issues with him in today's Webcast TechTalk.
Disputed loud and long,
Each in his own opinion
Exceeding stiff and strong.
Tho' each was partly in the right
And all were in the wrong.
Judith?
JB: Well, thank you very much, Howard. It's interesting to think about that comment that while each of us is in the right and yet some of us are in the wrong. Most of us feel that way about middleware. And particularly -- I think it's important -- I think it's the first time we've had poetry in our introduction to TechTalk. But it highlights, I think, the fact that engineering has a certain art in it, and art has a certain amount of engineering in it.
So with that, let me introduce our guest expert for today, Ken Klingenstein. He is the Chief Technology Officer at the University of Colorado at Boulder. Ken has been active in national and regional networking since 1985, serving on many boards and councils. He is a former chair of the Federal Networking Council Advisory Committee, has been a board member for FARNet (which is, by the way, now called NET@edu), and is also co-founder of Colorado SuperNet. He has served on the board of directors for CAUSE, now consolidated with Educom as Educause. (This introduction could get long doing this!) And he also serves on the Coalition for Network Information Steering Committee, and is also, I'm pleased to say, a member of the CREN board of trustees. He's testified before Congress on networking topics and regularly presents to many professional networking and computing groups, and is also a favorite and regular guest on CREN TechTalks.
Welcome back, Ken, and thanks for being here today. I understand it's spring break out in Colorado and that you're usually teaching at this time every Thursday.
KK: It's kind of nice, Judith, to sit back here in blue jeans and sandals instead of the tuxedos I normally wear during my teaching.
HS: I can imagine!
JB: And our guests know that you never wear anything but jeans, right?
KK: And actually, Tuxedo is a piece of middleware that we'll get to later.
JB: Oh, it complements the underware that we're going to talk about, right?
HS: Ken, maybe you can start by telling us what you think middleware is, since we've already talked to everybody else about it.
KK: Well, as you surmised, Howard, it very much depends on your point of view. It's the intersection of what network designers don't want to do and what application developers don't want to do. So if you're an application developer and something looks gunky or looks like it may be needed for multiple applications, you say, "Gosh, that's middleware -- it's somebody else's business!" And if you're a network person, well, there's a famous quote from Fred Baker of Cisco (who's also chair of the IATF). When asked what middleware was, he said, to him, PCP/IP is middleware! From where he sits, he just looks up at the bottom of the septic system and everything that's coming down is middleware to him.
So with that, I think we can hone in on a couple of definitions that capture at least parts of it. One nice phrase is that it's a persistent presence in the networked world. That is, in the networked world, you go to different workstations and you do different activities, but you'd like a fair amount of who you are to persist from moment to moment and perhaps find you in the networked world.
HS: So are you saying, though, that anything that is -- that could be called middleware? If we find some persistent presence?
KK: That certainly is a piece of middleware, but I don't think it's exhaustive. It's also a set of core software components that permit scaling of applications and networks. I think if you want one phrase, it may be the tools that take the complexity out of application integration. It takes the stuff that's in the silos of the applications and moves them out into daylight where multiple applications can access it.
JB: And we're going to talk a little bit further on today about examples of just what some of these tools that we're talking about are, Ken, right?
KK: Right. We'll go into some depth on that, Judith.
JB: You know, we may want to mention to folks that there is the presentation that you put together, and that it's up and can be accessed from today's event page (and if people are there, they can just find it in the second line below the section on resources). But since we really do have this as a discussion and interview, we're definitely not going to follow it piece by piece.
HS: In fact, I'll hop right off it on the next question.
JB: Yeah, right. We're going to just go move all around there. So basically, we were talking about what middleware is -- and I'm not certain that I really understand much more about whether I know more about what middleware is now than when we started a couple minutes ago, Ken.
KK: Well, I think we can tease out some regions within middleware, and that might be useful. And at the bottom of the stack, there is middleware that enables networks. And you could identify, for example, secure DNS. Now initially, we didn't worry about the security of DNS because it was a static cable, but as --
HS: Is this the stuff that you're calling underware, the stuff on the bottom here?
KK: I would guess so, Howard. I think that's a reasonable place to label underware. It's too good a phrase not to use somewhere in this metaphor.
JB: And the reason people do call it underware, it is one of the very lowest. It is a combination of some of the lower levels of middleware.
KK: Right.
JB: If we were to think about middleware as maybe having two or three regions, it's one of the lower regions of middleware?
KK: Right, but I want to be careful here to not indicate that you need underware for all applications of middleware -- whereas there is a core set of middleware services that we'll get to in a minute which, in fact, seem to be the elemental pieces that will drive all of the rest of the regions of middleware.
So if we go back to that bottom layer of secure DNS [Domain Naming System], it's only when you get into things like Dynamic DNS (which is a protocol which has become an IATF standard -- you can find Dynamic DNS inside NT5) -- we're not going to allow people to register hosts without some kind of security mechanism. So suddenly, DNS has gone from its simple form of the last 20 years to something that needs authentication. Authenticated DHCP [Dynamic Host Configuration Protocol] is another example.
An interesting one that's come up recently, again at this network layer middleware, is private multicast. Now, multicast is very hard, no matter how you slice it. But if you look at what multicast is today, it allows people to join and move themselves from broadcasts of information -- much as what we're doing today. But in the future, we're going to want to secure that because we're going to be doing pay-per-view using multicast. So where today's multicast has no knowledge of authentication, in the next generation of multicast, we're going to want to allow people to join a multicast IP block only if they're authenticated.
JB: And that sounds like it would be a great application for distance learning, if we're going to be doing distance learning across time zones and across geography.
KK: Exactly.
HS: Can we just get by one area where -- I've talked a lot to people who, when they heard we were going to do middleware here, they positively, absolutely knew that middleware was this three-tier architecture stuff. And the way you're talking, it seems like that's not the case. That's not the thing that defines middleware as that middle tier. Is that correct?
KK: Well, yeah, I would think that if people are looking at the slides online, about Slide 4 there's something called a Mega Middleware Map, and that helps to establish these relationships.
We've been talking about the network-layer middleware. Right above that are a core set of services that drive almost all of the upper reaches of middleware, and those core services are services which have been covered in previous TechTalks and will be covered in future ones as well -- things like identity, authentication, and directories. Those three elements seem to be very basic.
Now in the corporate world, those issues are well-resolved, and so they immediately move onto business middleware to reach their clients -- CORBA, ORBS, DECOM, some of the other alphabet soup. But at universities, we have a much richer environment, a much more complex environment, and we haven't solved identity and we haven't solved authentication or directories. So for us, the business is the hard -- if mundane -- elements of that core.
And then from that core, we can begin to create the upper reaches of middleware. And for the purpose of today, we can segment that upper reach into three fairly distinct components: One is the corporate upperware, and as you said, Howard, so well, it includes messaging and object request brokers, transaction processing monitors, etc.
But researchers believe that middleware is something very different. To them, it's the ability to co-schedule supercomputers and networks simultaneously so that their advanced application can execute passing its massive data flows through the network with guaranteed bandwidth to the next supercomputer that's going to munch it, and the hopping it across country to some other machine. To researchers, it's being able to find application libraries. They have, again, a whole set of self-describing collections of information.
And then for most of us on campuses, where we really want to use middleware is to enable ubiquitous computing across campus. We want a student to be able to sit down at any workstation, and after a brief pause, have all of their e-mail aliases on their desktop, have their bookmarks available to them, have their roaming profiles of who they are available, much as we have them on our own desktops.
So that kind of partitions the space of the upper reaches of middleware, and each of those three regions in turn depends upon the core middleware; authentication, identity, directories for enabling tools.
HS: So why is middleware called middleware? I thought it got the word middle because it was the center tier.
KK: It is. And to the casual eye, it looks like a single block of elephant, I guess.
JB: It's that elephant with all those different pieces to it, huh?
KK: Right. As we dive deeper into it, it looks more and more like a complex area, and the only reason it deserves one name -- middleware -- is that it's below applications and above networking.
JB: Maybe we ought to think about going back to what you called the core of middleware. So if middleware is more than one big block, you're really helping, I think, to clarify just what are the various components of middleware.
And going back to the elephant analogy, just what are the pieces? You mentioned three pieces before, Ken, and that was identity -- just who I am -- and authentication -- verifying that, in fact, if I can prove that I'm that person -- and then the directories. Are there practical situations on campus where you can describe where identity would be important?
KK: Sure. One of the ways you know it's middleware is that it's missing.
JB: Oh, okay!
KK: It's that hole where you have to do a work-around.
For example, imagine a faculty member who can't access scholarly databases or the university's digital library services from home because the university has outsourced the modem pools, and she's coming in with an IP address that isn't the campus IP address. What's missing there is a different form of authentication that isn't IP address-based that would enable that faculty person to identify who she is and authenticate as a member of the institution without having IP address as the decider.
Again, middleware would be the piece that would allow a student to sit down at any keyboard and have it be customized. Middleware for me would mean that I wouldn't have nine accounts and nine different passwords. Actually, I have nine accounts and one password. Actually, I have nine accounts and two passwords. I just can't remember the password -- the second password for the other four accounts.
JB: For all eight of them, right?
KK: Right.
JB: It sounds as if identity would be easier than what it sounds like it is, Ken. Why is identity so hard? What's involved with that?
KK: One of the things to realize is that we make the computing environment that much richer. Tools that were okay in the past need to grow. I think identity is a very good example of that.
Most of us on campus have identity based upon some UNIX ID that we actually never really see -- or we may see it as a login name. But that doesn't work as an identifier well when you want to have the same identity work for NT -- for your NT accounts -- because the 16-bit group identifier which is used in UNIX doesn't match with the 32 bit identifier that NT wants. Or you have outsourced modem pools and you'd like your identity to be waved in front of that. So it's likely that we will keep the UNIX ID, but we will create something even more primitive and more basic -- a first identity which we'll use then to create additional identities in the general realms that we worked in, namely NT and UNIX and maybe a couple of other areas. So at my campus, we still use the identity tool that we created 15 years ago, but it's on its last legs.
HS: Like COBOL, right?
KK: Yes, like COBOL.
HS: Which tends to hang around.
KK: Sure it does.
HS: You talked about an interesting story about Stanford University when we talked last -- about their attempt to characterize relationships -- which I think is related to what we're doing here. Could you tell us that again?
KK: Sure. At Stanford, in preparation for their financial systems and their wonderful directory development -- it's a project called Horton, by the way, and I think that --
JB: That goes back to Dr. Seuss, doesn't it?
KK: It does. (Something about you're someone even if you're very small. That's what the mouse was told by Horton.) That they went and tried to identify the kinds of primary relationships that an individual could have with a campus and came up with 92 different characterizations. It turned out to be, unfortunately, one short because they missed "former presidents of the university," and after they cleaned their database relative to this, they discovered that he could no longer log on. Slight pause while they fix that!
JB: So they added a new category?
KK: New category. Now, when you start to do this relationship to the institution, the question emerges, where do you want to capture this? Do you want to capture it in the identity or do you want to just have this be part of the directory information or part of some authorization information? And the answer, like everything else in our business, isn't clear. If in fact we're going to have different types of identity invoke different authentication methods to prove themselves (so that one group would use Kerberos, one group would use an X509, one might use SmartCards), then you could see where you want some hint in the identifier about how you expect somebody to authenticate themselves as that identity. And again, this gives indication that the simplistic way that we've dealt with identity in the past may need to (inaudible).
JB: Hi, Ken? I think we may have lost Ken, Howard.
HS: Okay. Well, if folks are expecting that I will answer questions about middleware, this is going to be an interesting kind of thing here, which I certainly can't do that. We're hoping, though, that Ken will --
JB: Hopefully Ken will call back in here very quickly.
HS: Very quickly here. Perhaps we should talk about some of the other questions that we're going to cover.
JB: And also we could remind our listeners to send in messages and questions to Ken as soon as he comes back in again.
KK: I'm back on! I don't know what happened.
JB: Okay, good. I was just reminding folks that they could send in questions as soon as you came back, Ken, at expert@cren.net, so I'm glad that you're back.
KK: I apologize.
JB: Was it something you said about identity?
KK: I suspect so! Maybe my relationship to the institution is changing.
HS: Or a phone company.
JB: Ken, maybe we want to talk a little bit about some of the technologies that are, in fact, being used to start solving or at least work on the road of solving some problems with the middleware technology.
KK: And I'd love to do that. Let me preface that, Judith, by saying that what makes middleware hard is that it isn't just a technology issue. It is, in fact, issues about practice and the design of middleware space -- and it's as much resolution of policy issues as anything else. We'll get to that later in this conversation. But let's remember that because middleware is where the rubber meets the road, the characteristics of the road are very important.
One of the things that you need to look at in life, as we look at middleware, is when we just use the corporate solutions -- is there any reason why higher ed has to be different about this? And unfortunately, the answer is yes, that we have certain characteristics that distinguish us from the corporate enterprise, and those characteristics range from the fact that our workers (namely, students) don't use the same keyboard all the time. So where authentication in the corporate world can be handled by an X509 certificate sitting on your hard drive, when you're moving from hard drive to hard drive, that is no longer a valid way of working.
Another characteristic of higher education is that (at least at public institutions like my own) the moment that somebody steps into the library, they become eligible for using library resources, including electronic databases. We have to generate identity on the fly. Again, something that most corporations don't have to worry about.
We're not crisp in how we define roles of individuals. Typically, somebody is both a faculty person and perhaps a staff person, or staff and student. So we have blurred characterizations that make life more complicated. We have issues about FERPA and open records, and that will affect how we view directory information.
HS: Want to say a few more words about FERPA?
KK: Sure. FERPA stands for the Family -- help me, Howard!
HS: Family Educational Rights and Privacy Act. And don't think I knew that a couple days ago!
KK: And basically, it characterizes which aspects of your personality, as it were, an institution is required to reveal to somebody who makes an inquiry. And we know, for example, that an institution can say, "Gee, this person is a student or is not a student," but they don't have to reveal what class you're in.
Well, what happens when we start to put bookmarks into directories? Then the question comes up, if I receive a subpoena for somebody's bookmarks, do I have to reveal them? What happens when I start to put your calendar online? Can a subpoena or an open-records request from a reporter force us to reveal who you're meeting with? These are issues that technically are fairly straightforward, but we need policy resolution to make sure that, as we go ahead and automate what had been previously private activities of people's lives, that we have a way of discerning what's public and what's private information.
The last differentiator is that we have a need for interoperability. The authentication method for GM need not interoperate with the authentication method for Ford. On the other hand, Harvard and Stanford may want to share digital library access, and so their authentication schema need to interoperate.
JB: Ken, do you want to follow up on that a little bit? You had mentioned, when were preparing for the session, that we often think about interoperability being on the technical level and that's really the least of our problems.
KK: Well, it's certainly one piece of the puzzle, but suppose, for example, that two universities have agreed to participate in a digital library license, and a license is available to full-time students. Well, if we have different definitions of what "full-time students" mean, is that going to gum up the license? So we may need to have consistency in our metadata about the data that we don't have today. Universities have wildly different definitions of what a full-time student is, and we're just going to need to make sure that those definitions can be reconciled, if not consistent, where needed.
JB: Okay. In terms, then, of all the formatting of our various directories and systems, if in fact we could solve some of the problems with the middleware, then the interoperability at both the technical and policy levels would begin to be addressed.
KK: Well, again --
JB: Or no?
KK: No, probably not. We can use the same tools in wildly different methods and that could be problematic. But I don't think that that consistency or reconciliation of metadata is going to be as hard as it was 15 years ago. The cloisters that were the Registrars' offices in higher ed are no longer quite so cloistered. These people collaborate regularly using the network. They are moving towards convergence naturally, and I think we can facilitate that convergence process to some degree.
JB: Okay. Going on to some of the dependencies that we've talked about and really differentiating just what this middleware is all about, are there going to be specialized servers evolving to address some of these special higher education needs, do you think?
KK: Yeah, it is the case that both on campuses and then more broadly within our community, we will have specialized servers. On campuses, we may have an X509 server, and then in turn, those X509 servers around campuses need to fit into a hierarchy so that they can validate each other, and that's where the CREN top-level certificate authority comes into play. Another place where there'll be a top-level authority will be inside the .edu area of DNS, where Educause has signaled that they're willing to play that role. So we'll need both servers on campuses, and then we'll need hierarchical servers between campuses to exchange the interoperability piece.
In some cases, we once thought it was going to be a single server. I think directories are a good example of that. As we get to understand directories more fully, we realize that there are multiple pieces here -- there are high performance pieces, there are archival pieces, there are places where we want users to be able to change information, there are places where users can't change information. We will wind up with many directories on campus and then seek metadirectories to help us identify which directory actually has the information we're looking for.
HS: Ken, you suggest that higher ed is really quite different than corporations in terms of their view of middleware. Could you talk a little bit about the difference?
KK: Yeah. I think we identified some already, Howard, in mobility -- in multiple roles. For example, if you look at the certificate development that's being done at the University of California system (as David Wasley pointed out a few weeks ago in his talk), one thing that they're realizing is that people will not have single certificates -- that you will want to have certificates that capture the role that you're playing, the role that you have that would allow you to access a certain resource. So the fact that you're a business faculty member will allow you to unlock some doors. The fact that you're a senior faculty rank will unlock other doors. You're going to want to wave a minimalist certificate in front of a resource to get in. You don't want to reveal more information than necessary to the resource, and that's very different than the corporate world where your role is clear and you can get away with one certificate. I think that's an example of some of the distinctions.
It's interesting that, when all is said and done, networking in corporations and networking in higher ed is going to be fairly similar. When all is said and done, our applications may be fairly similar, but it's likely that our middleware will always be fairly different between higher ed and the corporate world.
JB: Ken, one of the things we like to do is really talk about if someone is on a campus and they're just really trying to get a handle and get their arms around just what middleware is -- what are some of the basic things they ought to be doing, and then perhaps going on from that, how do they avoid going down and doing some dumb thing, so to speak?
KK: Well, we call those dumb things learning experiences.
JB: That's true! That's good to know, right?
KK: And going back to our earlier metaphor, the very first thing to say is, "Don't stand behind the elephant. The other end looks a lot more appealing." We're starting work right now on directories at the University of Colorado, and the first thing we're doing for several months is just building an inventory of all of the niche directories that are around campus.
JB: So there's a bunch out there right now, you're saying?
KK: There are phone directories, there are e-mail directories, there are places where we do keep some roaming profiles for students. We keep e-mail aliases in one place. It's scattered all over the place. Almost every application has a silo of management data that we really want to liberate and move into a more common resource. So an inventory of where you're at is very useful, and an important starting point.
I think it's also important to move simultaneously, if carefully, in the areas of identity, authentication and directories -- to realize that the identity server that you have today may need additional functionality, and spec out what could be there in a year. Even if you don't put it in, at least you know not to put that information into the directory and instead, to put it into the identity when that capability becomes available.
A third thing is to get the people who control the data (because middleware is really about real-world data) -- it's to get the people who control the data to participate in the grand adventure that lies ahead. Get them to agree that they are willing to provide the referential and biblical data resources that we need to populate the directory -- getting consensus on who owns which piece of information, getting consensus on who's permitted to update various fields of information. I think there's a lot of legwork, because we're going to need our partners on campus as we move forward in this.
A last thing is that it's likely that, over the next several months, there will be a number of national higher education initiatives in this area. Everybody's realizing that the lack of middleware is an impediment, and it may be CREN realizing that it can't lock down its Website to CREN members only without some kind of authentication scheme. It may be Internet2 realizing that the applications are coming along quite well, thank you, and the network's being built, but there's no management tools that would stop the unwanted videoconference from automatically initiating on your screen. We need call management for videoconferencing. How are we going to get there? So I think as these national initiatives begin, it would behoove folks to pay close attention and to latch onto them, to use them to guide the work on the campus that needs to be done.
JB: So that's a good step. Let me remind everyone to say that they can send their own specific question in to expert@cren.net and Ken will answer your question online here. Howard, do you have another question along the same lines here?
HS: Yeah, I certainly do. I have lots of them here. Ken, you've been talking about what middleware is and what it's done and things. What about some future directions for middleware? Where's this thing going? Where are we likely to see changes or new directions?
KK: Ooh. Like communists, it's everywhere.
HS: (Inaudible).
KK: I guess communists are nowhere these days, but --
JB: That's true, too.
KK: Again, we're going to be working the core territories a great deal, but there's a couple of exciting upper reaches that people might want to pay attention to as well.
There has been a major effort done called Project Globus, and that's available at www.globus.org. That's an effort on the part of supercomputing users to begin to develop their kinds of middleware -- things like the co-scheduling of resources, etc. What Globus has found out, however, is that they're utterly dependent on campus infrastructure -- directories, authentication, etc. -- which doesn't exist yet. So even as the upper reaches begin to develop -- and again, the administrative applications upperware is coming along and ubiquitous computing is coming along. I think those develop of their own accord pretty well, but they're all reliant on these core services.
And what's frustrating is that the core services are not so hard technically. It's the fact that its political processes, its practices -- you're going to design security for your campus for authentication. What are your security zones? Who trusts who?
I remember a few years ago seeing an announcement of a Kerberos server for the University of Michigan, followed two weeks later by a correction that indicated, yes, there was one Kerberos server for Michigan, but there was a second one for the College of Engineering at Michigan, followed by a correction two weeks later that said that, indeed, there were those two Kerberos servers, but Computer Science within the College of Engineering within the University of Michigan had its own separate Kerberos server.
So we need to take and structure the security cells on our campus. We need to recognize which directories are going to persist because they're locked into legacy systems, figure out how at least the information in those directories can be used to funnel other fonts of information out there.
So my suspicion is that the upper layers, Howard, of middleware will come along okay, and it's the bottom layers and the core services where we have to deal with non-technical people (university lawyers, God forbid) where the challenges are going to be. And I think we'll finally see people step up and say, "Let's see if we could get all university lawyers around the country to agree on some common definitions of what elements within a directory are private and what elements within a directory are public."
HS: Talking about this middleware stuff, I wonder, does it take special skills for people to get involved in middleware? If the university has its normal staff of programmers, are there special people they want to look for to do middleware, or can we just take whoever's doing whatever they're doing right now and move them in here?
KK: Well, let's see. Good question. There are certainly two or three technologies which are going to be omnipresent. We need LDAP. You need people who are skilled in that tool. Java is going to be a very widely used tool. We're going to need that capability. X509 will eventually make it -- not here yet, but it will be, and we'll need people who understand how to manage certificates and certificate servers. So at least those three elements are going to be part of however you craft your middleware solution. And it's not too early to send people to Java training, not too early to take those courses on LDAP.
HS: If somebody has a bunch of COBOL, MIS type programmers, that's what they ought to be doing -- they ought to be off in Java school?
KK: If that's efficient. It's certainly necessary, but there's a mindset there that you have to work on as well.
HS: What about, most universities have a whole bunch of existing systems floating around here that were built and designed without any thought of middleware. Is there some scheme or some suggestions you can give us to move those things?
KK: Well, those systems will persist. They're optimized for their particular activities and we're not going to build needless complexity. But we are going to have to figure out how we're going to get the management information inside those systems to feed other systems. We're going to have to work with our mainframe shop so that the student database is spit out into the LDAP directory on a regular basis to populate certain key fields of that. We'll have to talk with Payroll and Personnel about similar activities.
So I think the legacy systems will persist. We're busy enough as it is, so we'll have to find ways of using the information within the legacy systems to feed this new middleware.
JB: I've been checking for our messages, Ken, and I think that we may have a little bit of a problem in getting messages in (and I'm having somebody check on that right now). By this time, we usually have quite a few of the little messages coming in and there seems to be something going on. So at any rate, I just want to tell folks that are listening, if they're sending in their questions, we will get them and we will answer them. We'll ask Ken to answer them at some point here, either via e-mail or on the Web.
Let's see. In terms of where universities are going, then -- in terms of some of their next steps -- we've talked about the first applications and the importance of doing an inventory of directories. Ken, did you want to add anything more on the directories issue?
KK: Well, it always behooves us to mention Microsoft.
JB: Yeah.
KK: And I think NT5 is going to play a very important role on many campuses. (I think we have a TechTalk coming up on that.) In our work with Microsoft, we're really trying to understand how active directories work in this realm.
And I think there's a strategic decision that universities will need to make shortly about what is their primary directory structure. As I said earlier, there will be multiple directories, but is the core LDAP? Is the core active directories? Is the core X500? That's going to be a design decision reached probably early on in this process, and the decision will be made largely on the marketplace issues on a campus.
If you don't have NT today, then you don't have to worry about active directories. If you have a lot of NT, think long and hard about maybe you want to conserve your workforce and have active directories function as the core of your directory environment.
HS: Ken, a lot of this middleware stuff is something that lots of universities are going to be doing in common. Are there any attempts for people to share the stuff that they've done, middleware development that they've done?
KK: Let me give you two resources on that, Howard. The first is existent today, and it's a collection of materials from some Common Solutions workshops. And that can be found on the Common Solutions page at www.stonesoup.org. And then I would look for an initiative to be coming forward from Internet2 in the next few months.
Right now, at least, I refer to the initiative as the "Glue Factory" because, a) we're talking about glue, and b) the initiative is going to be very focused on delivering product associated with middleware, and that product may be intellectual property about what are the design schemas that you need to consider. The product may just as much be some applications that actually use this middleware. Wouldn't it be nice if we get a desktop video tool that works shrink-wrapped off of the middleware that we'll be developing in the next few months?
So I think that we hope to turn a corner within the next six months and begin to extract some of the wisdom that's happening at a few niche campuses around the world, and generalize those into practice-and-technology guidelines and convergent policy for most campuses. That's the goal.
HS: Why is that stuff coming from Internet2? That seems like an unusual place.
KK: Well, again, Internet2 was working on advanced applications and discovered that the applications were a lot easier than the management tools for the application. And so Internet2 is going to be stumped on continuing down the road of advanced applications without middleware being widely available to campuses to participate. So it's a sine qua non for Internet2 success.
HS: Are there some standards attempts also going on in middleware?
KK: I don't think in policy -- the policy dimension of middleware, that's happening right now. In the practice area, I guess I haven't seen a whole lot, either. In terms of the technologies, there are discussions, but there are no standards. One other activity that you'll see shortly is that --
[END OF SIDE A]�
--but like the beginning of this talk, it tries to map out what are the characteristics of middleware and which pieces belong where, and what elements of middleware depend upon other elements of middleware.
JB: So that'll be up on -- what's the URL for that one?
KK: Well, it'll ultimately join the RSC list that's maintained by numerous sites out there on the net.
HS: Where's the RSC coming from?
KK: NSF held a workshop in early December. NSF, Cisco and IBM all jointly sponsored a workshop in Chicago in December, and I'll put somebody on the spot who's a good friend, Bob Aiken. Bob, who works for Cisco, has been the guiding force for this middleware RSC, so I think that Bob will be a primary author on that. And do a search on Aiken in a couple of months, and that should come up with this.
JB: That sounds good. In terms of the Internet2 pages, is there some place there, too, that has some content on middleware that people would find helpful?
KK: Within weeks.
JB: Within weeks, so it's kind of a stay-tuned kind of topic here.
KK: Right.
JB: Okay. Let's see. We're coming close to the end here and probably want to go ahead and wrap up, Ken. Howard, did you have any final question for Ken at this point?
HS: No, I didn't. In fact, I'm out of poetry here!
JB: Oh, no!
HS: But I think that Ken has given us a couple views, actually, I think, of this elephant that we were looking at, and I hope it's been helpful to the people listening -- or at least more helpful than confusing.
JB: Well, I hope so, too, and I think the PowerPoint presentation that you have up there, Ken, that will be up there for a bit and I think that will give people a chance, at their leisure, to go ahead and take a look at that.
I'd like to thank everyone for being with us here today and to please send any follow-up questions also to expert@cren.net, and also then to mark your calendars for April 8, just two weeks from today. This TechTalk will feature Doug Van Howling, who is head of UCAID and who will provide us with an update on Internet2 network development. (I'm sure he may have something to say about middleware as well, Ken.) Plan on joining this session and also inviting your friends and colleagues, and check the Website for upcoming spring events.
Thanks to all who made this possible today: the board of CREN; our guest expert Ken Klingenstein; technology anchor Howard Strauss; Web content producer Terry Calhoun; and to Harold Ansell and Lee Perlis of CREN; Paul Bennett and Martha Vander Kolk at UM Web Services; and all of you for being here. You were here because it's time. Bye, Ken.
KK: Bye, Judith.
JB: Bye, Howard.
HS: Bye, Judith, bye, Ken.
JB: And bye, everyone out there in Webland.
