uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Roeder <chris.roe...@ucdenver.edu>
Subject Re: Parameters in uima descriptors
Date Wed, 03 Jun 2009 15:52:42 GMT
Thilo Goetz wrote:
> Steven Bethard wrote:
>> Steven Bethard wrote:
>>> On Thu, May 14, 2009 at 6:29 AM, Thilo Goetz <twgoetz@gmx.de> wrote:
>>>> I don't know the details of what you did, but it sounds to me like
>>>> you threw many advantages of UIMA (reusability, transparent remotability
>>>> etc.) right out of the window.
>>> I don't see why that would be the case. We're still creating
>>> AnalysisEngineDescriptions, just in Java code, not XML.
>> [snip]
>>> I haven't played around with "transparent remotability", but I can't
>>> see why using Java descriptors instead of XML descriptors would make
>>> that any harder. Maybe you can elaborate?
>> I would like to hear an answer to this if anyone knows. Is there
>> something you can do with an XML descriptor that you can't do with an
>> AnalysisEngineDescription object?
> You can't do any of the things that our documentation
> says you can do with a descriptor.  You can't read it,
> for example.
The IT/Java industry has grappled with issues concerning building systems
by plugging modules into a central integration platform for quite a 
while now.
UIMA AE's are analgous to either servlets or EJBs (beans) and the CPM 
would be
called a "container" as Tomcat and WebSphere are. The configuration in
these cases started out in XML as in UIMA. Newer releases have some of
the meta data is migrating  to Java Annotations.  The benefit of Java 
is that the meta-data stored in XML can be  written in the java source 
in a way
that  you don't get the problems associated with having two places that 
the name of a parameter for example. The AE descriptor information would be
in the annotations where the CPE gui could read it when creating the CPE
xml descriptor.

While their may be some Resume-Driven-Design that prefers the complexity
of these meta-data-driven approaches to the simplicity of doing it all 
in Java,
I think the motivation comes from the desire for a clear code separation 
container and "bean". It's clear to me in the extreme case of a 
commercial vendor supplied
container where you don't have access to the source so you can't code your
pipeline construction in java. While they could provide an 
initialization callback,
that's in effect what they are doing, yet with more restriction.

This is discussed in more detail under either "Inversion of Control" or
"Dependency Injection."


>> Steve

View raw message