Most enterprises have made extensive investments in system resources over the course of many years. Such enterprises have an enormous amount of data stored in legacy enterprise information systems (EIS), so it’s not practical to discard existing systems. It’s more cost-effective to evolve and enhance EIS. But how can this be done? Service Oriented Architecture (SOA) provides a cost-effective solution.

SOA is not a new concept. Sun defined SOA in the late 1990’s to describe Jini, which is an environment for dynamic discovery and use of services over a network. Web services have taken the concept of services introduced by Jini technology and implemented it as services delivered over the web using technologies such as XML, Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP), and Universal Description, Discovery, and Integration(UDDI). SOA is emerging as the premier integration and architecture framework in today’s complex and heterogeneous computing environment. Previous attempts didn’t enable open interoperable solutions, but relied on proprietary APIs and required a high degree of coordination between groups. SOA can help organizations streamline processes so that they can do business more efficiently, and adapt to changing needs and competition, enabling the software as a service concept. eBay for example, is opening up its web services API for its online auction. The goal is to drive developers to make money around the eBay platform. Through the new APIs, developers can build custom applications that link to the online auction site and allow applications to submit items for sale. Such applications are typically aimed at sellers, since buyers must still head to ebay.com to bid on items. This type of strategy, however, will increase the customer base for eBay.

SOA and web services are two different things, but web services are the preferred standards-based way to realize SOA. This article provides an overview of SOA and the role of web services in realizing it. The article provides:

* An overview of software as a service
* A tutorial on SOA
* An overview of Sun’s platforms for building web services
* Guidelines for designing interoperable web services
* Challenges in moving to SOA
* An overview of Java Business Integration (JSR 208)
* A discussion of web services for enterprise application integration

Service-Oriented Architecture

SOA is an architectural style for building software applications that use services available in a network such as the web. It promotes loose coupling between software components so that they can be reused. Applications in SOA are built based on services. A service is an implementation of a well-defined business functionality, and such services can then be consumed by clients in different applications or business processes.

SOA allows for the reuse of existing assets where new services can be created from an existing IT infrastructure of systems. In other words, it enables businesses to leverage existing investments by allowing them to reuse existing applications, and promises interoperability between heterogeneous applications and technologies. SOA provides a level of flexibility that wasn’t possible before in the sense that:

* Services are software components with well-defined interfaces that are implementation-independent. An important aspect of SOA is the separation of the service interface (the what) from its implementation (the how). Such services are consumed by clients that are not concerned with how these services will execute their requests.
* Services are self-contained (perform predetermined tasks) and loosely coupled (for independence)
* Services can be dynamically discovered
* Composite services can be built from aggregates of other services

SOA uses the find-bind-execute paradigm as shown in Figure 1. In this paradigm, service providers register their service in a public registry. This registry is used by consumers to find services that match certain criteria. If the registry has such a service, it provides the consumer with a contract and an endpoint address for that service.

SOA-based applications are distributed multi-tier applications that have presentation, business logic, and persistence layers. Services are the building blocks of SOA applications. While any functionality can be made into a service, the challenge is to define a service interface that is at the right level of abstraction. Services should provide coarse-grained functionality.
Realizing SOA with Web Services

Web services are software systems designed to support interoperable machine-to-machine interaction over a network. This interoperability is gained through a set of XML-based open standards, such as WSDL, SOAP, and UDDI. These standards provide a common approach for defining, publishing, and using web services.

Sun’s Java Web Services Developer Pack 1.5 (Java WSDP 1.5) and Java 2 Platform, Enterprise Edition (J2EE) 1.4 can be used to develop state-of-the-art web services to implement SOA. The J2EE 1.4 platform enables you to build and deploy web services in your IT infrastructure on the application server platform. It provides the tools you need to quickly build, test, and deploy web services and clients that interoperate with other web services and clients running on Java-based or non-Java-based platforms. In addition, it enables businesses to expose their existing J2EE applications as web services. Servlets and Enterprise JavaBeans components (EJBs) can be exposed as web services that can be accessed by Java-based or non-Java-based web service clients. J2EE applications can act as web service clients themselves, and they can communicate with other web services, regardless of how they are implemented.

source : http://java.sun.com/developer/technicalArticles/WebServices/soa/

“Lots of websites use audio for multiple purposes. Here’s a brief tutorial on how to use audio on your own site.

Upload it

Naturally, the first step is to upload the audio file. Just use your ftp to upload the file as you would any other, and remember the audio file’s url. Also, take into account the file size. Different types of audio files tend to have different sizes and smaller ones function better. Midis are generally the best, though .wav and .au files can hold more.

Link to it

One way to have audio on your page is to link to it. Any savvy HTML user knows the code to create a link. It will look like this:

{a href=”xyz.wav”}Text here{/a}

Where “xyz.wav” is the audio file’s url and “Text here” is what will appear as a link. Naturally, use > and < in place of } and {. I only use those to avoid auto-formatting.”

Read the full article at Associated Content. Decide which method is best for your web page today.

“CSS2 gives you three basic ways of choosing colours: hexadecimal, keywords and rgb.

Hexadecimal notation

You probably already know how the hexadecimal notation looks, for each colour (Red, green and blue) you have two letters or digits, and in front of that a #. The higher the digits are, the brighter the colour. Pure black becomes #000000 while pure white becomes #FFFFFF.

But what do those digits actually mean? Hexadecimal notation uses a system of 16 digits. Because we only have 10 digits, the remaining 6 (they start at 0) are described using the letters A to F. Together, this allows for 256 numbers per primary colour. Those 256 numbers correspond with the current RGB colours in most screens, and allow for about 16 million different colours.

Next to the #rrggbb notation, there also is the #rgb notation that lets you pick red, green and blue with 16 increments, totalling 4096 colours. This means that #ff0000 and #f00 give the same colour.

RGB Notation

Another notation that has been in CSS for a while is “direct” RGB. It looks like this: rgb(255, 0, 0) for 100% red, 0% green and 0% blue. As you might already have guessed, this notation also uses 256 steps for each of the primary colours.

The only difference (apart from the syntax) is that RGB uses our own system of counting, while hexadecimal notation uses an alternative method. In theory, it’s easier to use the RGB notation because we understand it better. But when working with hexadecimal notation, it is my experience that you learn to think in 16 digits pretty quickly.”

Read the full article hosted by Kilina Valkhof’s personal blog and master the art of color control for your web page.

This document specifies the second version of the Synchronized Multimedia Integration Language (SMIL, pronounced “smile”). SMIL 2.1 has the following design goals:

* Define an XML-based language that allows authors to write interactive multimedia presentations. Using SMIL, an author can describe the temporal behaviour of a multimedia presentation, associate hyperlinks with media objects and describe the layout of the presentation on a screen.
* Allow reusing of SMIL syntax and semantics in other XML-based languages, in particular those who need to represent timing and synchronization. For example, SMIL components are used for integrating timing into XHTML [XHTML10] and into SVG [SVG].
* Extend the functionalities contained in the SMIL 2.0 [SMIL20] into new or revised SMIL 2.1 modules.
* Define new SMIL 2.1 Mobile Profiles incorporating features useful within the mobile industry.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a Recommendation of the W3C. It has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C’s role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

This SMIL 2.1 edition is a new version, it extends the functionalities contained in SMIL 2.0 [SMIL20], incorporating new features useful within the mobile industry.
This SMIL 2.1 W3C Recommendation supersedes the 07 January 2005 SMIL 2.0 Recommendation (Second Edition) [SMIL20].

The SMIL 2.1 test suite along with an implementation report are publicly released and are intended solely to be used as proof of SMIL 2.1 implementability. It is only a snapshot of the actual implementation behaviors at one moment of time, as these implementations may not be immediately available to the public. The interoperability data is not intended to be used for assessing or grading the performance of any individual implementation.

This document has been produced by the SYMM Working Group as part of the W3C Synchronized Multimedia Activity, following the procedures set out for the W3C Process. The goals of the SYMM Working Group are discussed in the SYMM Working Group Charter.

The patent policy for this document is the 5 February 2004 W3C Patent Policy. Patent disclosures relevant to this specification may be found on the SYMM Working Group’s patent disclosure page.

An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.

The authors of this document are the SYMM Working Group members. Different parts of the document have different editors.

Please report errors in this document to www-smil@w3.org - (public archives) including the prefix’[SMIL21 REC]’ in the subject line.

source : http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil21.html

Abstract
Lark is a non-validating XML processor implemented in the Java language; it attempts to achieve good trade-offs among compactness, completeness, and performance. Larval is a validating XML processor built on the same code base as Lark. This report gives an overview of the motivations for, facilities offered by, and usage of, the Lark processor.

This document and the Lark software are copyright © 1997 by Tim Bray; all rights reserved. However, Lark is available on the Internet for general public use.

This note applies to the final beta of version 1.0 of Lark, and release 0.8 of Larval, in use in January 1998. In this note, the name Lark refers to both Lark and Larval, unless otherwise noted.

Why Lark?
1 Motivations:

Lark’s creation was driven by the following motivations:

Personal Gratification
Writing language processors is fun, particularly when you have the chance to fix the language.
Desire to Learn Java
It’s about time, and Java seems like the appropriate language for the job.
Test Compliance with Design Goals
In particular, XML Design Principle #4, which states that “It shall be easy to write programs which process XML documents.”
Expore the API Design Space
There is a chance, while XML is young, to make some real progress in the design of processor API’s. The design of Lark makes very few assumptions about the user interface; thus Lark should be useful as an experimental testbed in this area.
$$$
Perhaps Lark will turn out to be useful. I have not the slightest desire to start another software company (been there, done that, got the T-shirts), but it would be nice to figure out a way to get paid for the time I’ve put in writing it.

2 Conclusions:
Yes, writing Lark was fun. In particular, none of the innocent-looking things in XML turned out, in practice, to be too horribly difficult. And Java is indeed a Happy Hunting Ground for programmers.

On the design-goal-compliance front, the good news is that if you wanted a program to process XML that you knew was well-formed, you could probably bash it out in perl (don’t know about Java) in a day or so. On the other hand, if you want to build a general-purpose tool that does all of XML and provides helpful error messages and a useful API, the nominal week is not nearly enough. The development of Lark has consumed about a month at this point in time, stretched over a year’s elapsed time.

I do think that Lark will be useful for exploring API designs. Of course, none of this will happen unless there are people out there who want to use an XML processor for something or other. Among other things, Lark currently has no user interface at all; while I don’t mind editing the Driver.java file and recompiling to run tests, presumably a UI would be a good thing to have.

As for the financial aspects, I’m kind of gloomy. I think most XML processors are going to be purpose-built for the needs of particular applications, and will thus hide inside them. Which is good; XML’s simplicity makes this approach cost-effective. Failing that, processors will be full-dress validating parsers with incremental parsing for authoring support. So I’m not sure that there’s all that much need for a standalone processor; but I’d love to be wrong.

Just in case, for the moment I’m going to be giving away all the .class files, and some of the Java source code, but not the source code for the three classes with the hard bits. In any case, they’re sure to be buggy at this stage and I wouldn’t want to be letting them out of my hands with a bit more polishing. If you can see a way to get a little revenue out of this project, give me a call.

Lark Feature Set Overview:

1 Compactness
(The figures below refer to Lark 0.97; they will be updated for 1.0 when it comes out of final beta status.)

Since an XML processor is often going to run on the client and presumably need to be delivered over the network, it must be compact. At the moment, the total byte count is around 45K, which is not too bad.

There is some more scope for compression, when some useful facilities appear in the Java class libraries that ought to be there; e.g. usable symbol table and better Unicode support.

2 Performance
At the moment, Lark, running under the Win95 J++ “Jview” application viewer on an underconfigured P100 notebook, runs at about 200K/second. I am fairly happy with this performance, and doubt whether a full-featured processor implemented in Java can really be made to run much faster.

3 Completeness
Lark is a processor only; it does not attempt to validate. It does read the DTD, with parameter entity processing; it processes attribute list declarations (to find default values) and entity declarations. Lark is relatively full-featured; it implements (I think) everything in the XML spec and reports violations of well-formedness.

Lark’s error-handling is draconian. After encountering the first well-formedness error, no further internal data structures are built or returned to the application. However, Lark does continue processing the document looking for more syntax errors (and in fact performing some fairly aggressive heuristics on the tag stack in order to figure out what’s going on), and calling the doSyntaxError application callback (see below) to report further such errors.

Larval is a full validating XML processor; it reports violations of validity constraints, but does not apply draconian error handling to them.

4 API
Lark presents as a set of Java classes. Those named Element, Attribute, and Entity are obvious in their function. One lesson of this activity is that it may be possible for such classes to be shared independent of the parser architecture; it would be very handy if all XML-processing Java apps used the same Element class, at least as a basis for subclassing.

The Text and Segment classes do Lark’s character data management; details are below.

From an application’s point of view, the Lark and Handler classes are central. Handler has methods such as doPI, doSTag, doEntityReference, doEtag; the application passes a Handler instance to Lark’s readXML method, and Lark calls the routines as it recognizes significant objects in the XML document. The base class provides do-nothing methods; the intent is that an application would subclass Handler to provide the appropriate processing semantics.

Along with presenting this event stream to the application, Lark can optionally build a parse tree, and if so doing, can optionally save copies of the XML document’s character data, all in parallel with providing the event stream. Lark provides methods to toggle these behaviors. These methods may be used in the Handler callbacks while Lark is running, to build the parse tree or save the text for only a subset of the document.

In building the parse tree, Lark is guaranteed to update only elements which are still open; i.e. for which the end-tag has not been seen. All other sections of the tree, and the entire tree once Lark has hit end-of-file, may be manipulated freely by the application.

An instance of Lark may be initialized with an optional list of element GI’s which are to be considered as those of empty elements, whether or not the XML “/>” syntax is used. A typical set might begin: “HR”, “BR”, “IMG”, ….

Another initializer allows a set of entities to be predefined.

Lark also provides the application access to the “entity tree”; there is a method that toggles whether Lark attempts to retrieve and parse external entities.

5 Error Handling
Lark makes a serious effort to be robust, by providing useful error messages and continuing to do so after the first error. The error handling is good enough that I now use Lark as my primary tool to debug broken XML files.

6 Text Segment Management
Probably due to my background in the indexing and search business, Lark pays more attention than is perhaps strictly necessary to the location of objects within the XML file. Lark informs the application of the containing entity and begin/end offsets of each element. A chunk of character data in an element, which may look contiguous to an application, may in fact map to several different byte ranges in different entities, due to the effect of entity references. Also, the use of encodings such as UTF8 may cause the number of bytes of underlying document to differ from the number of bytes that makes up the characters in a chunk of text. Lark represents Text objects as a vector of Segment objects, each of which gives information about the source offset and length, and the number of characters in the segment. If text-saving has not been turned on, the segments contain no character data, but still contain the offset information.

7 Entity Handling
Lark does full XML entity handling. Java provides facilities which make this trivially easy. The application can turn the inclusion of external text entities on and off. Lark makes no use of PUBLIC identifiers, aside from passing them to the callback in the Handler upon recognizing the declaration.

8 Concurrency
Lark is thread-safe. Multiple Larks can run in parallel threads, with other threads doing useful processing of under-construction document trees.

source: http://www.textuality.com/Lark/

XML can be considered as a representation of hierarchical data, and the XML-related standards - as methods of processing such data. We describe benefits of XML view on legacy data and its processing, and suggest a method to develop XML tools and make them reusable for different tree-like structures in different programming languages.
Our approach is to use virtual machine technology, in particular, the Scheme programming language. We’re taking the unusual step of using the Scheme syntax itself as a native virtual machine language. Together with the SXML format and Scheme implementations tuning, it gives us the XML virtual machine (XML VM).
Reference implementations are ready for the Python and C languages. We describe a library for XSLT-like transformations of the Python parse trees and a special version of the GNU find utility which supports XPath queries over the file system.

The basis of some applications is hierarchical data structures plus methods of processing the data. Possible examples are compilers, interpreters and text processors. The former two may use abstract syntax trees (ASTs) to represent results of parsing a program and some other trees to deal with code transformations. Text processors may use trees to represent the structure or the formatting properties of a document.
Although the applications are from different domains, the basic operations on trees are the same. For example, getting list of children is a standard functionality for any tree. Some more advanced operations (for example, getting children with filtering) are also common. The problem is that possibly complex code for the advanced operations should be written and being updated for all the tree models, so maintenance become nightmare.
The possible solution for elimination of code duplication is to unify the tree models. As XML is now extremely popular, it’s reasonable to choose XML as an universal representation for trees. For needs of our work, the most fruitful feature of XML is existence of XML-related standards which in fact are design patterns for tree processing. And one of the most useful standards is XPath. In this paper, we give examples of XML and XPath and discuss benefits of seamless use of XML tools in legacy applications.

Read more on: http://uucode.com/texts/genxml/genxml.html