[MOZART-DLL REQUIREMENTS] Use Case 1: EmbedEmulationEngine
Bob Calco
robert.calco at verizon.net
Sat Apr 27 07:20:30 CEST 2002
Sameh et al.:
I think to generalize what you are saying here at a level of abstraction
sufficient for use case scenario development per Denys's suggestion, which I
like (there will be time for pseudocode later, after this use case has been
decomposed to a level that lends itself to actual design), one might begin
to "model" it this way:
USE CASE 1: EmbedOzEmulationEngine
ACTOR(s): ExternalApplication, OzEmulationEngine, HostOS
TRIGGER:
ExternalApplication requires low-level OzEmulationEngine services tightly
coupled with its own to provide additional valuable functionality not easily
implemented in its own implementation language.
[NOTE: This use case can be further decomposed by enumerating specifically
the different types of services that can be distinctly provided by Oz,
everything from invoking existing functors, to wrapping the Engine in a
particular component architecture (COM, JavaBeans, etc), to interactively or
dynamically generating functors on-the-fly, etc., and describing the
particulars in each case.]
BASIC FLOW:
1. ExternalApplication loads the OzEmulationEngine encapsulating and
enhancing the services of the Oz Emulation Engine.
2. OzEmulationEngine is successfully loaded into ExternalApplication's
memory space in a manner that is thread-safe in the context of
ExternalApplication and its HostOS.
4. ExternalApplication registers garbage collection and/or any other
necessary handlers/callbacks, depending upon the services required from the
OzEmulatorEngine during execution.
5. The OzEmulationEngine validates that it is ready to provide basic
services, having loaded whatever basic modules/functors it needs. Extended
services will be loaded on demand.
6. During execution, ExternalApplication avails itself as necessary
according to its design needs of OzEmulationEngine's public data and
services in a thread-safe manner and properly manages those aspects of the
integration that are its responsibility (e.g., garbage collection).
7. Upon shutdown or when OzEmulationEngine services are no longer needed,
the OzEmulationEngine terminates gracefully, cleaning up any garbage and
supplying ExternalApplication with a meaningful return code.
ALTERNATE FLOWS:
{TBD}
EXCEPTIONS:
During loading, execution and shutdown, the OzEmulationEngine reports any
errors, exceptions and warnings (with meaningful messages) needed for
ExternalApplication to recover (or exit) gracefully, where possible.
OPEN ISSUES:
1. Thread-safety is platform-specific in implementation and may affect the
portability of the design. As this is not a new problem to Oz or any other
system that operates based on a VM, it is not a major concern per se, but
alternate flows where dictated need to be identified in more detailed use
cases.
2. The HostOS may be a combination of a native OS and some virtual machine,
such as Java. This may further complicate threading-related issues.
3. Not all ExternalApplications are themselves multi-threaded or thread
safe. This too needs to be taken into account. For instance, some scripting
engines, which may wish to provide extension modules for integration with
the Oz system, are innately multi-threaded, others are not. Are there any
requirements we ought to demand of ExternalApplication in terms of threading
model or any other aspect of runtime behavior/characteristics?
4. How will we define the line of demarcation between the ExternalProgram's
responsibilities vis a vis garbage collection, and those of
OzEmulationEngine? What facilities if any need to be exposed or futher
enhanced to hand off the appropriate level of responsibility to the
ExternalApplication where garbage collection is concerned? More generically,
how much of a black box can and should garbage collection be?
5. What are the appropriate data and basic services to expose immediately on
startup?
6. How best to marshall data (of various types) between the host process,
and any processes spawned by the OzEmulationEngine? Obviously, a design
issue, but perhaps there are some higher-level functionality issues this
question illuminates?
6. What are the possible exceptions, specifically?
7. More, TBD.
--
Please let me know what to add... there were some conversations in the
parent thread (REALLY standalone executables...) that I have not had a time
to excavate from my Outlook inbox, where currently something like 7000
unread messages await my delete button... anybody and everybody feel free to
add/subtract/mulitply/divide as appropriate.
Just trying to get something started with enough momentum to carry it to
some actual conclusion...
I would draw some anatomically-correct stick figures and pretty balloons and
everything, but I personally think Use Cases are more useful when hammered
out in succinct prose. Diagramming, a wee bit later, when it will actually
be useful...
:)
Bob Calco.
% -----Original Message-----
% From: owner-oz-users at ps.uni-sb.de [mailto:owner-oz-users at ps.uni-sb.de]On
% Behalf Of Sameh El-Ansary
% Sent: Friday, April 26, 2002 7:45 AM
% To: users at mozart-oz.org
% Subject: Re: RE-SENT: [MOZART-DLL REQUIREMENTS] Announcement
%
%
% Hi all and Bob,
% Just to begin brainstoming on possible ways of using Mozart DLL, I
% plagiarized
% from the Prolog's interface to Java and VBasic.
%
% Please treat the following Java code as pseudocode, I would
% love to see something like the follwoing:
% %%--------
% static void main() {
% OzVM oz; %% OzVM is an interface to
% Mozart-DLL, Oz
% and instance
% OzList solutions; %% Ozlist, simply a list please do not
% start shouting here.
%
% %% where OzVm() code responsible for:
% %% 1) Forking a new native/OS thread to make the alarm signal
% %% 2) Running the mozart emulator
% %% 3) Possibly loading a compiler "Oz thread", something like the
% OPI
% oz = new OzVM();
%
% %% Also one may want to load a functor
% oz.loadfunctor("mysolver.ozf");
%
% %% get some input from the user.
% x = someInputCode();
%
% %% send code to be excuted by the Mozart emulator.
% solutions = oz..execute("{DoMySearch "+x+" }");
%
% while (solution=solutions.nextSolution()) {
% Print(solution);
% }
% }
% %%--------
%
% I have some problems with my described use cases though:
% 1- When we get output as a result of oz execution, in which data types
% should we receive it, in my example I did somehting called OzList but
% is this enough, possibly not, should we return strings instead, I do
% not
% know?
%
% 2- What happens if the value provided by th input to my solver resulted
% in a suspension. Ideally, no such value should exist but just imagine
% if there existed values like that that could suspend our code.
%
% Regards,
% ====================================
% Sameh El-Ansary
% Researcher, Distributed Systems Lab.
% Swedish Institute of Computer Science(SICS)
% Box 1263, SE-164 29 Kista, Sweden
% Phone : +46 8 633 1583
% Mobile: +46 73 0452197
% Fax : +46 8 751 7230
% http://www.sics.se/~sameh
%
%
%
%
%
%
%
% ----- Original Message -----
% From: "Bob Calco" <robert.calco at verizon.net>
% Newsgroups: mozart-oz.users
% Sent: Friday, April 26, 2002 9:15 AM
% Subject: RE-SENT: [MOZART-DLL REQUIREMENTS] Announcement
%
%
% > Denys et al.:
% >
% > % rcalco at mindspring.com writes:
% > %
% > % > I would like to volunteer to assist with the Mozart-DLL
% > % project, actually.
% > %
% > % Great! The first step is to come up with some sort of design
% > % requirements document and I think we should do this by studying a few
% > % "use case scenarii". Those of you with an interest in a Mozart DLL
% > % should describe in detail a practical scenario and outline what sort
% > % of functionality they'd expect from the DLL.
% >
% > I will take responsibility for maintaining the reqs and specs for
% > the Mozart-DLL project, and keeping them at a
% > soon-to-be-determined URL for everyone to pull down in some
% > commonly agreed-upon format.
% >
% > %
% > % Bob, if you could additionally distill the ensuing discussion into an
% > % evolving draft avilable on the web, that would be very helpful.
% >
% > Yes -- Everybody who has an opinion on the required functionality
% > or general usefulness of the Mozart-DLL, please send related
% > thoughts to the users at mozart-oz.org list with "[MOZART-DLL
% > REQUIREMENTS]" as the subject header. I will continually update
% > the webpage and downloadable specs and at some point, once we
% > have sufficiently detailed design and analysis out of the way, we
% > can start looking at how to dispense the tasks for getting it done.
% >
% > The process of prioritizing and selecting between conflicting
% > requirements will be an open one at the requirements phase, but I
% > suggest once the design is underway at a detailed level, we
% > should perhaps by then have decided on who, precisely, will be on
% > the implementation "team" and those discussions probably should
% > migrate to the hackers at mozart-oz.org list.
% >
% > Any other ideas?
% >
% > Sincerely,
% >
% > Bob Calco
% >
% >
% > % Cheers,
% > %
% > % --
% > % Dr. Denys Duchier Denys.Duchier at ps.uni-sb.de
% > % Forschungsbereich Programmiersysteme (Programming Systems Lab)
% > % Universitaet des Saarlandes, Geb. 45
% > http://www.ps.uni-sb.de/~duchier
% > % Postfach 15 11 50 Phone: +49 681 302 5618
% > % 66041 Saarbruecken, Germany Fax: +49 681 302 5615
% > % -
% > % Please send submissions to users at mozart-oz.org
% > % and administriva mail to users-request at mozart-oz.org.
% > % The Mozart Oz web site is at http://www.mozart-oz.org/.
% > %
% > -
% > Please send submissions to users at mozart-oz.org
% > and administriva mail to users-request at mozart-oz.org.
% > The Mozart Oz web site is at http://www.mozart-oz.org/.
%
% -
% Please send submissions to users at mozart-oz.org
% and administriva mail to users-request at mozart-oz.org.
% The Mozart Oz web site is at http://www.mozart-oz.org/.
%
-
Please send submissions to users at mozart-oz.org
and administriva mail to users-request at mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.
More information about the mozart-users
mailing list