CapeConnect Three. Concepts

CapeConnect Three Concepts

CapeConnect Three Concepts (October 2001) Copyright 1999 2001 Cape Clear Software Ltd., including this documentation, all demonstrations, and all software. All rights reserved. The document is not intended for production and is furnished as is without warranty of any kind. All warranties on this document are hereby disclaimed including the warranties of merchantability and fitness for a particular purpose. Trademarks Cape Clear, Cape Clear Software, CapeConnect, and CapeStudio are trademarks of Cape Clear Software Ltd. in the United States and other countries. Microsoft, Windows, Windows NT, the Windows logo, and IIS are trademarks or registered trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Sun, Solaris, iplanet, Java, Enterprise JavaBeans, EJB, J2EE, and all Java-based trademarks or logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. BEA is a registered trademark of BEA Systems, Inc. WebLogic, WebLogic Server, and WebLogic Enterprise are trademarks of BEA Systems, Inc. IBM and WebSphere are registered trademarks of IBM Corporation. IONA and Orbix 2000 are trademarks of IONA Technologies. Borland and VisiBroker are registered trademarks of Borland Software Corporation. This product includes ipp Preprocessor technology, which is licensed from Servertec. ipp and the ipp logo are trademarks or registered trademarks of Servertec. Other company, product, and service names mentioned in this document may be trademarks or service marks of others. CPC-DOC-015

Contents Preface Who Should Read This Manual Related Documents Conventions Used in This Manual Accessing Publications Online Providing Feedback about Publications Contacting Customer Support v vi vi vii viii viii viii Chapter 1 Understanding Web Services 1 Overview of Web Services 2 The Benefits of Web Services 4 How Web Services Work 6 Universal Description, Discovery, and Integration (UDDI) 7 Web Services Description Language (WSDL) 7 Simple Object Access Protocol (SOAP) 8 Other Relevant Technologies 8 CapeConnect and Web Services 9 Creating and Using Web Services with CapeConnect 9 Creating Web Service Applications with CapeStudio 10 Combining CapeStudio and CapeConnect 10 Summary 12 Chapter 2 Creating Web Services with CapeConnect 13 The Role of CapeConnect 14 Overview of CapeConnect 15 Overview of the Architecture 15 CapeConnect APIs 17 Summary 19 Glossary 21 Index 37 iii

Contents iv

Preface CapeConnect is a Web Services Platform that enables XML-based applications, SOAP, Java objects, CORBA objects, and Enterprise JavaBeans (EJB) middleware components to be united around a common, standards-based, XML model while, at the same time, providing the quality of service required to build enterprise-class systems. CapeConnect automatically creates Web services from new and existing components without the need to write custom or proprietary code. CapeConnect then makes these services available over the Internet using SOAP and HTTP. Using CapeConnect, organizations can extend the business logic and services embedded in server-side software to individuals and organizations across the Internet. This manual explains the concepts and technologies behind Web services and CapeConnect. v

Preface Who Should Read This Manual This manual is targeted at three types of users, each of whom is responsible for certain tasks: Web services architects, who design and build Web services with server-side Java, EJB, and CORBA components. Application developers, who maintain server-side Java, EJB, and CORBA components and develop SOAP clients to integrate external applications with the CapeConnect infrastructure. System administrators, who deploy CapeConnect applications and manage these applications as they run. Related Documents This section describes companion documentation to this book. CapeConnect Reference and CapeConnect Release Notes are available only as PDF and HTML files, not as printed manuals. These documents are stored in the docs subdirectory in your CapeConnect installation directory. Information regarding installing and setting up CapeConnect, as well as integrating with other application servers, is available in the following document: CapeConnect Getting Started Instructions on how to use CapeConnect are available in the following document: CapeConnect User s Guide Reference material for CapeConnect is available in the following online document: CapeConnect Reference Additional, late-breaking information on CapeConnect is contained in the following online document: CapeConnect Release Notes vi

Preface Conventions Used in This Manual This manual uses several typeface conventions for special terms and actions. These conventions have the following meaning: Bold Names of objects in procedures that you type, select, or click, as well as screen elements in a graphical user interface, appear like this, in bold. Italics Variables, new terms, and values that you must provide appear like this, in italics. Words and phrases that are emphasized also appear like this, in italics. Monospace Lowercase or mixed-case commands, command options in a syntax statement, code examples, output, system messages, and information that you must use literally appear like this, in a monospace font. This book uses special formatting and a world icon in the margin to indicate a real-world scenario that illustrates the concepts being discussed. The following is an example of this convention. This text describes a real-world scenario or example. Throughout this book, forward slashes (/) are used to indicate directories in file and folder paths. If you are running CapeConnect on Windows, replace these with backward slashes (\). Each chapter in this book concludes with a summary which reviews the chapter s key points. vii

Preface Accessing Publications Online The Cape Clear technical support Web site (http://www.capeclear.com/support) offers a guide to support services, frequently asked questions (FAQs), and technical information, including release notes, user s guides, and white papers. Most technical information is available in PDF and HTML formats. Providing Feedback about Publications We are very interested in hearing about your experience with CapeConnect. If you have any comments or suggestions about our documentation, contact us by sending e-mail to documentation@capeclear.com. Contacting Customer Support If you need support for this Cape Clear product, access Cape Clear customer support in one of the following ways: Refer to the Web site at http://www.capeclear.com/support for customer support information. For technical support requests, send e-mail to support@capeclear.com. viii

Understanding Web Services 1 This chapter introduces Web services technologies and how they work together to create a Web services architecture. This chapter covers the following topics: Overview of Web Services The Benefits of Web Services How Web Services Work CapeConnect and Web Services 1

Chapter 1, Understanding Web Services Overview of Web Services Before Web services, Internet computing and e-commerce was based on the exchange of information through presentation. Developers began with a presentational markup language (HTML), and then chose a particular technology (for example, JavaScript, common gateway interface (CGI), or ActiveX) to create applications for the Web. Because of the limitations of HTML and the Web-based technologies, these applications could rarely interact. The introduction of Extensible Markup Language (XML) enabled developers to separate the content of data exposed over the Web from its presentation. A predefined markup language like HTML defines a way to describe information in one specific class of documents. XML, on the other hand, lets you define your own customized markup languages for different classes of documents. This means that data can be easily exchanged, not only among humans through Internet browsers, but also among computers. Additionally, because XML has been widely accepted as the universal language of choice for exchanging information over the Web and is a public format, that is, not the proprietary product of any company, individuals can develop standards for specific functions based on it. Web services have emerged as the next generation of Web-based technology for exchanging information. Web services are modular, self-describing, self-contained applications that are accessible over the Internet. Based on open Internet standards, Web services enable you to construct Web-based applications using any platform, object model, and programming language that you require. Web services form the building blocks for creating distributed applications that can be published to and accessed over the Internet and corporate intranets. Web services modularity and flexibility make them ideal for application integration. Businesses can mix and match Web services to perform transactions with minimal programming. Web services can vary in function from simple requests (for example, currency conversion or a weather report) to complex business systems that access and combine information from multiple sources. Once a Web service is deployed, other applications and Web services can discover and invoke that service. Web services become more important as the range of computing devices (for example, handheld computers, cellular telephones, or appliances) and platforms (for example, UNIX or Windows CE) increases. Because Web services provide a uniform and ubiquitous information distributor for all of these devices and platforms, they are the next logical step for Web-based computing. 2

Overview of Web Services Consider the following simple example of how a Web service can be implemented as part of a distributed application: To maximize a car s performance, a Formula One pit crew receives a large amount of telemetry data during a race. This information typically includes data about gear choice, engine temperatures, and vehicle height. Additionally, the team requires realtime weather information to plan for precipitation and wind speed. In their data management application, they could include functionality that invokes a Web service to display weather updates instantly. Another example shows how multiple Web services are used to provide information to humans as well as to other computers: As shown in Figure 1, a phone company needs to receive usage data from telephone exchanges, convert that data into billing information, and display it to a user through an Internet browser. The company deploys a Web service to receive data from telephone exchanges. The ubiquitous and non-platform-specific nature of Web services enables the phone company to receive messages from a variety of different exchanges. The company uses its in-house system to process the usage data, and then exposes that data using another Web service. Human customers can access their billing information through an Internet browser. Alternatively, a corporation could develop its own accounting system to invoke the phone company s Web service and to collect billing information and use it to process payment. End User To view billing information the end user invokes another phone company Web service using an Internet browser. Telephone Exchange The phone company hosts a Web service that accepts usage data from the telephone exchange. Phone Company The corporation invokes the billing information Web service, which passes data to its internal accounting system. Corporation Figure 1: Examples of Web services 3

Chapter 1, Understanding Web Services These examples provide some scenarios of how Web services can be implemented. XML-based standards such as Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP), and Universal Description, Discovery, and Integration (UDDI) are available to make building applications from selected Web services viable. These technologies are discussed below in How Web Services Work on page 6. The following sections describe the benefits of Web service and the technologies behind them. The Benefits of Web Services Web services are superior to current business-to-business Web-based solutions because they are: Easy to use Using Web services, the business logic of individual systems can be exposed over the Web. Developers or business analysts can compose a custom, client-side solution to a particular business problem by combining the Web services that they require. Not only can Web services developers use their own programming language, but also their own component object model, architecture, and implementation strategy. As long as they adhere to the Web services standards, they can share functionality across the Web without knowledge of their target system s environment. Reusable Because of the component-based model of Web services, they can be reused whenever necessary. Additionally, when combined with a product such as CapeConnect, Web services enable the extension of existing code so that it can be exposed over the Internet. Discrete Unlike most traditional system architectures, Web services support a loosely coupled architecture. Each Web service is typically self-contained and provides a single piece of functionality. Consumable by both humans and computers Unlike HTML, which was designed strictly for display purposes, Web services have been developed to be easily accessible by both humans (for example, through a desktop application) and computers (for example, through an API). Ubiquitous Because Web services are provided over the Internet, they are accessible from anywhere and use existing infrastructure. Furthermore, because of the standards they are developed with, Web services respect existing security systems such as firewalls. 4

The Benefits of Web Services Interoperable By operating on the system boundaries, that is, outside of private company networks, Web services achieve a higher level of commonality than has previously been available. For developers and integrators, this commonality means that the applications and services they develop will enjoy a long life span, outlasting their proprietary equivalents. Web services permit the use of many types of clients not just Java and C++, but also VBScript, JavaScript, Perl, and so on. Furthermore, Web services extend beyond these language-based clients to collaborate with Web standards organizations, such as RosettaNet or X12. The following example describes how a company can realize the benefits of Web services: A company wants to announce the release of a new version of its product to all those active users who have received the previous version. The company needs a system that manages transactions between its messaging system, its inventory management system, and its customer database. Developing this system using, for example, CORBA or Java, requires that business logic for the announcement system be manually coded on the server side, requiring the services of experienced programmers. Subsequent changes or customization must be completed at the code level. By using Web services, the business logic of individual systems can be exposed over the Web. Programmers and even business analysts can develop client-side solutions using the programming languages and platforms that they are familiar with. They can expose the functionality of each system as a Web service, creating a larger, loosely coupled system that can process and distribute the new product announcements. If changes are required, they can be made on individual components without affecting the rest of the system. 5

Chapter 1, Understanding Web Services How Web Services Work As shown in Figure 2, each participant in a Web services architecture can assume one of three conceptual roles: service provider, service broker, or service requester. Your own organization can fill one or more of these roles. Service Broker Deploy Find Service Provider Bind Service Requester Figure 2: The relationships among the core Web services components Put simply, a service provider deploys Web services. A service broker lists various services and arranges transactions, helping service providers and service requesters find each other. A service requester uses an application programming interface (API) to discover Web services, asking the service broker about the services it needs. When the service broker returns results, the service requester can then invoke those services it needs to create applications. Three core XML-based technologies enable Web service providers, brokers, and requesters to communicate: Universal Description, Discovery, and Integration (UDDI) Web Services Description Language (WSDL) Simple Object Access Protocol (SOAP) 6

How Web Services Work Universal Description, Discovery, and Integration (UDDI) UDDI is the meeting place for Web services. An information database of Web services, a UDDI registry stores descriptions about companies and the services they offer in a common XML format. Just as businesses list their products and services in a telephone directory, Web service brokers use this specification to register services that service requesters can then discover and invoke. Web-based applications interact with a UDDI registry using SOAP messages. Conceptually, the data in a UDDI registry can be divided into three different types of telephone directories: a white pages section that provides business contact information, a yellow pages section that categorizes businesses and services, and a green pages section that provides technical information about the services that a business offers. A typical example of UDDI usage is a stock-ticker application that can automatically locate a Web service that offers stock quotes using a standardized API. Web Services Description Language (WSDL) WSDL is the metadata language of Web services. It defines how service providers and requesters communicate with each other about Web services. WSDL is an XML schema that defines XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and automate the details involved in communications between applications. Like XML, WSDL is extensible to allow the description of endpoints and their messages, regardless of what message formats or network protocols are used for communicating. WSDL can be used to design specifications to invoke and operate Web services on the Internet and to access and invoke remote applications and databases. 7

Chapter 1, Understanding Web Services Simple Object Access Protocol (SOAP) SOAP is a protocol for exchanging information in a decentralized, distributed environment. It defines a mechanism to pass commands and parameters between clients and servers. Like Web services as a whole, SOAP is independent of the platform, object model, and programming language being used. The SOAP protocol is XML-based and consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls and responses. A particular advantage of SOAP over earlier protocols, such as Internet Inter-ORB Protocol (IIOP) for CORBA or Java Remote Method Protocol (JRMP) for Java Remote Method Invocation (RMI), is that it uses XML and is therefore text-based. This makes SOAP-based applications easier to debug, because it is easier to read XML than to read a binary stream. Additionally, using text-based protocols like SOAP over HTTP enables information to pass more easily through corporate firewalls. Other Relevant Technologies CapeConnect supports three protocols Hypertext Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (HTTPS), and Simple Mail Transfer Protocol (SMTP) for invoking Web services. HTTP is the standard set of rules for exchanging files on the Internet. HTTPS is a related protocol developed by Netscape that encrypts and decrypts user page requests as well as the pages that are returned by a Web server. HTTPS uses Secure Sockets Layer (SSL) technology for communication. SSL is a public-key based protocol for network security. The standard protocol for sending and receiving e-mail, SMTP is an asynchronous alternative to HTTP. Web services developers can use SOAP messages transferred through SMTP when they are interfacing with components that return data by using e-mail messages. The following real-world example describes how SMTP might be used in a Web services solution. 8

CapeConnect and Web Services A company wants to distribute software license keys for a new version of their product. They develop a Web service that first communicates with their third-party customer management system and then obtains a contact list of the users who should receive a license key. The Web service then obtains a license key for each user from the company s internal license server. Because the license server is set up to receive license requests and send responses using e-mail messages, the Web service uses SMTP to communicate with it. CapeConnect and Web Services As shown in Figure 3, these basic components work together to form a Web services architecture. In this abstract model, CapeConnect serves as the Web Services platform that bridges the gap between your server-side functionality and the Internet. CLIENT Internet Browser Firewall SERVER Desktop Application Web Server Web Services Platform Server-Side Functionality API WSDL Files Figure 3: A basic Web services architecture Creating and Using Web Services with CapeConnect CapeConnect is a Web services platform that enables you to expose your existing Java, Enterprise JavaBeans (EJB), and CORBA server-side systems as Web services. CapeConnect bridges the gap between the Web and systems based on these technologies, not only by adhering to a Web services architecture, but also by providing development tools that unite your server-side components. Using 9

Chapter 1, Understanding Web Services CapeConnect, you can generate WSDL files for your current Java, EJB, and CORBA components. Additionally, you can use CapeConnect to create and host your own UDDI registry. For more information about using UDDI with CapeConnect, see CapeConnect User s Guide. Creating Web Service Applications with CapeStudio A companion product to CapeConnect, CapeStudio is Cape Clear s rapid application development (RAD) environment for developing Web services. It accelerates the process of developing Web service applications by enabling developers to focus on the business logic of their systems instead of the details of WSDL, SOAP, and UDDI. CapeStudio includes the following tools: A graphical mapper for defining transformations between XML documents, such as XML Schemas, WSDL files, and SOAP messages. The CapeStudio Mapper generates Extensible Stylesheet Language Transformations (XSLT) files, which are used to facilitate data exchange between businesses. A code generator that enables you to automatically create Visual Basic and Java client proxies, as well as EJB skeleton code for server-side EJB components. A UDDI registry browser to search for Web services. Combining CapeStudio and CapeConnect As shown in Figure 4 on page 11, CapeStudio can act as a development, design-time environment while CapeConnect manages the system at runtime. However, each product is standalone and contains features applicable at both runtime and design 10

CapeConnect and Web Services time. For example, the deployment wizard in CapeConnect enables you to create WSDL files based on server-side components, while CapeStudio can invoke Web services using SOAP messages. RUNTIME Client applications invoke the Web services using SOAP messages over HTTP or SMTP CapeConnect exposes these components as Web services Java Client Applications Internet CapeConnect Web Services Platform EJB CORBA DESIGN TIME CapeStudio generates Java and Visual Basic code proxies from WSDL files XSLT Files CapeStudio uses generated WSDL files to create XSLT CapeConnect generates WSDL files for server-side Java, EJB and CORBA components Java Client Visual Basic Client CapeStudio Development Environment WSDL Files Figure 4: How CapeConnect and CapeStudio work together By putting CapeStudio and CapeConnect together, you form an end-to-end solution that combines a RAD environment with a Web services platform. You can use client code generated in CapeStudio to create applications that can invoke Web services hosted by CapeConnect from your desktop. Alternatively, you can map WSDL files generated by CapeConnect to schemas in CapeStudio and use the resulting XSLT to transform incoming SOAP messages. For more information on the concepts and technologies discussed in this chapter, see CapeConnect User s Guide. 11

Chapter 1, Understanding Web Services Summary Following are the key points discussed in this chapter: The introduction of XML enables developers to separate the content of data exposed over the Web from its presentation. Web services are modular, self-describing, self-contained applications that are accessible over the Internet. Web services are superior to current business-to-business Web-based solutions because they are easy to use, reusable, discrete, ubiquitous, interoperable, and consumable by both humans and computers. A service provider deploys Web services. A service broker lists various services and arranges transactions, helping service providers and service requesters find each other. The core XML-based technologies that are key to working with Web services are Universal Description, Discovery, and Integration (UDDI), Web Services Description Language (WSDL), and Simple Object Access Protocol (SOAP). CapeConnect is a Web services platform that enables you to expose your existing Java, Enterprise JavaBeans (EJB), and CORBA server-side systems as Web services. CapeStudio is Cape Clear s rapid application development environment for Web services. 12

Creating Web Services with CapeConnect 2 CapeConnect bridges the gap between Java objects, Enterprise JavaBeans (EJB), and CORBA objects and the Web. It provides a Web services platform and development tools for creating Web services from Java and CORBA objects. This chapter discusses the following topics: The Role of CapeConnect Overview of CapeConnect 13

Chapter 2, Creating Web Services with CapeConnect The Role of CapeConnect CapeConnect extends Java, EJB, and CORBA systems to the Internet by providing a Web services architecture for e-business applications and a set of rapid application development tools that connect your server-side components to this architecture. CapeConnect unites Web-based applications, middleware components, and XML-based applications around a common, standards-based XML model. At runtime, a SOAP message from a client is channelled to CapeConnect, which interprets the client s input and converts it to Java or CORBA calls. CapeConnect communicates with your enterprise beans, Java objects, or CORBA objects, gathers the information that a client requires, and returns this information as a SOAP response. CapeConnect s development tools include a deployment wizard that generates WSDL files and a Universal Description, Discovery, and Integration (UDDI) registry. The deployment wizard enables you to generate Web Services Description Language (WSDL) files based on your enterprise beans, Java objects, and CORBA objects. CapeConnect s UDDI support enables you to publish, search for, and drill-down into information about Web services. CapeConnect also provides two Java application programming interfaces (APIs): SOAPDirect and UDDIDirect. SOAPDirect enables remote applications to connect to the CapeConnect infrastructure through the Simple Object Access Protocol (SOAP). This simple API, along with other SOAP APIs that are available for many languages, makes the CapeConnect infrastructure a highly flexible means of integrating distributed e-business components. UDDIDirect is a toolkit for creating Java clients that communicate with UDDI registries. It provides a Java API that enables developers to publish and retrieve information in registries that support the UDDI 1.0 standard. For an overview of the technologies discussed in this section, see How Web Services Work on page 6. 14

Overview of CapeConnect Overview of CapeConnect When learning about CapeConnect, it is important to understand the CapeConnect architecture, as well as how the CapeConnect development tools enable you to add components to this architecture. The architecture is straightforward yet powerful, because it makes Hypertext Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (HTTPS), and Simple Mail Transfer Protocol (SMTP) the standard protocols for accessing server-side components. Overview of the Architecture CapeConnect makes enterprise beans, Java objects, and CORBA objects available to any components that can communicate using SOAP. To achieve a robust, scalable, and efficient communications model, CapeConnect uses the architecture shown in Figure 5. CapeConnect Console EXTERIOR FIREWALL INTERIOR FIREWALL CORBA ORB SOAPDirect Client SOAP DMZ CapeConnect Console Server IIOP CORBA Objects IDL File Servlet Engine Servlet Engine EJB Container CapeConnect Gateway SOAP CapeConnect XML Engine RMI-IIOP Enterprise Beans EJB Interface Definitions Other XML Client SOAP JAR File UDDI Registry RMI Java Objects Class Definitions CapeConnect Deployment Wizard WSDL and WSML Files Figure 5: The CapeConnect architecture 15

Chapter 2, Creating Web Services with CapeConnect The CapeConnect architecture contains four core components: The CapeConnect gateway is a servlet that runs in a servlet engine on your Web server. The gateway acts as a communication bridge between remote clients and the CapeConnect XML engine. The CapeConnect XML engine converts SOAP messages from the gateway to Java calls on back-end components. The XML engine then converts the results of these Java calls to SOAP messages and returns these messages to the gateway. The CapeConnect J2EE engine is Cape Clear s implementation of the Java 2 Platform, Enterprise Edition (J2EE). The CapeConnect UDDI registry is Cape Clear s implementation of the UDDI 1.0 standard. Communication between clients, the gateway, and the XML engine takes place over HTTP, HTTPS, or SMTP, so you can place firewalls between these components without opening additional, insecure pathways. In addition to these core components, CapeConnect also includes an administrative console for managing CapeConnect servers, a CORBA naming service, and a Web service deployment wizard. The CapeConnect Gateway An Internet client makes a call to an enterprise bean, Java object, or CORBA object by sending a SOAP request to the CapeConnect gateway. The gateway then forwards this message to the XML engine, which processes it. When the XML engine returns the results of a method call to the gateway, the gateway sends the corresponding SOAP response to the client. The architecture of the CapeConnect gateway is very simple. This guarantees easy portability across Web servers, improves the performance of CapeConnect applications, and reduces maintenance. 16

Overview of CapeConnect The CapeConnect XML Engine An intranet client makes a call to an enterprise bean, Java object, or CORBA object by sending a SOAP request to the CapeConnect XML engine. The XML engine is a core component of CapeConnect. This component accepts incoming SOAP requests from the client or gateway, converts each request to a corresponding method call, and makes calls directly to your back-end components. The XML engine then converts the results to SOAP responses, which it returns to the gateway. The CapeConnect J2EE Engine J2EE represents a single standard for implementing and deploying Web-enabled applications that include enterprise beans, servlets, and JavaServer Pages (JSP). In addition, J2EE describes how these technologies work together to provide a complete solution. CapeConnect contains a full implementation of J2EE known as the CapeConnect J2EE engine. This J2EE implementation is used to host the XML engine and can also be used by your enterprise beans. The CapeConnect UDDI Registry The CapeConnect UDDI registry is hosted as a Web service by the CapeConnect architecture. All your UDDI data is stored in an external database. CapeConnect also includes a Web browser interface that provides form-based access to a UDDI registry and a Java API, called UDDIDirect, that provides a simplified UDDI access model for developers. CapeConnect APIs CapeConnect provides two application programming interfaces SOAPDirect and UDDIDirect that extend the functionality of your Web services. Understanding SOAPDirect SOAPDirect is a Java API that enables developers to connect any Java-based client to the CapeConnect XML infrastructure. All communication between the components of the CapeConnect infrastructure is based on SOAP 1.1 messages. If you know how to construct these messages, you can connect any software component directly to the CapeConnect infrastructure. 17

Chapter 2, Creating Web Services with CapeConnect While popular XML authoring tools, such as XMetal, provide the capability to hand-create XML documents using a Document Type Definition (DTD), CapeConnect provides a simple way to create CapeConnect XML documents in Java programs. SOAPDirect enables Java programmers to create, dispatch, receive, and interpret these documents. Using SOAPDirect, you can integrate any Java-based program with back-end Java systems through the CapeConnect XML infrastructure. The SOAPDirect classes provide an intuitive mechanism for handling XML documents, without requiring you to manipulate XML constructs directly. SOAPDirect was designed to enable you to create documents using a small, simplified API. Using this API, it is not necessary to understand the intricacies of the Web services programming model. Issues such as type management are handled automatically by the CapeConnect XML engine, and your clients do not require client-side stubs. Understanding UDDIDirect UDDIDirect is a Java toolkit that enables you to publish information about businesses and Web services in UDDI registries and to browse and read this information. A UDDIDirect client and a UDDI registry communicate by exchanging the SOAP messages defined in the UDDI Programmer's API 1.0. The UDDIDirect API hides the complexity of constructing, transmitting, and receiving these messages and manipulating UDDI data types in your Java clients. You can use UDDIDirect to create clients that communicate with the CapeConnect UDDI registry or with any other registry that supports the UDDI 1.0 standard. 18

Summary Summary Following are the key points discussed in this chapter: CapeConnect provides a Web services architecture for e-business applications and a set of rapid application development tools that connect your Java, EJB, and CORBA server-side components to this architecture. SOAPDirect and UDDIDirect are simple APIs that enable clients to connect to the CapeConnect architecture. CapeConnect s deployment tools include a deployment wizard that automatically generates WSDL, and a Universal Description, Discovery, and Integration (UDDI) implementation. CapeConnect makes enterprise beans, Java objects, and CORBA objects available to any components that can communicate using SOAP. The CapeConnect architecture contains four core components: the CapeConnect gateway, the CapeConnect XML engine, the CapeConnect J2EE engine, and the CapeConnect UDDI registry. 19

Chapter 2, Creating Web Services with CapeConnect 20

Glossary Glossary A Apache Server A freely available Web server, produced by the Apache Software Foundation, that is distributed under an open-source license. API See application programming interface (API). application programming interface (API) The specification of how a programmer writing an application accesses the behavior and state of classes and objects. C CapeConnect console The graphical tool that enables the control of the components of a CapeConnect system. It handles the display of information on processes managed by the console server, and includes other features, such as the WSDL generator. CapeConnect console server The component that enables the CapeConnect console to communicate with other CapeConnect components. Also known as a server manager. CapeConnect deployment wizard The CapeConnect deployment wizard is a WSDL generator that enables developers to generate WSDL descriptions from enterprise beans and other Java classes. This can enable non-java clients such as Microsoft Visual Basic and C++ (as well as any other client platform with WSDL support) to access components that are deployed in CapeConnect. CapeConnect gateway The component, which runs in a servlet engine on a Web server, that acts as the communication bridge between remote clients and the CapeConnect XML engine. 21

Glossary CapeConnect Java 2 Platform, Enterprise Edition (J2EE) engine Cape Clear s implementation of Sun Microsystems J2EE specification. CapeConnect log server The component that enables the viewing of XML engine and CapeConnect servlet messages on the console at runtime. It also writes the messages to a file called capeconnect.log on the local file system. CapeConnect XML engine The component that converts SOAP messages from the CapeConnect gateway into Java calls on back-end components. It also converts the results of these calls to XML documents and returns them to the gateway. Common Object Request Broker Architecture (CORBA) An architecture and specification, defined by the OMG, for creating, distributing, and managing distributed program objects in a network. console See CapeConnect console. console server See CapeConnect console server. CORBA See Common Object Request Broker Architecture (CORBA). D deployment The process whereby software is installed into an operational environment. Document Object Model (DOM) A tree of objects with interfaces for traversing the tree and writing an XML version of it, as defined by the World Wide Web Consortium (W3C) specification. Document Type Definition (DTD) A description of the structure and properties of a class of XML files. 22

Glossary DOM See Document Object Model (DOM). domain In BEA WebLogic, an interrelated group of WebLogic Server resources defined in a single configuration file. DTD See Document Type Definition (DTD). E ebxml A set of business-to-business XML specifications developed by UN/CEFACT (the United Nations body for Trade Facilitation and Electronic Business) and OASIS (Organization for the Advancement of Structured Information Standards) to enable a modular electronic business framework. EJB See Enterprise JavaBeans (EJB). Enterprise JavaBeans (EJB) A component architecture, which forms part of J2EE, for the development and deployment of object-oriented, distributed, enterprise-level applications. Extensible Markup Language (XML) A flexible way to create common information formats and share both the format and the data on the World Wide Web, intranets, and elsewhere. Extensible Stylesheet Language (XSL) A World Wide Web consortium style sheet format for XML documents. It is the XML counterpart to the Cascading Style Sheets (CSS) language in HTML. Extensible Stylesheet Language Transformations (XSLT) A language for transforming the structure of XML documents. XSLT refers to both transforming one XML document into another XML document and managing conversions between text and HTML documents. 23

Glossary F firewall A functional unit that protects and controls the connection of one network to other networks. The firewall prevents unwanted or unauthorized communication traffic from entering the protected network and allows only selected communication traffic to leave the protected network. G gateway See CapeConnect gateway. H HTML See Hypertext Markup Language (HTML). HTTP See Hypertext Transfer Protocol (HTTP). Hypertext Markup Language (HTML) The set of markup symbols or codes inserted in a file intended for display on a World Wide Web browser. Hypertext Transfer Protocol (HTTP) The set of rules for exchanging files (text, graphic images, sound, video, and other multimedia files) on the World Wide Web. Relative to the TCP/IP suite of protocols, which are the basis for information exchange on the Internet, HTTP is an application protocol. HTTPS See Secure Hypertext Transfer Protocol (HTTPS). 24

Glossary I IDL See Interface Definition Language (IDL). IDL attribute A value associated with an IDL interface. Conceptually, a CORBA object that implements the IDL interface also implements the value of each attribute in the interface. Clients that communicate with a CORBA object can get or set the attribute values for that object. However, the values of some attributes, known as read-only attributes, cannot be set by clients. IDL interface A type of IDL construct that enables clients to make calls to CORBA objects. IDL module A type of IDL construct that contains other IDL definitions, preventing clashes between IDL constructs with the same name. IDL operation A type of IDL construct that describes the calls that a client can make to CORBA objects. An IDL interface can contain any number of operations. IIOP See Internet Inter-ORB Protocol (IIOP). INS See Interoperable Naming Service (INS). Interface Definition Language (IDL) The CORBA language that allows object interfaces to be defined in a manner that is independent of any particular programming language. This allows applications that use different programming languages to interoperate. Internet Inter-ORB Protocol (IIOP) A standard CORBA communications protocol that makes it possible for different ORBs to communicate with each other. IIOP runs over TCP/IP. 25

Glossary Interoperable Naming Service (INS) A standard specification for the CORBA naming service. The INS includes a standard string representation for object names. Interoperable Object Reference (IOR) In CORBA 2.0, the information that enables an ORB to locate an object in a network. In an IOR, the structure and format of this data is standardized. iplanet Application Server A development tool from iplanet E-Commerce Solutions, a Sun-Netscape Alliance, for building e-commerce applications using J2EE standards, including Enterprise JavaBeans (EJB) components. CapeConnect supports integration with version 6.0 (SP2 or later) of iplanet Application Server. J JacORB A freely available CORBA 2.3 ORB, written in Java. JacORB is produced by Gerald Brose of Freie Universität Berlin, and colleagues. JacORB naming service A CORBA naming service supplied with JacORB. JAR file See Java Archive (JAR) file. Java The trademark of Sun Microsystems for a set of technologies for creating and safely running software programs in both standalone and networked environments. Java Archive (JAR) file A file format that enables the bundling of multiple files into a single archive file. A JAR file typically contains the class files and auxiliary resources associated with applets and applications. 26

Glossary JavaBeans An object-oriented programming interface from Sun Microsystems that lets you build reusable applications or program building blocks called components that can be deployed in a network. Java Development Kit (JDK) A software development environment for writing applications in the Java programming language. Java Remote Method Invocation (RMI) A distributed object model for communications among Java programs, in which the methods of remote objects written in the Java programming language can be invoked from other Java virtual machines, possibly on different hosts. Java Runtime Environment (JRE) A subset of the Java Development Kit (JDK) for end users and developers who want to redistribute the runtime environment alone. The Java runtime environment consists of the Java virtual machine, the Java core classes, and supporting files. Java virtual machine (JVM) A software execution engine that safely and compatibly executes the byte codes in Java class files on a microprocessor, whether in a computer or in another electronic device. Java 2 Platform, Enterprise Edition (J2EE) An environment for developing and deploying enterprise applications. J2EE consists of a set of services, application programming interfaces (APIs), and protocols that provide the functionality for developing multi-tiered, Web-based applications. JavaScript A Web scripting language that is used in both browsers and Web servers. Like all scripting languages, it is used primarily to tie other components together or to accept user input. JavaServer Pages (JSP) An extensible Web technology that uses template data, custom elements, scripting languages, and server-side Java objects to return dynamic content to a client. Typically, the template data consists of HTML or XML elements, and in many cases the client is a Web browser. 27

Glossary JDK See Java Development Kit (JDK). JRE See Java Runtime Environment (JRE). JSP See JavaServer Pages (JSP). JVM See Java virtual machine (JVM). J2EE See Java 2 Platform, Enterprise Edition (J2EE). J2EE engine See CapeConnect Java 2 Platform, Enterprise Edition (J2EE) engine. L log server See CapeConnect log server. M Microsoft SOAP Toolkit A Microsoft programming tool that enables developers to use Microsoft Visual Studio 6.0 to build, expose, and consume Web services. Not to be confused with SOAP toolkits produced by other companies. 28

Glossary N name In CORBA, an identifier associated with an object reference in the CORBA naming service. A CORBA client can retrieve an object reference from the naming service by resolving the associated name. Names can be converted to a standard string format, as described in the OMG's INS specification. namespace A unique identifier that indicates the names of particular data elements or attributes used within an XML file. naming service Maps a given name to the corresponding object reference stored under that name. O Object Management Group (OMG) A software consortium that develops standards, such as CORBA, for the design of portable distributed applications for heterogeneous systems. object reference In CORBA, information that enables an ORB to locate an object within a network. Two ORB implementations can differ in their choice of object-reference representation. However, the CORBA IOR format provides a common, interoperable representation for object references. Object Request Broker (ORB) In CORBA, the software component that acts as a broker between a client request for a service from a distributed object or component and the completion of that request. Having ORB support in a network means that a client program can request a service without having to know the location of a target object in a distributed network or how the object is implemented. Components can detect each other and exchange interface information as they are running. OMG See Object Management Group (OMG). 29

Glossary ORB See Object Request Broker (ORB). Orbix A CORBA 2.1 ORB, produced by IONA Technologies. Orbix 2000 A CORBA product, produced by IONA Technologies. Orbix 2000 contains several components, including a CORBA 2.3 ORB and a CORBA naming service. Orbix 2000 forms part of the iportal Suite from IONA Technologies. OrbixNames An implementation of the CORBA naming service, produced by IONA Technologies. OrbixNames forms part of several IONA Technologies products, including Orbix and OrbixWeb. OrbixWeb A Java version of Orbix. Orcas The former name of the CapeConnect J2EE engine. R Remote Procedure Call (RPC) A protocol used by one program to request a service from a program located in another computer in a network, without having to understand the network details. RMI See Java Remote Method Invocation (RMI). RPC See Remote Procedure Call (RPC). 30

Glossary S SAX See Simple API for XML (SAX). schema In XML, a conceptual framework that describes the underlying structure of your collection of elements. Secure Hypertext Transfer Protocol (HTTPS) A Web protocol developed by Netscape and built into its browser that encrypts and decrypts user page requests as well as the pages that are returned by the Web server. See also Hypertext Transfer Protocol (HTTP). Secure Sockets Layer (SSL) A public key-based protocol for network security used by HTTPS. service broker A component of Web services that lists various services and arranges transactions, helping service providers and service requesters find each other. service provider A component of Web services that deploys Web services for service requesters to use. service requester A component of Web services that uses an application programming interface (API) to discover Web services, asking the service broker about the services it needs. servlet A Java program that extends the functionality of a Web server, generating dynamic content and interacting with Web clients using a request-response paradigm. SGML See Standardized Generalized Markup Language (SGML). Simple API for XML (SAX) An event-driven, serial-access mechanism for accessing XML documents. 31

Glossary Simple Object Access Protocol (SOAP) An RPC mechanism using HTTP as the base transport and XML as the method for encoding invocation requests and responses to access services, objects, and servers in a platform-independent manner. SOAP See Simple Object Access Protocol (SOAP). SOAP Toolkit See Microsoft SOAP Toolkit. SOAPDirect API A Java API that enables Java programmers to create, dispatch, receive, and interpret XML documents in CapeConnect. SSL See Secure Sockets Layer (SSL). Standardized Generalized Markup Language (SGML) An ISO/ANSI/ECMA standard that specifies a way to annotate text documents with information about types of sections of a document. stringified object reference In CORBA, a string that begins with IOR: followed by a hex number. The hex number encodes the information stored in an object reference. T Tomcat A freely available Java servlet engine, produced by the Apache Software Foundation, that provides the reference implementation of JSP 1.1 and Java Servlet 2.2 technologies. U UDDI See Universal Description, Discovery, and Integration (UDDI). 32