Eric's Page

On This Site:

Nifty Hacks:

You Should Visit:

Projects I Manage:

Eric M. Dashofy's Research

I'm currently a Graduate Student Researcher in the Software group in the Department of Information & Computer Science at the University of California, Irvine. My advisor is Richard N. Taylor.

My current focus is on Software Architectures, particularly the C2 Architectural Style. I am currently the unofficial "Runtime Dynamism Evangelist" in the C2 group here.


ArchStudio 3 - An Architecture-Centric Development Environment

I'm one of the primary students building ArchStudio 3, our architecture-based development environment. I also maintain the ArchStudio 3 Homepage.


c2.fw - A New Framework for Developing Applications in the C2 Style

A big part of ArchStudio 3 is the architecture framework underlying it, which is called c2.fw. c2.fw provides a Java object library suitable for building applications out of components and connectors that communicate via asynchronous events. This particular architecture framework is but one of many developed here at UCI and elsewhere, each with different features and capabilities. c2.fw is unique among these frameworks because of features such as these:

  • The ability to develop event-based architectures with arbitrary topologies, not just C2 style architectures.
  • The ability to plug in different threading policies.
  • The ability to plug in different message queuing policies.
  • Direct and (mostly) transparent support for event-based procedure call (EPC) communication among components.
For those interested, c2.fw is currently available as part of the ArchStudio 3 Download.
xADL 2.0 - A Highly Extensible Architecture Description Language

ArchStudio 3 maintains a model of a software system's architecture along with the system, much like some code-oriented development environments maintain abstract syntax tree representations along with the code. Representing a software architecture is somewhat different becuase everybody's got a different idea of what information goes in an architecture description. Depending on the level of design you want to specify, you may or may not want certain features in your Architecture Description Language (ADL).

To help resolve this problem, we've developed a highly extensible (and I would posit the most extensible) ADL available, based on XML and XML Schemas. Imagine the ability to add or remove features from your favorite programming language as you need them--that's the kind of extensibility that our ADL provides. It's called xADL 2.0, and you can find out more about it at the xADL 2.0 site. You can use xADL 2.0 with or without ArchStudio 3. I also maintain the xADL 2.0 site.


Hermit - the HTTP Enhanced Remote Method Invocation Technique

Update: After working with it for some time, I've decided that SOAP/Hermit are not exactly what I was looking for in my work. Therefore, I'm not going to be updating the Hermit download anytime soon, but feel free to grab it for yourself and take a look.

In the course of enhancing the above C2 framework to support distributed software architectures, it struck me that I would need a good interprocess communication mechanism to faciliate distributed control and distributed message passing within C2 architectures. Everybody's been pitching XML and SOAP as the next generation of technologies geared toward this, and I didn't want to get stuck building on some proprietary, hard-to-work-with middleware for lightweight interprocess communication, so I decided to use SOAP. After working with SOAP, I found out that the current Apache SOAP implementation (http://xml.apache.org/soap) is a great implementation of the protocol, but has a wieldy programmer's interface, especially for what I wanted - simple skeleton/stub based RPC. Furthermore, it requires custom XML serializers for every object you want to send, which means explicit registration of types. I was just about to give up on SOAP and just implement my own mechanism, but I gave it one last go and integrated all my XML tools into the SOAP implementation. So, now you can have the standards-compliance of SOAP and XML with the ease of RMI (mostly)

If you're from the SOAP community, you're probably looking for one of two things:

  1. My much-touted Java<->XML serializer, which is included here. Just read the Javadoc documentation for the edu.uci.ics.xml.JavaXmlSerializer class, and that should get you up to speed. The SOAP serializer that uses this is edu.uci.ics.hermit.ObjectSerializer, which you can use if you don't mind registering all your types manually. If you want some nice auto-type registration, play with edu.uci.ics.hermit.AutoSOAPMappingRegistry and the various createDeploymentDescriptor() functions found in edu.uci.ics.hermit.HermitServer. Of course, if you're doing that, you probably want to use all of Hermit, described here:
  2. My RMI-like stubber for Java interfaces, which is a little harder to explain, and for which I don't want to write documentation right now. Basically, here's the deal. Make a Java interface. Run the edu.uci.ics.hermit.HermitCompiler standalone app on it to generate a stub. If you want to find out how to deploy your object, look in the HermitServer and TestServer objects. To find out how to call it, look at the TestClient object. It's not very hard to figure out, and works pretty darn well.

Updated! I fixed a couple of bugs in the Hermit compiler regarding interfaces that extend multiple interfaces, some of which share a common function, and a bug regarding proper compilation of basic types. If you already have my updated modified SOAP jar, you don't need to download that again. Just download the new Hermit jar.

Anyway, I have to show you some legalese so you don't sue us. Hey, guys, this is an alpha release, and isn't ready for prime time, but feel free to play with it:

Disclamer: THE UNIVERSITY OF CALIFORNIA DISCLAIMS ALL 
WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL 
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, 
IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE 
FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR 
ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, 
DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, 
NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF 
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF 
THIS SOFTWARE.

Mmkay? Good.

To browse the Javadoc documentation, go here: http://www.ics.uci.edu/~edashofy/soaplib/doc/.

Now, if you want to download the package, the serializer and Hermit stuff are in here:

hermit.jar: Serializer and Hermit implementation (Alpha release 2).

Note, that if you want to use Hermit (the stubber and all), you have to use a slightly modified version of Apache SOAP 2.0 that has a patch in it to allow SOAP Faults to store serialized exceptions. I've submitted this patch to the Apache folks, but it hasn't been included in a release yet. If you want to use Hermit, use this in place of your existing SOAP 2.0 jar file:

soap-2_0_mod.jar: Modified Apache SOAP 2.0 release with Exceptions-in-Faults patch (Unofficial release necessary for Hermit).

Looking for the code? It's in the .jar files. Just unzip them in some other directory--I was too lazy to separate them all out for an alpha release.

If you have any questions or patches or updates or bug reports, just drop me an email at edashofy@ics.uci.edu.


Other folks I work with here

These are pretty cool people to work with. Check out their homepages: