Introduction to Adobe Connect Web Services Architecture

Adobe® Connect™ Web Services is the web service layer over the Adobe Connect Server suite of applications.

Web services allow you to build portals or web applications that integrate Adobe Connect functionality and reporting information with third-party systems such as portals, customer relationship management systems, and enterprise resource planning systems.

As an example, you might have a central user management system, such as an LDAP directory, Microsoft Active Directory, or another third-party system, that is an integral part of your business processes.

Using web services, you can write an application that synchronizes users between your system and Adobe Connect. The application can use the J2EE platform or another technology of your choice to pull a list of users from the directory, compare it against a list of Adobe Connect users, and then perform requested updates within the Adobe Connect user repository, such as adding or deleting users or groups.

The data flows between client applications and Adobe Connect are shown in the following diagram. Custom applications that you write use paths 1 to 2 and A to B. Adobe Connect applications (such as Adobe Connect Meeting, Adobe Connect Training, or Adobe Connect Events) can use any of the data flow paths.

The data flow can be encrypted with SSL or unencrypted.

If the data flow is unencrypted, connections are made over HTTP and Adobe Real Time Messaging Protocol (RTMP) and follow the paths described in the following table.

If the data flow is encrypted, connections are made securely over HTTPS and RTMPS (Real Time Messaging Protocol over SSL), as follows.

Custom applications

Adobe Connect Web Services provides an XML API, so your application must be able to communicate with Adobe Connect using XML over HTTP or XML over HTTPS. Your application calls the API by building a request URL and passing it one or more parameters, either as name/value pairs or as an XML document. Web Services returns an XML response, from which you can extract values.

Custom applications retrieve metadata from the Adobe Connect database. Metadata includes meeting or course names and times, meeting room URLs, content URLs, and report information.

The data flow for a custom application retrieving metadata from the database is from a client web browser, to the client web application server, to the XML API, the Adobe Connect web application server, and the SQL database—and then back again.

The data flow between a custom application and Adobe Connect works like this:

Adobe Connect applications

Adobe Connect applications call the server using the same Web Services XML API that you use from a custom application.

In general, content is transported over HTTP port 80 or HTTPS port 443. Content includes slides, HTTP pages, SWF files, and files transferred through the FileShare pod. These are default port numbers that you can configure (see Migrating, Installing, and Configuring Adobe Connect Server for details).

Streamed, real-time communications from Adobe Media Server are transported over RTMP port 1935. Streamed communications include audio, video (webcam and FLV), file share, and chat. Meeting state is also maintained over RTMP port 1935.

Components of Adobe Connect

Adobe Connect is architected with two server components, and each server uses a SQL database.

The web application server is the brains of Adobe Connect. It contains and executes all of the business logic needed to deliver content to users. It handles access control, security, quotas, and licensing, as well as management functions such as clustering, failover, and replication.

The web application server also handles Adobe Connect Central, the application through which you view and manage your organization’s content and users—when you are not using a custom application or integrated third-party system. The metadata describing content and users can be stored in either single or multiple replicated SQL databases. The web application server is stateless, which means that scaling is near linear.

Adobe Media Server streams audio, video, and rich media content using RTMP. When a meeting is recorded and played back, audio and video are synchronized, or content is converted and packaged for real-time screen sharing, Adobe Media Server does the job.

Adobe Media Server also plays a vital role in reducing server load by caching frequently accessed web pages, streams, and shared data.

Adobe Connect uses the Microsoft SQL Server database for persistent storage of transactional and application metadata, including users, groups, content, and reporting information. The XML API retrieves metadata stored in the database. The database can be implemented with either the Microsoft SQL Server Desktop Engine (MSDE) or the full version of Microsoft SQL Server 2005.

Making your first API call

Adobe Connect Web Services uses a servlet framework to handle XML API requests. In the data flow diagram, the servlet framework is represented by the API component. The API servlet receives XML requests from clients and returns XML responses from the web application server and the database.

A request to the XML API is formatted as an HTTP request URL that the API servlet handles. A request URL has an action name and parameters in name/value pairs, like this:

If you have access to a Adobe Connect account in which you can test API calls, you can experiment. In fact, Adobe recommends testing API calls in the browser while you learn the API and write applications.

Before you begin, it’s useful to install a tool that allows you to view HTTP request and response headers in your browser.

Call common-info in a browser

Call principal-list in a browser

Once you have the BREEZESESSION cookie value from common-info, the browser adds it to the request header on your next request.

Add filters and sorts

Many actions in the API allow you to add a filter to return only certain response elements or a sort to display response elements in a certain order.

A filter is a special parameter that starts with the keyword filter, followed by an optional modifier, then a field name and a value. These are all examples of filters:

• filter-name=jazz doe (which matches results with the exact name jazz doe)

• filter-like-name=jazz (which matches any results that contain jazz in the name)

• filter-out-type=user (which returns any results that do not have a type of user)

These are just a few filter types, and you can find more in filter-definition. Check an action in the reference (at Action reference) to see whether its response can be filtered. In general, if an action allows filters, you can use them on any response element or attribute.

A sort is another special parameter that starts with the keyword sort (or sort1 or sort2), followed by a field name and then one of the keywords asc or desc, for example:

• sort-name=asc (to sort in ascending order by name)

• sort-group-id=desc (to sort in descending order by group-id)

These are just a few sort examples. You can test sorts in the browser or see sort-definition for more.

Make a call with a filter and sort

Where to go from here

At this point, you can continue to test calls in the browser and observe how they work. It’s the best and easiest way to learn the XML API. When you need more information, turn to any of these sources:

• The API reference in Action reference.

• Login and requests for information on how to log users in from applications.

• Basics to learn the three basic concepts underlying the API.

• Meetings if you want to create and manage meetings from an application.

• Training if you are building a training application.