My name's Tom Goguen. I'm the Director of Server Software here at Apple in Worldwide Product Marketing. And I just want to welcome you all to this session. I'm only here briefly. Basically, what we wanted to do was to provide all of you with, essentially, the view or the perspective of third parties doing projects, enterprise-oriented projects, on Mac OS X and Mac OS X Server, and to give you that sort of perspective on what we're trying to do here. So I'm going to introduce a couple of gentlemen in a moment, and we'll talk a little bit about what they've been doing. And then they're going to spend the bulk of this time talking to you about what they've done on Mac OS X and Mac OS X Server.

So, enterprise applications in a heterogeneous environment. That's just too many syllables for me at this point along the line of the day, so we'll just skip through this one really quickly. So on our agenda today is going to be Infosys, and they're going to talk about enterprise IT architecture. They've got some customer scenarios and some great examples of things that they've done, some really good information around best practices, working with the products, and what they're doing.

And from Infosys, and I'm going to read from my notes here because I want to get this right, and I'm never great with names. We have Amit Seth, and Amit is the Senior Technical Architect at Infosys. And he's done a number of IT integration projects, and Amit's going to come up here in a moment and talk to you about what he's done and how he's done it and show you in depth on how he's pulled all of that together.

Following Amit, we have Steve Olson from Sybase. And I've known Steve for a while, actually. Once we started going down the Mac OS X server route, I got talking to him about bringing Sybase's enterprise class database server over onto Mac OS X server. And it's been a great relationship. Steve's the Technical Director for Sybase Engineering, and Steve actually was in charge of the Sybase port to Mac OS X server.

And if you've followed what Sybase has done, they literally are, in some ways, they're driving us. They've pushed us to do things that I think would be of interest to a lot of developers and a lot of IT people who are looking at using the platform. For example, Sybase has really done a lot of innovation around the management console and is taking advantages of some of the APIs that we're starting to make available in the management console for third parties to plug in their information into the management console.

So, we've been able to do a lot of things with the server admin. So, take a look at what they've done. It's really exciting stuff. They've helped push us in a number of other directions as well in terms of really, you know, helping us to make Mac OS X server really rock when it comes to databases.

And we've got some new technology going into Panther Server, things that, of course, people would generally just skip over very quickly in something like a keynote, but are of great interest to people like me. Things like AsyncIO going into Panther Server. Which will really, really help with database performance. So, first we're going to have Ahmed Seth come up and talk to you about Infosys and what they're doing there. And then Steve's going to come up and talk to you about Sybase. And after that, there should be a little bit of time for Q&A.

And let me just make sure I click this. This is kind of interesting what you will learn in this session. I always like that they put these slides in here. But basically what we want you to get out of this is we want you to have a chance to take a look at, you know, what third parties are doing, what people are doing with large enterprise class applications on the platform, how they're doing it, how they're doing it to meet the needs of your typical mixed client, mixed server enterprise environment, how they're deploying and using our technologies to do that.

So, I hope you take away a lot of that good information and get some great ideas about what you can do with your products and what you can do inside of your environments. So, without further ado, I'm going to hand it over to Ahmed. Thank you. Thank you, Seth. Without further ado, I'd like you all to provide a nice warm welcome to Ahmed Seth. Ahmed.

I'm Amit Seth, representing Infosys Technologies. Infosys is a leading systems integrator with more than 15,000 employees. In the last few years, Apple has been coming up with some really exciting products in the enterprise state. The XServe, Support for open source softwares, the OS 10 server version, This has really got us excited, and we have been developing some solutions. for the Using the Apple Technologies, which we wanted to share with you today.

In today's session on Enterprise Applications in a Heterogenious Environment, I'll be talking about From a system integrator's perspective, what does an enterprise IT architecture look like? What are the main components of this architecture? And I'll use some examples of applications that we developed for each of these components to showcase how we leveraged Apple's technologies in an enterprise heterogeneous environment to provide solutions for some common business problems. A few words about Infosys.

We have more than 15,000 employees, more than 370 clients. 35 offices in 15 countries, and we are still growing. We pioneered the global delivery model, and We have, our greatest strength has been our ability to deliver projects. 95% of the projects that we have delivered have been on time, on budget, or better.

We are financially a very, very strong company. Our financial strength has been growing year over year. Last year, we closed our fiscal year with net revenues over $750 million. We have cash reserves of over $235 million. We have partnered with some of the industry leaders, and most of our clients are in the Fortune 500 and Fortune 1000 companies. Let's move on to what is our perspective of an enterprise IT architecture.

It's slightly late on a Friday evening. I want to inject some life into this. Providing Some real good insights into why we are dividing this into these kinds of components. When we look at it, we are essentially looking at some eight different categories in an enterprise IT architecture. These categories are the thick client category, The business components. Business components are the reusable components which can be shared across multiple applications. Client access services, which include the application servers, streaming servers, web servers, and these are, this is essentially the layer between the clients and the server.

Application Security Services. These determine the authentication, the security, the user profiles. Enterprise APIs, the programmable interfaces, which allow data to be shared across multiple applications within an enterprise or over the Internet. Bus services allow computing in a distributed computing environment, include the domain name services, directory services, CORBA, COM, IIOP, Operating system provided services, which essentially include input/output services and network services. And the last category is the server hardware platform itself, which includes the processor hardware for the server.

So these were the eight categories that I spoke to you about. Let's move on to our first category, that is client solutions. Now in each of those eight categories that I was talking to you about, in this session, we'll touch upon some six of those categories. I'll be talking to you about a common business problem in each of this category.

A solution which we developed leveraging Apple's technologies to address that problem and how we were able to integrate that solution

Things like the transaction model, support for threaded transactions, conformity with the existing IT infrastructure and strategy for deployment and distribution are important when we need to consider solutions in this space.

Let's take a look at the implementation scenario for a particular solution that we developed in this space. The application is a mobile sales application. What was the customer situation in this case? The customer situation was that they had field sales representatives who already had Apple's PowerBooks. There were... They did not have any kind of an integration with the central CRM package, which was on a different platform, which had a different technology. They did not have an application to integrate from their PowerBooks to the central CRM database.

And the client was losing business. They were at a decision point whether we need to go in and buy a product from the market and go in and replace our Apple PowerBooks and provide people with laptops based on other technologies, or to continue with their carrying the Apple's PowerBooks and develop some kind of a solution which allows them to leverage the central CRM database that already exists within the organization.

We identified the business drivers for the solution that needs to be developed, in this case, as an application that can allow better collaboration between the sales teams, and which essentially allows that the solution that the sales representatives are going to use to integrate data with the central CRM, enabling better reporting, better decision making for the senior management.

The solution that we proposed was an offline solution that can run on a Macintosh, because these are field salespeople, they're moving around. And the ability for this solution to integrate with the central CRM database. Why did we go in for Apple, the biggest driver? They already had Apple's Power Books. Also, Objective-C and CoQA allowed us to rapidly develop an application to be used by the sales representatives in this company.

We developed a complete three-tier solution to run on their PowerBooks. We had a client built of Objective-C and CoQua. CoQua using Objective-C. A server, custom server written in Java. And we took an open source database, that is PostgreSQL database, and installed it on their machines. Then we wrote some custom classes to allow them To allow this local server, the local Java server running on their machines, to exchange data over socket connections with a server running against the central CRM database.

This essentially allowed will be presenting the first session of the session, Data Synchronization between their local databases and the central CRM database. Let's look at the details of the technical implementation. So what you see on this side is what was already existing. This was their central CRM database hosted in a data center within their organization.

What we developed was a three-tiered solution. We were looking at the choice of databases. The client wanted a... Cost-effective way to install database. It was a database to be used for a single person on a PowerBook and We looked at the open source databases that were available. The two databases that we zeroed in on were MySQL and PostgreSQL. We selected PostgreSQL based upon the fact that it had better support for transactions. You could do rollbacks, you could write functions.

And at the time when we developed the solution, PostgreSQL was the only database, open source database, which was truly Unicode compatible, when we compared MySQL to this. MySQL, at that time, you could have a Japanese version, you could have a Western European version, but nothing which allowed you to support everything. I believe the latest version of MySQL does support Unicode.

So this was our implementation. The server was communicating with a server within the data center. And that server was essentially dealing with the database, was sending in transactions against the database. The solution enabled us to To prove that on an OS X PowerBook, you can essentially have all the three components required for an application. The client, the server, and the database all running together. And it's been a stable application. It's been one of our good implementations.

Let's move on to our second category, that's the business components. When we talk about the business components, we are talking about reusable components which can be shared across multiple applications. When we talk about components that can be shared across multiple applications, the things, the major considerations in this case are what kind of functions and services do these components offer? What kind of interfaces are available? Those have to be standard interfaces to be implemented across applications. The development and deployment of these components have to be independent of the applications with which they are being linked with.

Let's take a look at a typical implementation scenario for this component. The implementation scenario for this component is an automated fax-integrated application. It's a very easy solution, a very simple solution, but resolved a big business problem. When we came in, we saw that the customer situation was, it was a large organization with a lot of employees. are different geographic locations who essentially use to submit their expense bills for reimbursements.

They had to fill in a form which was being driven by an application. They used to fill in, "I spent so many dollars in traveling, I spent so many dollars in food, I spent so many dollars in business expenses." Submit that form. And then the original bills had to be mailed to a back office, where someone used to look at those bills, relate it to who submitted it, Checkmark on that form, yes, this is correct. And then approve the request.

This was a manual, resource-intensive process in that organization, and it was becoming a big overhead for them. So they were essentially looking around for a solution that allows them to automate this task. The solution that we proposed was the electronic submission of bills along with their expense details.

What made us select Apple in this case? What made us select Apple in this case was, one, it was a low-cost solution. It was easy to monitor and maintain. and it was extremely easy to integrate this in the existing infrastructure. We'll take a look into the technical details of how we did this.

What we did was, we took the open source package EFAX, compiled it on OS X. We also took ImageMagick, compiled that on OS X. Actually, OS X versions are already available on the net for ImageMagick. eFax allows us to receive fax messages. The process that we defined was that an employee prints out the expense bill form from whatever they submitted. That expense will form, has a barcode printed on top of it.

They then take the original bills and this form and fax all of them together. That fax is received by the electronics, the e-fax. And it uses ImageMagick to convert that TIFF file to a GIF format. Tiff-to-GIF conversion was required for a barcode reader, which they already had within their organization, a software which could essentially read the barcodes. And then we wrote a small custom component which allowed us to submit those forms against those electronic bills, the copies of those electronic bills, against the actual form within the application.

Now, normally, This kind of a solution would have entailed going in for a small server, for a small platform,

They came up with a few other things where they were submitting copies of the original documents electronically. They wanted those to be submitted electronically. And this solution allowed us to do that because essentially that barcode that we were printing on it was a tag which allowed us to route it to any kind of an application, to associate it anywhere.

We implemented it for one application, but we left the architecture open for them to go in and implement it later on with any other application that they wanted to. Again, in this case, the only component that we brought in was and XServe with the electronic facts, image magic, installed on it and just plugged it into their existing IT architecture.

Let's move on to our third component. That's the client access services. Client access services are essentially the layer between the client and the server. The common implementations like web servers, streaming servers, Enterprise Application Servers, where it's Enterprise Application Servers, but with the trend that's going on in the industry, it may change to Enterprise Java Application Servers. It's still not Enterprise Java Application Servers, though.

An implementation scenario where we went in and implemented a solution in this category.

What was the client situation in this case? The client situation was that the client had A very, very big, it was a big corporation. They had more than 10,000 employees, and they had a central human resources application. That could be used by the employees on their workstations to do all the HR-related things. Writing reviews, managers used to write reviews, employees used to submit their leave applications. That was essentially the central HR application within that organization.

And they had a problem that, because this was based on the workstation, Employees could not use it while they were traveling or while they did not have access to the workstations in their offices. So they wanted a way to access this information anytime, anywhere.

Also, another driver in this case, like in any organization where we go,

They had been using a lot of custom code in the database.

So it did not allow you to go in and build something on top of the database directly. So you could not go in and build a web application and go in and interface with the database directly. That was an issue in this case. That is why the problem was not as simple as just writing a simple web interface to a database.

Why did we go in for Apple in this case? We went in for Apple's technologies was because WebObjects on OS X provides us with an excellent platform to go in and build Web-based applications. It's also a very cost-effective way and allows us to develop applications very rapidly. The architecture that we implemented and the solution that we provided allowed us to reuse most of the existing components within this application.

This is what we did. So on your right side, you are looking at-- The way the application used to exist within their environment. They had an enterprise HR database, and they had their custom server, which was interfacing with this database. The custom server did have APIs defined to go in and access data, That was it. I mean, you couldn't do too much.

Our own framework, which we compiled with the WebObjects code, which allowed us to interface with those APIs and provided a layer between the custom server and the WebObjects server. So the WebObjects server was communicating with the custom server in this environment.

was a very, we could develop this really fast, and it allowed us and I are here today to build a very cost-effective solution. We deployed the entire thing on an exerf, a single exerf, The solution is being used as and when the employees in this company travel outside, as and when the employees want to access it from the web. More than 10,000 employees are using this kind of a solution.

Between applications in the same organization or over the internet, Major considerations when we have to go in and provide a solution using enterprise APIs are: We have to consider object persistence. We have to consider the transaction services. Transaction services is essentially the core. The Data Access Models and the Data Distribution Services. Let's take a look at a common implementation scenario in this space.

The application that we developed in this space was a call center application. The client situation when we went in was that the client was losing business because of the lack of a call center solution. The current way in which they were tracking calls was they used to receive calls. They had a very, very rudimentary way of going in and entering it into a database. They did have a proper database, but the way they were using that database was in a very, very rudimentary fashion.

And it initially started with the client being a small-time company, and they grew up rapidly in the space of a few years. So the model that they used initially just could not scale up to the kind of requirements that they had in a few years' time. The business problem that they were facing was that they were losing customers because of their inability to respond back to their calls on time. And they wanted to address this.

The solution that we proposed was a low-cost solution With an ability to support high transaction volumes that were required, the ability to scale up even further as this company grew up, and the ability for this solution to integrate with multiple data sources. Why did we think Apple is the best solution in this case? Apple was the best solution in this case because it provided us with a server optimized version of Java. A low-cost enterprise application deployment alternative with XServe OS X Server and with JBoss compiled on that.

Support for open source technologies like JBoss, where essentially the, The deciding factors in moving towards this kind of a solution. Let's take a look at the implementation of how we went in and what we did. So on the right side, you're looking at what is colored in orange is your existing components that were already existing within this enterprise. These were the database.

With data inside it, which was still meaningful, but just that it could not really be used or it could not really be leveraged off given their current solution. They had some reporting applications on Windows, which used to go in directly against that database. to come up with some kinds of reports.

Again, their reporting requirements had grown over time and they were trying to figure out how to enhance their reporting solutions to come up with a... to come up with a model where they can have better reporting and better call tracking, and allowing the management to take speedy decisions.

On your left side is what you're looking at, the solution that we implemented. What we implemented was, we took Some EJB components, prebuilt EJB components, open source components which are available. We wrote some of our own. Use JBoss on OS X to host these Our custom components allowed us interfacing with the current reporting applications, whatever they had.

It also interfaced with the database. We wrote some more components to provide interfaces for even more reporting application as were being required. And, made the entire solution such that it could scale up with the growth of this company. So essentially, putting in this kind of a middle layer of EJB components on an XSERV allowed us to use the existing reporting applications, the existing database,

I'll move on to our next category, which is operating system services.

From our perspective, hold solutions in the storage and in the distributed computing environment space. Storage falls also under the server platform stage, but in our classification, we have classified it under the operating system services space. The major considerations that we as solutions providers have when we start looking at solutions in this space are: Is the solution really interoperable? Interoperability is a key in this component. What kind of scalability does the solution offer? What kind of a performance does the solution offer? What kind of a security is offered by the solution that we have to develop in this layer? Let's take a look at a typical implementation scenario in this case.

We had this organization where there were multiple clients on different platforms. They wanted to share files across platforms, and these were large-sized files. These were very large-sized files. This was a geographically dispersed organization with offices in multiple countries across the globe. Considerations like sending files over wide area network repeatedly was an issue, a resource drainage issue. Considerations like the ability to make the large size files available to the persons on time were a big issue.

They also wanted a low-cost file storage solution along with it, because the files that were being, essentially the solution that they were looking for was, I put the file in your system, there are a set of business rules, the file gets stored, and it also gets distributed to multiple locations, wherever the other users are who have subscribed to this kind of a file. The subscription is being determined by the business rules which are built into the application. So let's take a look at the implementation scenario in this case.

The solution that we proposed was a low-cost storage solution. The client also had an issue with insufficient rack space in their data center. So the solution that we proposed was a rack space friendly solution. We provided a solution that could be dovetailed with their existing IT infrastructure. Why did we think Apple is the best solution in this case? Apple with Mac OS X server, with Mac OS X, with OS X server, essentially allows you To support multiple kinds of file protocols. Also, XServe provides the lowest cost storage in the industry.

And that is on the disk, on the server disk. And the fact that XServe is also one of the most rack-friendly servers in the 1U category. So what did we develop? Our technology implementation in this case was, we essentially went in and installed XSERVs at those multiple locations. The initial solution that we provided, we actually provided the solution in two phases. The initial solution that we provided was to go in and install XSERVs at multiple locations.

To actually go in and do NFS mounts from the XRFs and add in files. This was done because the first solution that they wanted and the initial solution that they wanted was essentially to leverage had to be built in a very quick timeframe in a really tight, on really tight deadlines. But what was common to the solution was that it allowed files to be stored, to be transferred, between these multiple XSERVs over TCP/IP protocol, Over-socket Connections. So, based upon the business rule, files were transferred from one XSERV to the other.

What this allowed was, one, a large-size file only had to make one trip over the wide area network to cater to as many downloads as are required by the users at a particular location. It allowed storage of files at each of these locations, and also the fact that downloads from the local servers were always faster as compared to downloads over the wide area network. The second phase of the solution, we did away with the NFS mounting of that, because that was not a scalable model. That was a temporary solution that we had to provide.

And then, that is when we went in for essentially a small layer, which could be installed on each of these clients as add the file layer, which...

and were then being distributed in this kind of an environment. This is one solution where we essentially leverage the low-cost storage provided by XSERVs and the XSERVs ability to be installed as a rack-free server in their data centers.

Let's take a look at some of our best practices when we go in and implement solutions. Like any systems integrator, we are strongly focused on using tools. Our best practice is that we have got a dedicated team which just works on identifying tools,

Debugging frameworks which allow us to do a lot of debugging with a Java application. Tools which allow us to do distribution of software on Macintosh. There are times when there are some challenges. We have developed some tools which allow us to do that.

We also have well-defined processes and methodologies for software delivery. When we talk about software delivery, we essentially have processes falling into three different categories. These categories are whether it's a custom system integration, whether it's a solutions systems integration, or is this an infrastructure systems integration. These are the three main categories. And our processes differ slightly for each one of these. What is common to all our processes and the core set of processes that we have developed around all these three are pertaining to technology change management.

Technology change management is implemented in three stages: the planning stage, the analysis stage, and the deployment stage. In the planning stage, we go in, we study, just as I was presenting, we go in and we study what is the solution that is required. What are the business drivers for this solution? What kind of a cost? Cost limit is there to the solution that needs to be provided.

What are the different parameters like scalability, etc., that have to be considered to use the solution? We then move into the evaluation phase, where we start evaluating the different solutions against these parameters that we have collected. Do we need to go in for some kind of a pre-built package, pre-built software? Do we have to go in and develop a customized solution? Can we just modify the existing solutions that already exist in an enterprise to resolve most of the common problems that are surfacing today? And then, the last stage is the deployment stage, where we start considering things like How maintainable will this solution be? How easily deployable is this solution? What are the kind of training requirements that will be required in this case? Can we plug in this kind of a solution into the existing enterprise architecture? So those are some of our common considerations and the best practices. We have built our best practices around these to really fine-hone these processes. Thanks.

My name is Steve Olson. I'm a director of engineering at Sybase. I promise you I won't be talking about Oracle on Solaris or Oracle on AIX. I'll be talking about Sybase on Mac OS X. Before I do that, I'd like to ask you, is anybody here a current Sybase customer right now? That's pretty much what I thought. We decided last year to move our product line, some of it, into the Mac OS X environment.

And we realized that we are strangers to the Apple community, the community of Apple users. We live in different worlds, or have been. So I thought we'd take a few moments here to introduce a little bit about what Sybase is. And then, after a couple of minutes, talk about our database software that we've moved over to the platform.

They made me put these slides in here. So who are we? Sybase started in 1984, about the same time of the Super Bowl commercial that Apple produced. And since then, we have expanded. The first few customers that we had were in Wall Street. Wall Street folks needed an online transaction processing engine that would handle stock trades. And they've stuck with Sybase through all these years, and right now about 60% of stock trades in Wall Street, E-Trade, and others are processed through Sybase servers. We have a very strong presence in the financial services community, banks, and so forth.

Healthcare, telecommunications, and both state and local governments, as well as federal governments, are also strong customers of ours. So the point I'd like to make here is that... The same code line, this code that has evolved since approximately 1984, is what we've moved over to the Mac. The same code that is used by our most demanding customers. What we've done is not provided you with Sybase Lite. It's an industrial strength online transaction processing engine for Mac OS X. And our software is localized for all of the major languages of the world. So we've deployed in just about every country on the planet.

What's available today is our Adaptive Server Enterprise version 12.5.03. Just this week, we've announced the availability of Adaptive Server Anywhere version 8-something, and a number of APIs, JDBC, ODBC, and our open client APIs, and our open server product. That's available right now. Most of this is available as a free developer edition download code from our website at sybase.com/mac. Later this year, we will be releasing our replication server, and for those of you who may not know what that is, think iSync for business. It's basically bidirectional synchronization between databases that may be either enterprise databases, laptop databases, or Palm Pilot databases.

And also the Adaptive Server Enterprise 12.5.1 will be available later this year. We are tying that to the availability of Panther. So although we will be ready in approximately September, we're not sure exactly yet when Panther will be available. So whenever that happens, whichever comes first, I guess. And then also later on, Adaptive Server Anywhere version 9 will be generally available on Mac OS ASE was first released in 1987, optimized for online transaction processing, and we licensed it to Microsoft in 1988.

Microsoft took the source code, the whole package, and for a long time marketed it as the Microsoft SQL Server. And then we parted company with Microsoft approximately 1997, and since then our two product lines have evolved in different directions. They even got our name. They have very good lawyers, and that's about all I can say about that.

But anyway... We now call our product the Adaptive Server Enterprise, but because of this common heritage, there still remains a very high degree of compatibility between the two. So applications generally written for a SQL server should have little problem, maybe some, but because of the evolution of the product lines, but there's still a high degree of compatibility that will allow you to move your application to Adaptive Server Enterprise on Mac OS X, if you might have an interest in getting rid of the SQL server. It's a SQL database. We are SQL 92 compliant at entry level, and we've also got a number of extensions in the Transact SQL language.

When we decided to do this port to Mac OS X, we took a long hard look at the Unix underneath the covers. The first Unix port that we ever did was with Sun OS back in the mid-80s, and that was essentially Berkeley Unix. So what we found with Mac OS X is an old friend in a new coat.

Berkeley Unix is very, very familiar to us, and the engine and the basic database components themselves moved over to Berkeley Unix very, very quickly. So we looked then at, well, what else can we do to tie in more tightly and integrate with some of the services provided on the Mac OS X platform? We looked at Rendezvous, the SNMP agent, Open Directory, the server monitor itself, and then the install. I'm not going to say much more about the install, except that we have a lot of information on the Mac OS X platform.

We use Apple's Package Maker, which provides you a command line install facility on headless X-serves, as well as a nice GUI installation for monitored servers. So a little bit about this architecture. The engines depicted here essentially equate to Unix processes. Engine 0 listens for client connections and dispatches to some engine based on load.

We associate an engine with a CPU, meaning if you've got a dual CPU system, you can configure two engines. Each engine is threaded so that you can allow up to, on the Mac, each engine can handle about 1,000 connections. So a total of about 2,000 users can connect to this system at the same time.

If you've got two CPUs. We use shared memory. We looked at memory map files versus the System 5 APIs for shared memory and have so far adopted the memmap as the interface to create the shared memory region. So essentially the environment we found in Mac OS X was something very, very familiar to us and very compatible with our prior implementations on Unix systems. So we're very, very pleased about that. And like I said, it came together very quickly. Within about two months we were ready for an early adopter program. And within four months we had a general release available in September of last year.

We used Rendezvous for a number of reasons. First of all, we wanted the server to come up and register with Rendezvous so that a discovery client could recognize where the servers are in your network, or in the case of the current implementation, your subnetwork, and allow a client to automatically discover where they were, get every bit of information needed in order to establish a session with that server. So that's why we did it, and it only took about 10-15 lines of code, if you count the comments. It was a very simple thing for us to do.

And we also provide a discovery program on the, it's a Cocoa-based application that uses Rendezvous discovery APIs and allows us to take a look at all of the servers running in a network. So in this screenshot came from our QA lab, and we have both the database server itself, plus some auxiliary servers that we use for backup and other purposes. So they're all Rendezvous enabled, and the discovery tool allows us to take a look at everything that's running in the server.

And in this model, or in this screenshot, the highlighted server here has its host name and port number showing up in the upper left corner. And you type in a name and a password and hit the query button, and we'll launch a query tool that will allow you to interact with SQL languages and view the result sets and so forth. Sort of an interactive SQL utility.

That interactive part is available, or will be available, in our 12.5.1 release. In terms of SNMP, does anyone here use SNMP in your organization at all? A few of you? Apple provided an SNMP agent on their server that came from NetSNMP, which is another open source project. The version provided with Jaguar was NetSNMP version 4. something, and we found that it had some problems with the AgentX protocol. The AgentX protocol is a means by which you can extend the SNMP master agent.

So we have taken that model and provided our own SNMP sub-agent that allows us to monitor and view what's going on with the various servers that we provide. Our adaptive server database, backup servers, and so forth. And so if you have an SNMP console from HP, OpenView, BMC Patrol, Tivoli, or the CA product, you can view what's going on in the database. And also the server state changes generate traps.

So if you have a trap handling enabled in your console, you can be notified and configure it to alert you through email or paging or whatever you require when a server might go down or a system might crash. So that facility is enabled. We provide version 5.1 of the NetSNMP agent.

And I believe in Panther, that's what's provided in the box. So we won't be providing our own SNMP agent with our distribution. We provide two MIBs with the SNMP sub-agent. The standard RDBMS MIB, and then we have a Sybase MIB that extends that to give you a great deal more information about the state of the running server.

This open directory authentication is new in the 12.5.1 release, but prior to this implementation, when you log into our server, you provide a name and a password, or if you're using SSL, a name and a certificate, and we do the authentication entirely within our database. So, for the most part, people use names and passwords, and our database manages those passwords in our system catalogs.

With this implementation, you no longer have to worry about the password situation. We will use directory-native authentication via the open directory APIs to talk to open directory and use their authentication services to authenticate a login. Now, we've learned a lot in the past week about single sign-on and Kerberos and what Apple's doing.

And we hope that by the time this is released in the September timeframe, that we will be able to achieve single sign-on capabilities. But I can't commit to that right now. That's our plan. We'll see how it goes. Does anybody here use NIS for Yellow Pages? Most of you use LDAP or Kerberos Active Directory.

Okay. Monitoring and configuration. Apple has produced a very interesting monitor or server admin tool in the Panther. It's extensible. It provides a Cocoa framework that allows a client plug-in and a server-side plug-in to monitor and manage a facility or a service running on a Mac OS X server. So we were able to work with Apple and they provided us with examples of how to do that and have provided a monitor or an admin component for this tool that plugs into this tool. So with this component, we'll allow you to start and stop the server, to backup and restore databases, to reconfigure it, and to monitor the behavior of a running system through various graphical reports.

So in this case, CPU usage, but we also expect to provide graphs over time of disk I/O, network I/O, max number of users connected, and so forth. Basically to let you track what's going on inside the server. So we're very enthused about this. It's been a sore point with a lot of customers because it's been difficult to get this kind of user interface on other platforms. Apple understands these interfaces very well. And we're very happy that we're able to take advantage of the look and feel and the usability enabled by this tool. So this will be available in our 12.5.1 release.

And the title of this session is Applications in a Heterogeneous World. And I wanted to just talk for a moment about how the adaptive server enterprise is able to coexist with other database systems that might be in your enterprise. We have an interface within our adaptive server enterprise called Omni, or Component Integration Services. And what it does is allows you to set up tables, we call them proxy tables, which serve the role as pointers to data that lives elsewhere.

So with standard SQL, you're able to query these tables as if they were all local. And they might point to Oracle, they might point to SQL Server, they might point to DB2. And when I say DB2, I mean the world of IBM, which might be on the mainframe, VSAM, IMS, database, and so forth.

And, of course, other Sybase servers are configured. So if you've got Sybase elsewhere in your enterprise, you basically have a federated architecture that allows you to have a database that's able to do all of that. So that allows you to have a single view presented to your client applications.

A replication server has been a very successful product of ours. This came out, was first available in cooperation with a significant customer of ours, Goldman Sachs. And it allows us to publish database changes from the adaptive server enterprise to a subscribing server. Maybe another adaptive server enterprise, maybe Oracle, whoever it may be.

So, the reasons, I mean, we initially did this simply to allow customers to distribute data, to aggregate data. But lately, I would say about 70% of our customers now use it for warm standby. You can set it up to basically replicate an entire database to a warm standby server, so that if your site goes down for any reason, you still have this warm standby. So, the main benefits here are that we're not restricted by geography. We're restricted by the reach of your WAN or your local area network. And we replicate transactions. We don't replicate any disk files or anything like that. It's transactions that are replicated.

So, in a failover scenario, for example, in a disaster recovery scenario, your clients may find that they're no longer able to connect to your primary site. We have client-side failover built into our client APIs that allow them to be redirected to a secondary data center. And this mechanism was used by a number of our customers who had data centers at the World Trade Center in September 11th, and those that chose to were back online in a matter of minutes.

I mean, they had other things on their mind that day, so it sounds bad that they were able to get back up within days, but in fact, there were human considerations there more than technical consideration. Those that chose to were able to get back online in a matter of minutes.

Through this technology. And this has been used by a number of customers for disaster recovery scenarios, for dealing with unplanned downtime, somebody trips over a power cable, or planned downtime, you want to take your systems down for maintenance, upgrade, whatever the case may be. In a warm standby scenario, your applications talk to your primary server.

Replication is being done for the entire contents of that server to a standby server. And the replication model is one of store and forward. So the transactions or changes are stored in a queue on the replication server and then propagated to the standby when they're committed. We don't propagate halfway committed changes, only those transactions that are committed.

If for some reason the primary fails, client-side failover mechanisms automatically direct the client to the secondary site. And the rep server can be told, has to be told, to change the direction of replication. And when that happens, the standby then becomes the primary and the direction of the replication is switched and the changes on the secondary are stored in a queue until the primary becomes... available. And then when the primary does become available, the two are synchronized and normal operation then can resume.

So that's a standard way that the rep server is used in a lot of customer situations.

The rep agent then will take these changes, queue them, and when the transactions commit, replicate to various targets. And that could be Oracle, it could be Informix, DB2, or whatever.

We provide our own JDBC drivers. It's a Type 4 all-Java driver. And we also offer the Mac platform. We licensed an ODBC driver from Open Link. It's ODBC 3.5 compliant. We provide our own open client APIs, which are roughly equivalent to Oracle OCI. There. And we have an open server.

An open server is an API, a library, that allows you to write the server side of the open client interface, so that you can provide handlers for language, RPCs, and so forth, in a threaded server environment. Essentially, this was built in 1990, carried forward, and it was a precursor to application servers. But you can do everything in C, C++. You can get very high-speed performance out of this server engine.

A number of tools for development purposes are available on this platform and some solutions. The tools that are provided, the WebObjects plugin is available. Apple Engineering produced a plugin for WebObjects that uses our JDBC driver, and it's been widely used now by a number of vendors to produce solutions. We have provided a real basic plugin for the real basic product. Version 5.1 now is available and it has a plugin that we've provided that's been very well received by the RealSoft folks.

Runtime Labs has provided support for our servers, our interfaces, using their framework, which allows you to use the interface builder to create database-driven applications. It's a very nice tool. Blue World has provided ASE support. There's a number of additional third parties that provide tools, to enable you to build either client server applications or web-based applications. And of course the JDBC driver can be used in a JBoss environment if you want to build EJBs that deal with databases.

In terms of solutions, Power Easy I'll be talking about a little bit later, and the same with Inovion. RiskWise was mentioned earlier this week as an interesting customer. They're a credit bureau and they have over 200 XSERVs. They have custom-built software to handle their particular application, but it's powered by Sybase underneath all that middleware that they have built. Quadbase is a good partner of ours. They provide a reporting solution for our products.

The TOLUS group can be used to backup to tape, from file system to tape. And so when we backup files in our backup databases, we write them to the file system and the TOLUS group BRU utility can be used to then back them up to tape if need be.

LiveTime is another partner, and MindWrap is a very interesting web content management partner. And I understand there's a person from MindWrap here. Can you stand up? Maybe not. There he is. Okay. All right. So anyway, once again, migrating from SQL Server to ASE, we provide some tools. To make that possible, to migrate both the schema and the data from SQL Server to ASE. This one tool is provided by a company called Schema Research. It's called SR Migrate.

And then Sybase provides a tool. It's called Power Designer. And it has been extended with a transfer plug-in to allow you to import the schema from just about any data source, build a data model, and then push that model to ASE. With the transfer plug-in, you can then take the data represented by that source server and transfer it into ASE using our bulk transfer facilities. Very high speed. So it's... We're trying to make it as easy as possible to do this.

I have three case studies I'll go through fairly quickly here. Power Easy, Inovion, and Schema Research. Power Easy has built an ERP application, which is all Mac OS X using Sybase and WebObjects. They provide four packages for e-commerce, logistics, financials, and sales, and a whole host of reporting facilities using the Quadbase services.

Their environment is basically browser-based. The application is a browser-based application. It uses Apache web server on the Mac OS X server and web objects and the adaptive server enterprise. They provide the total package. So, XSERVs, Apache, it's a complete unit. Plug it in, turn it on, and it's ready to go.

Inovion is a, this is a very big title, a very hard word to pronounce, but what it boils down to is these folks take pictures of your eyeball and your retina and analyze them to detect diabetes and other potential problems with your eye. And their tests are 90% accurate, which is greater than a physician exam, they claim, and it's a very interesting application.

The... It's a startup operation they expect to deploy in about 500 sites in North America. And they have a workflow agent on each site that captures the data from a very high resolution camera and also data that's keyed in for that particular patient when the retinal scans are done. That workflow agent transmits through RMI to a server in a workflow scenario. The server stores the information on a queue, which is a Sybase table or tables.

And then a workflow process occurs where various physicians may review the information that's presented to them and add some notes and so forth. And then finally a diagnosis is made through a series of steps. A highly innovative application and who knows? It looks like it's going to be able to do some good.

So Schema Research is a consulting firm. They also have some products. I mentioned SR Migrate, but they helped us with the implementation of a facility to assist a manufacturing operation with the running of their factory. The solution consisted of the Adaptive Server Enterprise, Replication Server, RAID, and ASE Mirrors. One of the features of ASE is it will do mirroring as well.

They are very highly reliant upon this application for running their factories, so downtime is of serious concern to them. In fact, we displaced the incumbent database, which was problematic because it could not guarantee the degree of uptime required for this particular application. They are very pleased about the solution. It's another WebObjects application, browser-based, using ASE as their primary data store. They also have two off-site standby servers in case of disaster. They also have a warm standby on the same site in case the particular computer in which ASE is running happens to die.

And they also replicate various database changes in their running site to their development environment so that their application developers have some live data to test with and to implement new features. So this customer is very pleased with the results. They've been running their factory now for about three months using this configuration.

So to conclude, I just wanted to point out that Sybase is committed to this platform. The same software that we've used, that our most demanding customers use to run their business is now available to you on Mac OS X. And we're also focusing on additional services Apple is providing this platform to integrate our database with to give you the greatest level of integration possible on this platform.

We're also working with a number of third-party tool and application developers to provide a more complete solution for you. And we are also trying to make it possible for you to eliminate any dependency you might have on SQL servers so you can have an all-Mac solution in your enterprise. Developer's Edition download is available from our website at sybase.com/mac. Check it out.

Okay, you can contact me, any of our salespeople. Daryl Salas is a systems consultant. Michael Haynes, I believe he's here, is a business developer at Sybase. I mentioned the download site. All of our documentation is also online. You can go there. We don't provide hard copy of our manuals with our CDs for the Mac. And of course, the Rendezvous, SNMP, and Open Directory websites are available to you as well.