Введение в Интерфейсы Поставщика услуг

Каковы Службы?

Службы являются модулями обрабатывающей звук функциональности, которые автоматически доступны, когда прикладная программа использует реализацию API Звука Java. Они состоят из объектов, которые делают работу чтения, записи, смешивания, обработки, и преобразования данные MIDI и аудио. Реализация API Звука Java обычно предоставляет основной набор служб, но механизмы также включаются в API, чтобы поддерживать разработку новых звуковых служб сторонними разработчиками (или поставщиком реализации непосредственно). Эти новые службы могут быть "включены в" существующую установленную реализацию, чтобы развернуть ее функциональность, не требуя нового выпуска. В архитектуре API Звука Java сторонние службы интегрируются в систему таким способом, которым интерфейс прикладной программы им является тем же самым как интерфейсом к "встроенным" службам. В некоторых случаях, разработчики приложений, которые используют javax.sound.sampled и javax.sound.midi пакеты не могли бы даже знать, что используют сторонние службы.

Примеры стороннего потенциала, службы выбранного аудио включают:

• Читатели звукового файла и писатели
• Преобразователи, которые преобразовывают между различными форматами аудиоданных
• Новые аудио микшеры и устройства ввода-вывода, реализованный ли просто в программном обеспечении, или в аппаратных средствах с интерфейсом программного обеспечения

Сторонние службы MIDI могли бы состоять из:

• Средства чтения файлов MIDI и писатели
• Читатели для различных типов soundbank файлов (которые являются часто определенными для определенных синтезаторов),
• УПРАВЛЯЕМЫЕ MIDI звуковые синтезаторы, секвенсеры, и порты ввода-вывода, реализованный ли просто в программном обеспечении, или в аппаратных средствах с интерфейсом программного обеспечения

Как Работают Службы

javax.sound.sampled и javax.sound.midi пакеты предоставляют функциональность разработчикам приложений, которые хотят включать звуковые службы в их прикладные программы. Эти пакеты для потребителей звуковых служб, обеспечивая интерфейсы, чтобы получить информацию о, управление, и аудио доступа и службы MIDI. Кроме того, API Звука Java также предоставляет два пакета, которые определяют абстрактные классы, которые будут использоваться провайдерами звуковых служб: javax.sound.sampled.spi и javax.sound.midi.spi пакеты.

Разработчики новых звуковых служб реализуют конкретные подклассы соответствующих классов в пакетах SPI. Эти подклассы, наряду с любыми дополнительными классами, требуемыми поддерживать новую службу, помещаются в Архив Java (JAR) архивный файл с описанием включенной службы или служб. Когда этот файл JAR устанавливается в пользователе CLASSPATH, система времени выполнения автоматически делает новую службу доступной, расширяя функциональность системы времени выполнения платформы Java.

Как только новая служба устанавливается, к ней можно получить доступ точно так же как любой ранее установленная служба. Потребители служб могут получить информацию о новой службе, или получить экземпляры новой службы class непосредственно, вызывая методы AudioSystem и MidiSystem классы (в javax.sound.sampled и javax.sound.midi пакеты, соответственно), чтобы возвратить информацию о новых службах, или возвратить экземпляры новых или существующих классов службы непосредственно. Прикладные программы нуждаются в not⠀” и если not⠀” ссылаются на классы в пакетах SPI (и их подклассы) непосредственно, чтобы использовать установленные службы.

Например, предположите, что гипотетический поставщик услуг под названием Acme Software, Inc. интересуется предоставлением пакета, который позволяет прикладным программам читать новый формат звукового файла (но тот, аудиоданные которого находятся в стандартном формате данных). SPI class AudioFileReader может быть разделен на подклассы в class, вызванный, скажем, AcmeAudioFileReader. В новом подклассе Высшая точка предоставила бы реализации всех методов, определенных в AudioFileReader; в этом случае есть только два метода (с разновидностями параметра), getAudioFileFormat и getAudioInputStream. Затем, когда прикладная программа, предпринятая, чтобы считать звуковой файл, который, оказалось, был в формате файла Высшей точки, он вызовет методы AudioSystem class в javax.sound.sampled получить доступ к файлу и информации об этом. Методы AudioSystem.getAudioInputStream и AudioSystem.getAudioFileFormat обеспечьте стандартный API, чтобы считать аудиопотоки; с AcmeAudioFileReader Установленный class, этот интерфейс расширяется, чтобы поддерживать новый тип файла прозрачно. Разработчики приложений не нуждаются в прямом доступе к недавно зарегистрированным классам SPI: AudioSystem объектные методы передают запрос на установленный AcmeAudioFileReader class.

Какой смысл того, чтобы иметь эти классы "фабрики"? Почему бы не разрешать разработчику приложений получать доступ непосредственно к недавно предоставленным услугам? Это - возможный подход, но имеющий все управление и инстанцирование служб проходят через экраны системных объектов привратника разработчик приложений от необходимости знать что-либо об идентификационных данных установленных служб. Разработчики приложений только используют службы имеющие значение для них, возможно даже не понимая это. Одновременно эта архитектура разрешает поставщикам услуг эффективно управлять доступными ресурсами в своих пакетах.

Часто использование новых звуковых служб прозрачно к прикладной программе. Например, вообразите ситуацию, где разработчик приложений хочет читать в потоке аудио от файла. Принятие этого thePathName идентифицирует файл аудиовхода, программа делает это:

    File theInFile = new File(thePathName);
    AudioInputStream theInStream = AudioSystem.getAudioInputStream(theInFile); 

Негласно, AudioSystem определяет, какая установленная служба может считать файл и просит, чтобы это предоставило аудиоданные как AudioInputStream объект. Разработчик не мог бы знать или даже заботиться, что входной аудиофайл находится в некотором новом формате файла (таком как Высшая точка), поддерживается установленными сторонними службами. Первый контакт программы с потоком через AudioSystem объект, и весь его последующий доступ к потоку и его свойства через методы AudioInputStream. Оба из них являются стандартными объектами в javax.sound.sampled API; специальная обработка, которой может потребовать новый формат файла, полностью скрывается.

Как Провайдеры Готовят Новые Службы

Поставщики услуг предоставляют свои новые службы в особенно отформатированных файлах JAR, которые должны быть установлены в каталоге на системе пользователя, где Среда выполнения Java найдет их. Файлы JAR являются архивными файлами, каждый содержащий наборы файлов, которые могли бы быть организованы в иерархических структурах каталога в пределах архива. Детали о подготовке файлов class, которые входят в эти архивы, обсуждаются в следующих немногих страницах, которые описывают специфические особенности аудио и пакетов SPI MIDI; здесь мы только дадим краткий обзор процесса создания файла JAR.

Файл JAR для новой службы или служб должен содержать файл class для каждой службы, поддерживаемой в файле JAR. После соглашения платформы Java у каждого файла class есть имя недавно определенного class, который является конкретным подклассом одного из классов провайдера реферативной службы. Файл JAR также должен включать любые классы поддержки, требуемые новой реализацией службы. Так, чтобы новая служба или службы могли быть расположены системным механизмом поставщика услуг времени выполнения, файл JAR должен также содержать специальные файлы (описанный ниже), которые отображают SPI имена class к новым определяемым подклассам.

Чтобы продолжать от нашего примера выше, скажите, что Acme Software, Inc. распределяет пакет новых служб выбранного аудио. Давайте предположим, что этот пакет состоит из двух новых служб:

• AcmeAudioFileReader class, который был упомянут выше, и который является подклассом AudioFileReader
• Подкласс AudioFileWriter вызванный AcmeAudioFileWriter, который запишет звуковые файлы в новом формате Высшей точки

Запускаясь с произвольного directory⠀” позволяют нам вызывать это /devel⠀”, где мы хотим сделать создавание, мы создаем подкаталоги и помещаем новые файлы class в них, организованный таким способом как, чтобы дать требуемый путь, которым сошлются на новые классы:

    com/acme/AcmeAudioFileReader.class
    com/acme/AcmeAudioFileWriter.class

Кроме того, для каждого нового SPI разделяемый на подклассы class, мы создаем отображающийся файл в особенно именованном каталоге META-INF/services. Имя файла является именем SPI class, разделяемый на подклассы, и файл содержит имена новых подклассов того краткого обзора SPI class.

Мы создаем файл

  META-INF/services/javax.sound.sampled.spi.AudioFileReader

который состоит из

    # Providers of sound file-reading services 
    # (a comment line begins with a pound sign)
    com.acme.AcmeAudioFileReader

и также файл

  META-INF/services/javax.sound.sampled.spi.AudioFileWriter

который состоит из

    # Providers of sound file-writing services 
    com.acme.AcmeAudioFileWriter

Теперь мы работаем jar из любого каталога с командной строкой:

jar cvf acme.jar -C /devel .

-C причины опции jar переключаться на /devel каталог, вместо того, чтобы использовать каталог, в котором выполняется команда. Заключительный параметр периода сообщает jar заархивировать все содержание того каталога (а именно, /devel), но не каталог непосредственно.

Это выполнение создаст файл acme.jar с содержанием:

com/acme/AcmeAudioFileReader.class
com/acme/AcmeAudioFileWriter.class
META-INF/services/javax.sound.sampled.spi.AudioFileReader
META-INF/services/javax.sound.sampled.spi.AudioFileWriter
META-INF/Manifest.mf

Файл Manifest.mf, который сгенерирован jar утилита непосредственно, список всех файлов, содержавшихся в архиве.

Как Пользователи Устанавливают Новые Службы

Для конечных пользователей (или системные администраторы), кто хочет получить доступ к новой службе через их прикладные программы, установка проста. Они помещают обеспеченный файл JAR в каталог в их CLASSPATH. После выполнения Среда выполнения Java найдет классы, на которые ссылаются, при необходимости.

Это не ошибка установить больше чем одного провайдера для той же самой службы. Например, два различных поставщика услуг могли бы предоставить поддержку чтения того же самого типа звукового файла. В таком случае система произвольно выбирает одного из провайдеров. Пользователи, которые заботятся, какой провайдер выбирается, должны установить только требуемый.