OMG is getting ready to vote on its "Reusable Asset Specification". Ronald Schmelzer, an analyst with ZapThink LLC, said that RAS "defines how to package software 'assets' so that they can easily be reused by other applications."

This doesn't equal Objects or Components, but also scripts, metadata, and any artifacts. What makes a RAS asset distinct is that it's packaged as a set of files and metadata that describes those files in a way that they can be reused.

RAS supports Model Driven Architecture and Unified Modeling Language, and the vision is that the specification allows a number of companies to host repositories and access these reusable assets.

Does this sound like it makes sense? or more like "that will never actually happen" as with public UDDI servers.

Read OMG Aims for Reusable Assets

From the self-promotion department: Tapestry has had some form of this concept for years ... the idea that (web) components would be packaged (as JARs) with additional resources (images, stylesheets, JavaScript libraries) and scripts (dynamically generated JavaScript) for reuse in wide ranging applications.

It would be interesting if there was more standard infrastructure for this kind of thing, however; Tapestry uses two different approaches to expose "private" assets (assets that are packaged on the classpath) and neither of them is 100% ideal in all situations. Option #1 is to use an Tapestry service (think of it as a kind of servlet) to expose resources on the classpath ... which has some number of security issues. Option #2 is to copy files to a portion of the file system mapped to a web folder, but that has issues in a cluster.

As I Understand, RAS is supported by Rational Tool ? so who is proposing? IBM or OMG?

As I Understand, RAS is supported by Rational Tool ? so who is proposing? IBM or OMG?

Rational initially spearheaded RAS, so I guess it is IBM now. RAS was officially driven by a "consortium" of companies headed up by Rational (if I remember correctly) as opposed to a standard, which may be one of the reasons it never took off.

Bill Willis
PatternsCentral

>
> Bill Willis

Yes, you are right, RAS was headed by IBM Rational the RAS Consortium formed in 2000. The original members included IBM Rational, Microsoft, ComponentSource, and Merrill Lynch.

-----------------------------------------
http://JavaRSS.com
Just one bookmark - for all java news, articles and blogs.
-----------------------------------------

RAS "is taking a pragmatic approach to packaging reusable assets and cataloging them in asset repositories."

If the last version of the spec that was available publicly is any indication, I don't think the word "practical" fits here. The standard was based on UML and was anything but practical. I also didn't like the one-size-fits-all approach to representing artifacts (which is also the case in repositories already in existence). There was an extension mechanism, but they didn't provide any compelling examples in the spec. The spec also didn't cover any necessary constraints on repositories themselves.

I would honestly like to see a truly practical standard for reusing artifacts, because I am currently working on a repository for patterns and other related artifacts. Until they open the specification up for review and I am convinced it will meet my needs (without a bunch of UML/MDA overhead), I will use my own simple, XML-based interchange for artifacts.

Perhaps someone involved in the RAS effort could give us some more up-to-date information on the spec??

Bill Willis
PatternsCentral

Until they open the specification up for review and I am convinced it will meet my needs (without a bunch of UML/MDA overhead), I will use my own simple, XML-based interchange for artifacts.

Having skimmed IBM's proposal, I agree with your assessment. It doesn't seem that RAS offers much to a traditional manual implementation environment. RAS only fits CASE tools, and that's a strength.

Here is the link to IBM Rational's RAS Draft Specification

-----------------------------------------
http://JavaRSS.com
Just one bookmark - for all java news, articles and blogs.
-----------------------------------------

I may be way off base here, but I don't think a common packaging format is the answer. In JBoss we have a microkernel. I common kernel that provides plugins for classloading and hot deployment. On top of that we have a set of pluggable Deployers. Deployers are responsible for unpackaging a deployment type, reading metadata or whatever, and deploying the component into the JBoss runtime. We have different Deployers for each component type in JBoss. One for each J2EE type, EAR, WAR, EJB-JAR, and RAR (resource archives). And proprietary ones for JBoss: SAR (JMX service archive), AOP, and currently are writing one for Hibernate. These Deployers are based on a set of well defined interfaces that somebody can extend to write their own Deployer/packaging mechanism.

So, what I'm saying is that it is more important to have a lightweight kernel and a mechanism/API to define and plugin new types of deployments than a common archive format.

Bill

>
> So, what I'm saying is that it is more important to have a lightweight kernel and a mechanism/API to define and plugin new types of deployments than a common archive format.
>
> Bill

(Sorry replying to myself). So, with Deployers you don't care what format the component/archive is in. In can be jarred, bzipped, tarred, gziped, in any directory structure, even binary stuff, whatever....The pluggable Deployer is responsible for unpackaging the component and has a well defined interface into the runtime.

Bill

Bill,

I agree with you that having something like JBoss' microkernal is a good fit for a lot situations where you have heterogenious data types (deployers, components, assets, etc., etc.) However, I may be missing the point (it's a hobby of mine), but it seems like your statements may illustrate the need for a common format.

You say that you have descriptors for each J2EE type: EAR, RAR, etc. as well as the prioprietary formats. However, some governing body had to come together to define the format of those types. They had to state the format of an EAR, what metadata is could and had to contain, where files would go, etc. Thus, there was some work that needed to be done on the definition of a common format.

So, is RAS a JAR or an app (a combination of JARs, EARs, WARs, etc.)? Obviously, a common repositiory for components and assets would be well served by a kernel such as the one you speak of, but we might do well to work on defining a standard format.

Though, I do want to give my .02 and say that a UML based definition of that common format is probably not the best way to go...

Well, given that a RAS component contains data on how to access it, it could be considered a universal plugin structure. Somewhat like WDSL and webservices, but than for code directly.

My two cents would be that I think that the only way to get software development to "the next level" is to put more emphasis on interfaces and interoperability, so I'm please with the approach, although I'm not sure if the selected technology will make it easy. How about something like SOAP without the web thingy, but a memory pipe?

It all kinda feels like we're looking for the proper way to go with the Java / DotNet / WebService / virtual machine / XML context. Java was great with this VM idea (although not new), XML appears to be a good idea also, DotNet picked up where Java stopped (conceptually) and now we're gonna, gonna, well, anyone got ducttape?

Oh and, ah, please let them take using multiple versions of the same RAS component into account.

Tom

Tom

What you are saying makes sense. RAS isn't about an archive of files but about the meta data describing how it is used. WSDL is great for web services but if you apply some of the thinking further then you start looking at a more constructive way of attempting re-use.

I have been working on something in my spare time that is basically a way of applying standard XML Schema to Java API. The idea being that the schema can describe how to use the class API from a use case point of view. In the end you notice that alot of code is simply matching inputs and outputs between the API guided by these schema. The end goal being that if I give you some of my classes then I would be sure that you use them as intended.

More than half the problem of re-use is describing how something should be used.

Dan

I have been working on something in my spare time that is basically a way of applying standard XML Schema to Java API. The idea being that the schema can describe how to use the class API from a use case point of view. In the end you notice that alot of code is simply matching inputs and outputs between the API guided by these schema. The end goal being that if I give you some of my classes then I would be sure that you use them as intended.

That sounds helpful, assuming sophisticated automation such as interceptor advice. But I don't see how Schema can validate a use case, which is a temporal matter. Schema doesn't know about time. I assume Schema can only be used to exclude some method parameter actual values -- eg, not null. Surely Schema can't validate an invocation sequence -- eg, must call init() before calling run(). This really begs a state diagram, UML, and MDA. Or BPEL.

Brian

If you use multiple schemas. One for the API and one or more for the invocation sequences.

A schema cannot validate an invocation sequence directly. I have been tyring out transforming the java code to XML and then validating that against the relevant schemas. Schemas can do order of elements and choices which work well for sequences.

What I was looking for was patterns of code driven by the schemas and wired up by the developer. The developer provides the glue and steers any decisions needed. Also the developer helps fill the gaps too!

This is something that is experimental so the outcome will be bits that work and bits that don't.

For example, one bit that fell out was using schemas to describe HTTP requests in my web applications. It provides a nice developer time check that I am linking correctly and it can be used for some runtime security checking too.

And I have also created a way to bind JDO and XML Schema for the database layer.

At the moment I haven't time to release anything to a wider audience but hope to one day.

Dan