One of the most difficult questions to answer during SOA implementation is how to appropriately define services. An enterprise usually already has a set of applications supporting most of the required business functionality. These applications are implemented using a variety of hardware platforms, operating systems and programming languages. Some of them are stand alone applications, others are integrated using EAI solutions. Some applications are implemented by the enterprise itself and some are implemented by its business partners and are used in the overall processing using B2B solutions. The current application architecture of Orchestra Mortgage  illustrates this common situation.

What"s SOA?  

First, SOA means different things to different people:

• From the point of view of a business executive and business analyst, SOA is a set of services that constitute business IT assets and can be exposed to their customers and partners, or other portions of the organization
• From the point of view of an enterprise architect SOA is an architectural style that promotes the concepts of business processes and the orchestration of enterprise-level business services. It is also a set of architectural principles, patterns and criteria which address characteristics such as modularity, encapsulation, loose coupling, separation of concerns, reuse, composability, etc.
• From the point of view of a project manager SOA is a development approach supporting massive parallel development.
• From the point of view of a tester and/or quality assurance engineer SOA represents a way to simplify overall system testing.
• From the point of view of a software developer SOA is a programming model complete with standards, tools and technologies such as Web Services.
  

First part:  Java Logging tutorial

Package java.util.logging Description (from sun)

Package java.util.logging  provides the classes and interfaces of the JavaTM 2 platform's core logging facilities. The central goal of the logging APIs is to support maintaining and servicing software at customer sites.

There are four main target uses of the logs:

• Problem diagnosis by end users and system administrators. This consists of simple logging of common problems that can be fixed or tracked locally, such as running out of resources, security failures, and simple configuration errors.
• Problem diagnosis by field service engineers. The logging information used by field service engineers may be considerably more complex and verbose than that required by system administrators. Typically such information will require extra logging within particular subsystems.
• Problem diagnosis by the development organization. When a problem occurs in the field, it may be necessary to return the captured logging information to the original development team for diagnosis. This logging information may be extremely detailed and fairly inscrutable. Such information might include detailed tracing on the internal execution of particular subsystems.
• Problem diagnosis by developers. The Logging APIs may also be used to help debug an application under development. This may include logging information generated by the target application as well as logging information generated by lower-level libraries. Note however that while this use is perfectly reasonable, the logging APIs are not intended to replace the normal debugging and profiling tools that may already exist in the development environment.

The key elements of this package include:

• Logger: The main entity on which applications make logging calls. A Logger object is used to log messages for a specific system or application component.
• LogRecord: Used to pass logging requests between the logging framework and individual log handlers.
• Handler: Exports LogRecord objects to a variety of destinations including memory, output streams, consoles, files, and sockets. A variety of Handler subclasses exist for this purpose. Additional Handlers may be developed by third parties and delivered on top of the core platform.
• Level: Defines a set of standard logging levels that can be used to control logging output. Programs can be configured to output logging for some levels while ignoring output for others.
• Filter: Provides fine-grained control over what gets logged, beyond the control provided by log levels. The logging APIs support a general-purpose filter mechanism that allows application code to attach arbitrary filters to control logging output.
• Formatter: Provides support for formatting LogRecord objects. This package includes two formatters, SimpleFormatter and XMLFormatter, for formatting log records in plain text or XML respectively. As with Handlers, additional Formatters may be developed by third parties.

The Logging APIs offer both static and dynamic configuration control. Static control enables field service staff to set up a particular configuration and then re-launch the application with the new logging settings. Dynamic control allows for updates to the logging configuration within a currently running program. The APIs also allow for logging to be enabled or disabled for different functional areas of the system. For example, a field service engineer might be interested in tracing all AWT events, but might have no interest in socket events or memory management.

What is Java Sound?

The Java Sound API specifies mechanisms for capturing, processing, and playing back audio and MIDI (Musical Instrument Digital Interface) data in a framework that promotes extensibility and flexibility.

Sun's reference implementation for the Java Sound API, also known as the Java Sound engine, is a 64 channel audio rendering and MIDI controlled sound synthesis engine which offers reliable, high quality sound on all Java 2 Platforms. This implementation also supports a set of high-quality General MIDI sound banks.

Who needs Java Sound?

Anyone who is interested in adding sound capabilities into their Java applets and applications will benefit from the Java Sound API. Java Sound will enable a wide variety of markets, such as education, advertising and telecommunications, to take advantage of its high quality audio to make communication more effective and accessible.

Where is Java Sound available?

The full featured Java Sound API is available as a core API in the Java 2 SDK, Standard Edition, v. 1.3 and above. The full featured Java Sound API is also available as part of the Java Media Framework 2.x for use on older JDK 1.x platforms.

Please note that the Java 2 Runtime Environment, Standard Edition, v. 1.3 release for Win32 does not include a soundbank. To use the software synthesizer with this release bundle, you must manually install a soundbank. For more information, refer to the Soundbanks page.

This API provides comprehensive access to the features of the Java Sound engine, and allows musicians and sound designers to integrate their work into Java applets and applications.

The Java Sound engine has been integrated into previous releases of the Java 2 platform (formerly known as JDK 1.2), and uses the existing AudioClip interface to access it. This means AudioClips may be created from any of the supported file formats using any of the supported data types.

What are the benefits of Java Sound?

Consistent and Reliable Sound:
Java Sound allows consistent, reliable, high-quality audio on all Java-enabled platforms. Developers have the assurance their audio content will sound great across all platforms, with the only requirement being a simple digital to audio converter (DAC).

CPU Efficient:
Java Sound uses only a small amount of a system's CPU to process sound files. For example: a 24-voice MIDI file uses only 20% of the CPU on a Pentium 90 MHz system.

Complete Audio API:
The fully featured Java Sound API allows total access to the underlying synthesis and rendering engine. This provides musicians with the capability to create new musical instruments and engineers the ability to capture microphone data for telephony or audio conferencing applications.

What audio formats does Java Sound support?

Java Sound supports the following audio file formats: AIFF, AU and WAV. It also supports the following MIDI based song file formats: SMF type 0 (Standard MIDI File, aka .mid files), SMF type 1 and RMF.

The Java Sound engine can render 8 or 16 bit audio data, in mono or stereo, with sample rates from 8KHz to 48KHz, that might be found in streaming audio or any of the supported file formats.

How do you stream audio using Java Sound?

Java Sound can begin playing as soon as it starts getting audio samples or MIDI requests -- there is no need to wait for the entire audio file to be loaded into memory.

Java Sound can be used in conjunction with the Java Media Framework API software (JMF) to stream audio data over the network. Third parties can also use Java Sound to present audio within their own streaming framework.

What other APIs that Sun is creating that relate to Java Sound?

Java Sound is part of a family of APIs that work together to provide customers with enhanced multimedia capabilities.

These APIs include:

Java 2D - two dimensional graphics and imaging
Java 3D - three dimensional graphics and imaging
Java Advanced Imaging - additional graphics and imaging operations which extend Java 2D
Java Media Framework - allows the capture, streaming and playback of time-based media such as audio and video.
Java Shared Data Toolkit - provides collaboration support for Java applets and applications.
Java Speech - speech synthesis and recognition (API only)
FreeTTS free speech synthesizer in Java - speech synthesis (implementation only)

What's New in the Sun Java Wireless Toolkit 2.3 beta

The Sun Java Wireless Toolkit just keeps getting better. Version 2.3 beta adds support for three new APIs:

• The Security and Trust Services APIs (SATSA, JSR 177) allow MIDlets to communicate with smard cards and perform cryptographic functions.
• The Location API (JSR 179) gives MIDlets a way to discover the current location of the device.
• The Content Handler API (CHAPI, JSR 211) provides a mechanism for launching MIDlets based on the type of content a device receives.