Silex-- A new Approach

Silex is an open source RIA that enables you to build Flash websites for Flash Player 7, 8, 9, and 10. Silex is a new kind of CMS, a mix between an editing software like the Adobe Creative Suite, and Wiki based software. All multimedia file formats -- images of all kinds, texts, videos with chapters and subtitles, audio and playlists, 3D animations, .pdf files, etc. can be assembled in Silex WYSIWYG editor to publish online, on a local computer, or on a CD-R. Silex can be used to display all types of data -- either static or dynamic -- from text files, databases, a CMS, blog, Web TVs, etc. HTML and Flash are both supported by Silex. Search engine support is provided by generating an HTML equivalent on the fly of the contents of Silex web sites as if they were HTML web sites. You can get more details on the official Silex site.

Another Hectic Day

Again it gonna be a hectic day at office..

when i opened the mailbox a bunch of mails were waiting for me.. adn the full 10-12 hours of schedule was there :(

Lets hope for a not too busy weekend.. thinking go hometown adn catch up with few old friends !!

The whole week ends in the Work

Also i have gone thru few interesting topics. For some of my friends it may be a crap kinda stuff :)

Sprituality-- Osho's History, Swami Vivekanand's Teachings adn Speeches, A tak between Ishwar Chand Vidyasagar and Master Ramakirshan Paramhans.

Technical Front--(not much).. but tried to make music player kinda thing :) in flash.. completed 70% now stuffed in between the as classes.. , gone thru ATOM and RSS fields patterns and yes the GutterShark Framework as well..

Celebrating Father's Day

My special DAD

I always search for you,
because you feel I can do.
You are always there
to help me grow
encouraging me
in all my show.
I know I will never fail,
Because you are always there.
Holding my finger tight,
to teach me walk always right.
You care like a mother,
play with me like a brother.
Your affection is like a sister,
What else can be better.
Your dedication to the family,
is as great as sky blue
Every work you do ,
Your dedication is always true.
I thank GOD to give me,
a wonderful gift like You.
I wish if next birth is true,
You are always my DAD
and I am always your LAD. :)

USB 3.0

USB 3.0 specifications were announced in November by Intel and Intel developer Sarah Sharp has been busy coding the linux drivers ever since. The drivers have been ready and have been scheduled to be merged with the Linux mainstream kernel in the version 2.6.31. Traditionally it has always been that Windows is the first OS to get the hardware drivers and the linux geeks tend to reverse engineer or design it based on the specification but this time around tables have been turned over.

The support of Intel to mainstream linux and to the development of open hardware drivers does seem to be a road of change on the part of the hardware manufacturers who have traditionally been windows centric.

The USB 3.0 hardwares have not made to the market yet although NEC is producing 1 million xHCI PCI-Express add-in cards for september release.

Sarah is also working to ensure that these drivers make it to mainstream distributions like Redhat and Ubuntu, according to the post on her blog.

For those who do not know USB 3.0 specification gives a 10x increase over the existing USB standard delivering a transfer rate of 5.0Gbps. You can read further details here: http://en.wikipedia.org/wiki/USB#USB_3.0

For those who live on the edge and want to test out the drivers(in case you are the lucky few with the hardware), head on to The Geekess blog at http://sarah.thesharps.us/2009-06-09-13-30.cherry and follow her instructions. For those who would like to wait, wait for the next kernel release.

FEW MORE AS QUESTIONS

Disadvantages of event dispatcher.

Linkage between components.

What are v2 components.

What are mxp and mxi file and how they r relate to swc file.

Do we have method overloading and operator overloading in flash,

Any workaround on method or class overloading.

Can we exclude our as file not to be included during the runtime or can we specify to the debugger which as file to use or not.

How garbage collector works in flash.

Can we use interfaces in flash.

How do we implement MVC pattern.

How do we use observer pattern.

How we create the custom components.

Any experience on as editor or any other IDE.

Any experience on third party compilers.

What OOPS things were not there in as2 which are added to as3.

What is delegate class.?

How we use getter and setters methods in component designing.?

How we integrate our as files with the fla file.

What is linkage.

What type of polymorphism is being supported by flash.?

Load movie and load movienum

Diff. between stage and root.

Diff. between sealed classes and dynamic classes.

Exception handling methodology in flash.

What is external interface class.

How we add the page in the printjob class.

What is the way the print job class works .

AS3 INTERVIEW QUESTIONS

--External Interface Class

--Diff. between Overloading and Overriding

--Can we have overloading in flash?

--Do we need to override the function in same class or the different class.?

--How we start and stop video playback?

--How we load a audio , play, pause and stop, resume etc.

--Explain the sound object and How do we use it.?

-- Explain Design Patterns.?

--Diff. between Design patterns and Frameworks.?

--Whats OOP..?-- the famous borng question ever :)

--How we implement OOP approach.?

--Is as2 OOP based.?

--Do we have packages in as2.?

--How do we can achieve flash and client side communication.?

--How to communicate between flash and javascript.?

--Do we have fscommand in as3.?

A lot of others coming soon..

Adobe Flash Collaboration Service aka Cocomo

AFCS (Adobe Flash Collaboration Service) previously known as 'Cocomo' is a Platform as a Service (PaaS) that that allows Flex developers to address a class of applications known as collaborative applications.

Collaborative Applications have progressed from a nice cool thing into serious applications. Almost all of us would have participated in an online chat or a web meeting, which allows a group of users to chat, share files, do screen sharing, take polls, ask questions and receive answers, etc. AFCS aims to lower the barrier to entry for developers to bring such collaborative features into their applications.

A developer would have general questions like:

• Why do we need a set of components to enable collaborative features in my application?
• It should not be that complex to build a collaborative application, right? Isn't chat and sharing some files the maximum that I would want?
• …and many more.

Well, building collaborative applications is not as simple as it sound. If you wish to build a collaborative application - you will need to consider the following in your application:

• Handle Audio, Video and all other forms of transcoding data
• Ensure that your application can scale to a large number of users.
• Enable shared state in your application and ensure that multiple users are co-coordinated with each other so maintain data integrity
• Reuse commonly used components like chat, notes, whiteboard, etc so that you can build the applications quickly and not reinvent the wheel.
• Handle User Management and Permissions

Courtesy-- TechRepublic!!!!!!!!!!!!!!!

Apache Pivot

What is Apache Pivot?

Apache Pivot is an open-source platform for building rich internet applications in Java. It combines the enhanced productivity and usability features of a modern RIA toolkit with the robustness of the Java platform. Pivot applications are written using a combination of Java and XML and can be run either as an applet or as a standalone, optionally offline, desktop application.

Like other modern development platforms, Pivot provides a comprehensive set of foundation classes that together comprise a "framework". These classes form the building blocks upon which more complex and sophisticated applications can be built.

Who is Pivot's target audience?

Pivot was designed to be familiar to web developers who have experience building AJAX applications using HTML, CSS, and JavaScript. However, it provides a much richer set of standard widgets than HTML, and allows developers to create sophisticated user experiences much more quickly and easily. Pivot will also seem familiar to Swing developers, as both Swing and Pivot are based on Java2D and employ a model-view-controller (MVC) architecture to separate component data from presentation. However, Pivot includes additional features that make building modern GUI applications much easier, including declarative UI, data binding, effects and transitions, and web services integration.

Why RIA?

The web has become the defacto standard method for application delivery. However, functional requirements for web applications have begun to scale beyond the capabilities of the browser. Even with the addition of scripting support, dynamic element manipulation, and asynchronous server communication, it is difficult to create a user experience in HTML that is truly on par with that of a desktop application.

Rich internet application (RIA) development platforms are a means of bridging the gap between the web and desktop experiences. Using browser plugins, these platforms allow developers to build applications that look and feel more like native desktop applications but are deployable via the web, like traditional, HTML-based web applications. RIAs also often incorporate visual effects intended to enhance the overall user experience, such as animations and other dynamic behavior.

Adobe Flex and Microsoft Silverlight are arguably the most high-profile of these platforms; others include OpenLaszlo and Curl. Pivot itself falls into this category.

Why Pivot?

Pivot was created for two primary reasons:

• To provide a viable option for developers who want to build rich client applications in Java. Flex applications are written in ActionScript, an ECMAScript variant; Silverlight applications can be written in either C# or JavaScript; OpenLaszlo applications are written in JavaScript. Pivot allows developers to write rich internet applications in Java (or any other language that can run in a JVM).

• To provide a freely-available, open source alternative for RIA developers. Flex, Silverlight, and Curl are all proprietary platforms. We believe that a large part of HTML's success was its due to its openness. While we certainly hope that developers will use Pivot to build revenue-generating products and applications, we believe that the platform itself should be free and driven by its technological merits, not by corporate objectives.

Where did Pivot come from?

Pivot began as an R&D effort at VMware in 2007. It was announced as an open-source project in June of 2008 under the Apache 2.0 license. Version 1.0 was released in October, 2008, and version 1.1 in April, 2009. Work is currently underway on version 1.2, scheduled for release in mid 2009.

What platforms does Pivot support?

Pivot applications run on any operating system with a Java Virtual Machine (JVM) version 5 or greater. They can be run locally as Java desktop applications or via the web using the Java plugin.

Who is developing Pivot?

Pivot has been developed primarily Greg Brown and Todd Volkert of VMware. However, it is a community-driven effort that has recieved contributions from a number of developers around the world. An RIA platform is a large undertaking that needs the support of a larger developer base if it is to succeed and thrive. Interested developers are encouraged to participate; information on how to do so is available on the Pivot home page.

How does Pivot compare to Swing?

While it is technically feasible to build an RIA in Java using the Swing toolkit, Pivot offers a number of advantages that make it a more compelling, modern alternative:

• Pivot provides an XML markup language called WTKX for simplifying user interface construction. Flex, Silverlight, and OpenLaszlo all offer a similar feature; web developers are comfortable with the markup metaphor, and it can considerably reduce overall development time.

• Components are not limited to an "atomic" preferred size; they are allowed to report a preferred size as constrained by either width or height - this facilitates such features as label wrapping, which Swing does not support.

• Pivot employs a consistent data model that is used throughout the entire framework; for example, JSON data returned from a REST service is serialized into the same data structures used by a table view component to present data. No additional translation is necessary, which can significantly improve performance. A common data model also reduces the learning curve for new developers.

• Pivot includes built-in support for REST-based data services, which Pivot calls "web queries". This provides parity with Flex, which comes with out-of-the-box support for RPC via the AMF protocol, and Silverlight, which supports both SOAP and REST-style services. Swing does not include any built-in facilities for server communication, making it less convenient to work with.
  Note, however, that Pivot is not limited to REST for server communication. Because it runs in a JRE, a Pivot application can take advantage of any client/server protocol that has a Java API; for example SOAP-based services via Axis or Flex RPC using the BlazeDS AMF client.

• Pivot includes built-in data binding support, which allows data returned from web queries (as well as other types of data services) to easily be mapped to form contents.

• Pivot includes (and takes advantage of) platform-level support for visual effects and transitions (i.e. animations).

• Pivot applications are inherently resolution independent. Bitmapped and vector images are interchangeable, and the entire user interface can be scaled to take advantage of high-resolution displays or for accessibility purposes.

• Pivot defines a single Application inteface that is used for launching both desktop and web-based applications - multiple codebases for applets and applications are not required.

• Because it requires Java 5, Pivot is able to take advantage of newer Java language features such as generics, enums, for..each loops, and annotations.

How does Pivot compare to JavaFX?

Fundamentally, Pivot and JavaFX appear to be serving two different use cases. Pivot is designed primarily to address the "Application" in "RIA", whereas JavaFX appears to be geared more towards the "Rich" part of the acronym. This isn't to say that the two are mutually exclusive - Pivot supports a variety of features for adding visual richness to an application. However, Pivot is first and foremost a tool for creating applications - animations and other effects are primarily intended to enhance the user experience of those applications, not serve as simple eye-candy.

Pivot additionally differentiates itself from JavaFX by allowing developers to build applications in Java, rather than the JavaFX scripting language. Finally, JavaFX's widget support is based on Swing, which suffers from the limitations outlined above.

In a sense, Pivot represents what we think Sun should have done instead of JavaFX.

How does Pivot compare to the Google Widget Toolkit (GWT)?

While GWT allows developers to use the Java language to write web-based applications, the runtime enviroment for a GWT application is the browser itself, not a JVM. This has a number of drawbacks:

• The compiled code executes as interpreted JavaScript, not bytecode.

• The only libraries available are those that have been ported to GWT by Google.

• All presentation must be done via CSS and DOM manipulation rather than via a true 2D drawing API.

• Additionally, GWT does not support an XML markup language - all UI elements must be created programmatically.

Pivot allows developers to efficiently construct RIAs that can truly take advantage of the Java platform.

Multiple Inheritance in Java and Delegate Factory pattern

When Sun was designing Java, it omitted multiple inheritance - or more precisely multiple implementation inheritance - on purpose. Yet multiple inheritance can be useful, particularly when the potential ancestors of a class have orthogonal concerns. This article presents a utility class that not only allows multiple inheritance to be simulated, but also has other far-reaching applications.

Have you ever found yourself wanting to write something similar to:

public class Employee extends Person, Employment {
// detail omitted
}

Here, Person is a concrete class that represents a person, while Employment is another concrete class that represents the details of a person who is employed. If you could only put them together, you would have everything necessary to define and implement an Employee class. Except in Java - you can't. Inheriting implementation from more than one superclass - multiple implementation inheritance - is not a feature of the language. Java allows a class to have a single superclass and no more.

On the other hand, a class can implement multiple interfaces. In other words, Java supports multiple interface inheritance. Suppose the PersonLike interface is:

public interface PersonLike {
String getName();
int getAge();
}

and the EmployeeLike interface is:

public interface EmployeeLike {
float getSalary();
java.util.Date getHireDate();
}

If Person implements the Person-Like interface, and Employment implements an EmployeeLike interface, it's perfectly acceptable to write:

public class Employee implements PersonLike, EmployeeLike {
// detail omitted
}

Here there is no explicit superclass. Since we are allowed to specify at most one superclass, we could also write:

public class Employee extends Person implements PersonLike, EmployeeLike {
// detail omitted
}

We would need to write the implementation of EmployeeLike, but the implementation of PersonLike is taken care of through the Person superclass. Alternatively we might write:

public class Employee extends Employment implements PersonLike, EmployeeLike{
// detail omitted
}

This is the opposite situation: the EmployeeLike interface is taken care of through the Employment superclass, but we do need to write an implementation for PersonLike.

Java does not support multiple implementation inheritance, but does support multiple interface inheritance. When you read or overhear someone remark that Java does not support multiple inheritance, what is actually meant is that it does not support multiple implementation inheritance.

Stay Adaptable
Suppose then that you have the concrete implementations Person, which implements the PersonLike interface, and Employment, which implements the EmployeeLike interface. Although only one can be selected to be the superclass, it would be useful to somehow exploit the other implementation.

The easiest way to do this in Java is by applying the (Object) Adapter pattern. If we make Person the superclass, we can use Employment using an object adapter held within the employee:

public class Employee extends Person implements PersonLike, EmployeeLike {
private EmployeeLike employment = new
Employment();
public float getSalary() { return
employment.getSalary(); }
public java.util.Date getHireDate() { return employment.getHireDate(); }
}

For each method of EmployeeLike, the employee delegates to the object adapter. This helps motivate the decision as to whether Person or Employment should be the superclass; choose the one with the most methods as the superclass so there will be less manual delegation code to write when dealing with the other interface.

The Adapter pattern is a fine way to support multiple interface inheritance while exploiting two concrete implementations. Indeed, it's more often the case that an anonymous inner class is used as the object adapter, allowing customization of behavior with respect to the context (of being embedded within a subclass).

However, writing that delegation code is tedious, especially if both interfaces to be implemented have many methods in them. In many cases, we can get Java to do the delegation to the would-be superclass(es) automatically.

Enter Dynamic Proxies
Dynamic proxies were introduced into Java in J2SE v1.3. Part of the java.lang.reflect package, they allow Java to synthesize a class at runtime. The methods supported by this synthesized class are specified by the interface (or interfaces) that it implements. The implementation is taken care of through an invocation handler (java.lang.reflect.InvocationHandler) that is handed an object representing the method being invoked (java.lang. reflect.Method). As you can see, dynamic proxies use heavy doses of the Java Reflection API.

This then is the key to simulating multiple implementation inheritance within Java. We can write a custom InvocationHandler that is constructed with a set of classes; these represent the superclasses of the subclass to be synthesized. The interface(s) of our subclass will be the union of the interfaces implemented by these superclasses. Our InvocationHandler will instantiate instances of these superclasses so that it can delegate to them. We then arrange it so that the invocation handler, on being given a method to be invoked, will reflectively invoke the method on the appropriate superclass object instance. (There must be one; remember the subclass's interface is derived from the superclass's, so at least one superclass must be able to handle the method invocation.)

To make things simple, we can make our InvocationHandler implementation also return the proxy. In other words, the invocation handler can act as a factory, able to return instance(s) of the synthesized subclass that will delegate to the superclass instances. We call our invocation handler implementation DelegatorFactory for this reason:

// imports omitted
public final class DelegatorFactory
implements InvocationHandler {
public Object getObject() {
return Proxy.newProxyInstance(
this.getClass().getClassLoader(),
getSupportedInterfaces(),
this);
}
}
// code omitted
}

The supported interfaces of the resultant object are derived from the superclasses provided in the DelegatorFactory's constructor:

// imports omitted
public final class DelegatorFactory implements InvocationHandler {
public DelegatorFactory(final Class[]
ancestors) {
// implementation omitted
}
// code omitted
}

There is more to DelegatorFactory as we shall soon see, but we now have enough to simulate multiple implementation inheritance. Going back to the question first posed, instead of:

public class Employee extends Person, Employment {
// detail omitted
}

followed (presumably) by:

Employee employee = new Employee();

We can instead write:

Object employee =
new DelgatorFactory(
new Class[] {
Person.class,
Employee.class
}
).getObject();

Although the syntax is somewhat different, the same essential information is being provided. That is, the concrete implementations are provided in Person and in Employment. This object will use the implementation of Person if invoked as a PersonLike, and the implementation of Employment if invoked as an EmployeeLike:

((PersonLike)employee).getAge();
((EmployableLike)employee).getHireDate();

How Convenient
In the above example, the casts are necessary because the getObject() method of DelegatorFactory can only return a reference of type java.lang.Object. But the clunkiness arises because our original aim of defining the Employee class with two concrete superclasses actually does something else as well:

public class Employee extends Person, Employment {
// detail omitted
}

Not only does this indicate that the implementation of Employee should be based on that of its superclasses, it also defines Employee as a type. In other words, it's then possible to write:

Employee employee;

What is missing in our dynamic proxy solution is this definition of type. Let's first do that in the usual way. As shown in Figure 2, we don't need to use a class though; an interface is sufficient.

As code, this is simply:

public interface Employee extends PersonLike, EmployeeLike { }

There is no detail omitted here; this is our complete definition. Note that Employee is now an interface and not a class. The following will not work, however:

Employee employee =
(Employee)
new DelegatorFactory(
new Class[] {
Person.class,
Employment.class
}
).getObject();

This is because the only interfaces implemented by the dynamic proxy returned by getObject() are PersonLike and EmployableLike. No matter that logically the Employee interface does not require any additional implementation from our dynamically created object; Employee is not an interface that we can cast to. However, DelegatorFactory does provide an alternative constructor:

Employee employee =
(Employee)
new DelegatorFactory(
new Class[] {
Person.class,
Employment.class
},
Employee.class
).getObject();

Note the new second argument (Employee.class) to the constructor. Casting the object returned from getObject() to Employee will now work. Behind the scenes, the Delegator- Factory simply adds this interface to the set of those to be implemented by the dynamic proxy. Note that Delegator Factory takes this interface object on trust: there is no validation that the interface doesn't introduce any new methods that are not already present in the interfaces of the superclasses.

Initializing the Superclasses
In "regular" Java, if a superclass does not provide a no-arg constructor, it's necessary for the subclass to correctly initialize the superclass using constructor chaining. Normally this is done by including the superclass's constructor's argument(s) in the subclass's constructor's argument(s), and then passing them up the class hierarchy using super().

The facilities shown in Delegator-Factory thus far do not support this. The DelegatorFactory is given a list of superclasses, and then instantiates an instance of each (to delegate to) using java.lang.Class.newInstance(). This requires a public no-arg constructor to exist.

If the would-be superclass does not offer a public no-arg constructor, the DelegatorFactory should be instantiated using a different constructor that takes preinstantiated superclass instances:

Person person = new Person("joe", 28);
Employment employment =
new Employment(someCalendar.getTime(),
30000);
Employee employee =
(Employee)
new DelegatorFactory(
new Object[] {
person, employment
},
Employee.class
).getObject();

If the would-be superclass does not have a public constructor, or is abstract, a custom subclass (probably an anonymous inner class) should be instantiated and used instead.

Dealing with Diamonds
Typically, multiple implementation inheritance is used when the superclasses have orthogonal concerns. Certainly this is the case with PersonLike and EmployeeLike, and each method is unambiguous as to which ancestor it relates to.

However, sometimes there may be a common super-interface in the interfaces implemented by the "superclasses." For example, suppose we have the concrete class, Car, which implements Driveable, the Boat class, which implements Sailable, and both Driveable and Sailable extend from Steerable. Since we want to use both Car and Boat to define a new subclass, we will also introduce a convenience interface, AmphibiousCar (see Figure 3).

The steer() method of Steerable is used to alter the bearing (0 to 359 degrees) of the steerable object. The getBearing() method, of course, should return this bearing.

For simplicity, the drive() method of Driveable and the sail() method of Sailable return a suitable string indicating the current bearing. Invoking drive() might return a string such as:

driving at bearing 30 degrees.

From what we currently know, we would create an amphibious car object using:

AmphibiousCar ac =
(AmphibiousCar)
new DelegatorFactory(
Class[] {
Car.class, Boat.class
}).getObject();

What happens if we invoke the steer() method on our new amphibious car ac? Should the invocation handler delegate to the Car superclass object or the Boat? The default behavior is to delegate to the first matching object. Hence, we will get:

ac.steer(30);
System.out.println(ac.drive());
// prints "driving at bearing 30 degrees"
System.out.println(ac.sail());
// prints "sailing at bearing 0 degrees"

The Boat superclass component of our class never knew that the bearing had changed.

It's this kind of problem that persuaded the Java language designers to exclude multiple implementation inheritance. This is too large an area to cover in this article, but what we have here is an example of part of the so-called "diamond" problem, where there is a common ancestor. You can see the diamond in the interfaces: Steerable, Driveable, Sailable, and Amphibious-Car.

The DelegatorFactory utility deals with the diamond problem by allowing you to specify the invocation behavior to the delegate superclasses as a pluggable strategy (an example of the Strategy pattern). The strategy is defined by the InvocationStrategy interface. The default strategy (InvokeFirstOnlyStrategy) is to invoke the first ancestor superclass that can handle the method. However, in the case of the diamond, what is required is that both ancestors need to handle the method. The InvokeAllStrategy handles this. If the method being invoked has a nonvoid return type, the return value from the first ancestor is returned. The two strategies are shown in Figure 4.

The invocation strategy can either be set after the DelegatorFactory has been instantiated, or can be set through (yet another) overloaded constructor. Hence our amphibious car should be created using:

AmphibiousCar ac =
(AmphibiousCar)
new DelegatorFactory(
Class[] {
Car.class, Boat.class
},
new InvokeAllStrategy()
).getObject();

This time, we get:

ac.steer(30);
System.out.println(ac.drive());
// prints "driving at bearing 30 degrees"
System.out.println(ac.sail());
// prints "sailing at bearing 30 degrees"

The InvokeFirstOnlyStrategy and InvokeAllStrategy are not the only strategies available (indeed we shall see one more shortly); however, they should work for most situations.

If a custom invocation strategy is required, it can be written by implementing the InvocationStrategy interface:

public interface InvocationStrategy {
Object invoke(final List ancestors,
final Method method,
final Object[] args)
throws Throwable
}

The ancestors parameter is an immutable list of the object instances representing the superclass. The method parameter represents the Method being invoked, and the args parameter contains the arguments to that Method. A typical invocation strategy would likely call method.invoke(S) somewhere within its implementation, with the first argument (the object upon which to invoke the method) being one of the ancestors.

We shall look at some applications of custom invocation strategies shortly. For now, though, an adaptation of InvokeAllStrategy might be to return the average return value of all ancestors, not just the return value of the first one.

Implicit Diamonds
In the previous diamond example, the Steerable interface is explicitly a super-interface of both Driveable and Sailable. What if the super-interface has not been explicitly factored out, though?

For example, in the original PersonLike and EmployeeLike example, what if each provided a foo() method, returning a string. Not imaginative, but never mind. Let's construct our employee and use an InvokeAllStrategy:

Employee employee = (Employee)
new DelegatorFactory(new Class[]{Person.class, Employment.class},
Employee.class,
new InvokeAllStrategy())
.getObject();

Now let us invoke foo():

employee.foo(); // what will happen?

Should the Person's implementation be called, that of Employment, or both? Although you might wish that both would be called (by virtue of our installed strategy), the sad truth is that only Person's implementation would be called. This is because the dynamic proxy has no way of knowing which interface to match foo() to, so it simply matches it to the first interface listed. (It's a java.lang.reflect.Method that is passed to the DelegatorFactory, not the string literal "foo()". Methods are associated with a specific declaring class/interface.) In terms of the DelegatorFactory's implementation, this means the first superclass listed in its constructor.

Note also that the compile time type does not matter. Neither of the following will change the outcome:

((PersonLike)employee).foo(); ((EmployeeLike)employee).foo();

In fact, it would be possible to modify DelegatorFactory to make Invoke-AllStrategy effective in this case, but that would involve parsing on the Method.getName() rather than the method. However, this has deliberately not been done. We'd rather you factored out the super-interface and made the diamond explicit. In the above example, add a FooLike (or Fooable) interface and make both PersonLike and EmployLike extend from it.

Other Applications
The issue raised by diamonds (implicit or otherwise) is that of how to deal with more than one implementation of a given method within an interface. However, it's interesting to turn this on its head.

In aircraft and other safety-critical environments, it's common to implement subsystems in triplicate. For example, there may be three different navigational systems, possibly with each implemented by different subcontractors. Each of these would be able to respond to the request, "Where is the location of the aircraft?"

Other systems within the aircraft interact with the navigational subsystem through a broker. This accepts the request on behalf of the navigational subsystem, and then forwards the request onto each implementation. Assuming there are no bugs in any of those implementations, they should all respond with the same data (within some delta of acceptable variance).

If there is a bug in one of the implementations, it may produce a response that differs wildly from the other two implementations. In this case, the broker disregards that response completely and uses the responses of the other implementations that agree with each other.

The design of DelegatorFactory and its pluggable invocation strategies make it easy to implement such a broker. Imagine a Calculator interface that defines a single method add(int, int):int. We can then have three implementations of this interface, as shown in Figure 5.

The FastCalculator uses regular integer arithmetic. The OneByOne- Calculator rather long-windedly performs its arithmetic by incrementing the first operand one-by-one in a loop. Both of these implementations are correct, just different. The final BrokenCalculator is just that; it actually performs a subtraction, not an addition.

The InvokeSafelyStrategy invocation strategy requires at least three ancestors that implement each method invoked. It will invoke the method on all ancestors, and then look to see that there is precisely one response that is most popular. Here is how to create a safe calculator that will ignore the incorrect implementation within the BrokenCalculator:

DelegatorFactory dfInvokeSafely =
new DelegatorFactory(
new Class[] {
BrokenCalculator.class,
OneByOneCalculator.class,
FastCalculator.class
},
Calculator.class,
new InvokeSafelyStrategy()
);
Calculator safeCalculator =
(Calculator)dfInvokeSafely.getObject();
assertEquals(7, safeCalculator.add(3,4));

Note that the InvokeSafelyStrategy is not all that intelligent. It stores the return values from each ancestor within a HashSet, so it relies on an accurate implementation of equals() and hashCode(). If the actual return type were a float (wrapped within a Float object), a more sophisticated invocation strategy would most likely be required. In general, this strategy will work only with well-defined value objects that can intrinsically deal with any rounding and other such errors.

You could easily adapt or refine the InvokeSafelyStrategy into further strategies. For example:

A parameterized version of InvokeSafelyStrategy could be used to deal with floats and other return types that would have rounding issues.

A background strategy might perform each invocation within a separate thread. Any invocation that had not responded within a certain timeout would be discarded.

A high-performance system, on the other hand, might use a strategy that again uses a backgrounding strategy but returns the result of the first one to finish, killing off the rest.

A logging strategy might perform some logging and then forward the invocation (typically to a single delegate).

A caching strategy would check its cache with respect to the input parameter, and only if the result is unknown would it invoke the delegate (caching the subsequent result).

A listener/broadcast strategy could represent a collection of listener objects; notifying all listeners of an event would require notifying only the broadcaster, which would then iterate over all listener objects as required.

Moreover, there is nothing to prevent multiple invocations from being chained together, (that is, the Decorator pattern). Alternatively, we could imagine a composite strategy (the Composite pattern) that combines a set of strategies together. Either the invocation chain (decorator) or the set of leaf strategies (composite) could be changed at runtime, meaning that we can change the behavior and responsibilities of the object dynamically. This is a fundamentally different paradigm from conventional Java with its static typing. Normally, it's the type/class of the object that determines its behavior, something that cannot be changed once the object is instantiated. Here, though, we have ended up configuring the behavior of objects on an instance-by-instance basis: so-called instance-based programming. In effect, the whole notion of type becomes much less important.

There are echoes here too of aspect-oriented programming. Most aspect-oriented programming uses compile-time techniques (the term used is "weaving") to add in behavior to classes. The classic example of aspect-oriented programming is to add logging within all method calls. You can easily see, though, that these same features can be incorporated dynamically using invocation strategies; the decorator/composite invocation strategies would allow an arbitrary set of aspects to be added to a class. The difference though is that now the aspects are applied at runtime (and hence can be changed without recompile and redeployment).

Conclusion
The DelegatorFactory is simple to use, supporting classic mix-in (orthogonal) multiple-implementation inheritance "out-of-the-box" and - with its pluggable invocation strategy design - allows diamond hierarchies to be easily supported. Moreover, the design also lends itself to other quite unrelated problem spaces; for example, creating safe systems was explored. Taken to its logical conclusion, the approach supports both instance-based programming and aspect-oriented programming.

Of course, what makes DelegatorFactory work is Java's support for dynamic proxies, and that in turn requires that the ancestor superclasses implement interfaces. This approach won't work for class-based designs (JDOM is an example that comes to mind). But arguably class-based designs should be used only for value objects that should be final anyway. Those situations where multiple inheritance is desired are more likely to occur when working with reference objects.

One particular case deliberately not supported by DelegatorFactory is when there is a so-called implicit diamond. The solution though is to pull out the methods that appear in both interfaces, and move them into a new super-interface. Then, make sure you use InvokeAllStrategy rather than the default InvokeFirstOnlyStrategy.

Of course, using a dynamic proxy object will be slower than a hand-crafted solution, principally because reflection is used. However, the difference may not be noticeable in practice. In recent releases of Java, Sun has put much effort in speeding up reflective invocation; as of JDK 1.4.1, it may well be that regular invocation is only twice as fast as reflective invocation (previously this figure was something like 40 times faster).

Using DelegatorFactory
The DelegatorFactory utility class and supporting classes described here can be downloaded from www.sys-con.com/java/sourcec.cfm, and are compilable using Ant (v1.5.1 was used to create the build file). A JUnit-based test harness is also provided; JUnit v3.8.1 is required. The motivating examples in this article are based on the JUnit tests, so they should be easy enough to follow.

To run the tests with JUnit's text-based test runner, use:

ant test

Alternatively, you can use JUnit's test runner by running directly:

ant rebuild
java -classpath
dist/halware-util-dynamic-bin.jar;dist/halware-util-dynamic-bin-test.jar
com.halware.util.dynamic.test.AllTests gui

(The GUI test runner is not the default since JUnit's classloaders do not understand the Class-Path manifest attribute.)

I hope you find DelegatorFactory useful. It has been distributed under the GNU Lesser Public License, so you are free to embed it within your own software as required.

Few More As Faqs..

What are Static variable and Static classes?

What is the difference between as2 and as3?

Explain singleton design pattern and its implementation?

What are data services?

What is flex charting and its use?

Explain the complete display list API.

What is the difference between sprite and movie clip?

Explain the procedure of handling HTML items in xml.

How can we do the video editing?

What are cue points?

How can we achieve the Database integration with Flash and Flex?

What is server side data handling?

What is Font Embedding? How to do it and why and its use.?

What are device fonts?

What are dynamic classes adn how can they useful in a real scenario?

Explain the event flow.

What is object class?

Can we call add event listener and dispatch event on object class?

Which class we need to import for event?

What is the use of weak references?

What is the garbage collection procedure in as3?

Can we overload the function of two different classes.?

Difference between target and current target?

Difference between inheritance and composition?

Explain the use of flash media server.

What is flash remoting?

What is strict mode compilation?

What is the need of interfaces?

How can we pause a running event?

Difference between == and &&?


more on the go...................... :)

Adobe LiveCycle ES Foundation

Adobe LiveCycle ES Foundation software provides the underlying server capabilities that enable the deployment, execution, and management of LiveCycle ES solution components. Included with the purchase of most* LiveCycle ES solution components, LiveCycle ES Foundation consists of:

• Service container
• Foundation services
• Administration tools
• Central repository

Use LiveCycle ES Foundation to deploy short-lived processes that combine a number of solution components. For example, you can create a PDF form, apply a security policy to it, certify the document, and finally enable the form for basic form fill-in and import/export of data using Adobe Reader® software. A short-lived process can be reused in other processes once it has been created. It can also be invoked by a number of different mechanisms. For developers, a process can be invoked through a Java API, web services, and Microsoft .NET. LiveCycle software supports the WS-I Basic Profile 1.1 standard and has tested interoperability with .NET and the web services stacks supported by the major application server vendors as well as that found within the Sun™ Java Software Development Kit (SDK). LiveCycle ES also allows developers of Adobe Flex™ software using ActionScript™ to directly invoke processes (as well as solution components) through Adobe LiveCycle Data Services ES software. Other common forms of invocation include watched folders and e-mail.

Service container

The service container provides the common runtime environment to support all solution components and associated services. It provides an event framework that enables business events to be defined. LiveCycle ES supports a number of different event types, such as asynchronous events, exception events, and timer events. Events can be raised or received within processes or linked to external events on a messaging bus through integration with Java Message Service (JMS).

Foundation services

LiveCycle ES Foundation has a number of out-of-box services that allow integration with common IT infrastructures. Common services include:

• Query a user directory through LDAP
• Invoke web services
• Read/write data to a relational database through SQL queries
• Send/receive e-mail through common standards such as SMTP, POP3, and IMAP
• Send/receive messages over a JMS queue
• Read/write files from a file system or using FTP protocol

Administration tools

To simplify the management of your LiveCycle deployment, LiveCycle ES Foundation includes:

• LiveCycle Configuration Manager
• LiveCycle Administration Console

LiveCycle Configuration Manager is used to configure and deploy LiveCycle ES solution components, including applying service packs and emergency patches.

LiveCycle Administration Console is a web-based portal used by systems administrators to manage the deployment and configuration of LiveCycle ES applications, configure users and groups and their associated permissions, and configure and fine-tune the server settings such as port numbers and log files. LiveCycle Administration Console also provides the ability to manage each solution component, such as configuring polices for Adobe LiveCycle Rights Management ES software and reassigning tasks as part of Adobe LiveCycle Process Management ES software.

Central repository

When you deploy an application, all of the information goes in the LiveCycle ES Foundation central repository, and all of the systems in a single or clustered J2EE system get their components from the repository. This greatly simplifies application deployment and enables many time-saving capabilities, such as form fragment libraries for reuse, auditing for management, and versioning for structured development and deployment. The ability to move archives (groups of related assets that can be packaged together) eliminates many manual tasks. And by relating assets in the repository, these applications can be exported and transferred to other LiveCycle systems including Adobe LiveCycle Content Services ES.