[802] in I/T Delivery
May Status for Java Architecture Group
daemon@ATHENA.MIT.EDU (Charles Shubert)
Wed Jun 12 12:02:35 2002
Date: Wed, 12 Jun 2002 12:02:33 -0400
Mime-Version: 1.0 (Apple Message framework v481)
Content-Type: multipart/alternative; boundary=Apple-Mail-1-493396722
From: Charles Shubert <cshubert@MIT.EDU>
To: delivery@mit.edu
Message-Id: <CE3A3D95-7E1D-11D6-9414-00039384A12E@mit.edu>
--Apple-Mail-1-493396722
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=WINDOWS-1252;
format=flowed
Java Architecture for Infrastructure Services
Team Name: Java Architecture
Project Leader: Scott Thorne
Report Date: 6/10/2002
Submitted by: Chuck Shubert
Accomplishments:
In May we shifted our development focus to emphasize utilizing OKI=20
Common Services in demonstration applications. We have created=20
storyboards for two demonstration applications: one that we are calling=20=
the Hierarchy demonstration and the other that we are calling the Filing=20=
demonstration. The names may be adjusted (e.g. Hierarchy may become=20
Graph or Relations) on these applications, but the intent is to exercise=20=
the OKI APIs in a multitier environment using both application and=20
servlet user interfaces.
We were delighted to host Gavin Eadie from the University of Michigan=20
this month. He worked with us here at Cambridge and continues to work=20=
with us from Ann Arbor. His work focused on creating an implementation=20=
of the Authorization API. Our current implementation uses MIT Roles. =20=
Gavin is planning on deploying his implementation of Authorization with=20=
a Telephone service application that he is creating at the University of=20=
Michigan. We anticipate that his implementation will be generic enough=20=
to serve as the Authorization API reference implementation. In=20
conjunction with Gavin=92s work we have refined the Authorization API =
and=20
the MIT Roles implementation.
We are confident now that we will be able to structure work to take=20
advantage of help coming from our OKI partners.
Goals:
There continues to be plenty to do: documentation, common service,=20
utility, and application layer API creation, implementation, testing,=20
documentation, and so on. We are using development of demo applications=20=
to refine the OKI message, to create the environment needed for testing=20=
system integration, and to serve as examples for developers.
The bulk of work on the initial set of demonstration applications will=20=
take place in June.
We will again take up the issues associated with the application layer=20=
APIs. Specifically, we will be working on two major application layer=20=
APIs: Content Management, and Course Administration.
Issues:
Structuring OKI work to handle the large number of activities currently=20=
under way is the biggest current issue.
Key learnings:
Earlier lessons have been reinforced.
Team Dynamics:
The OKI team continues to work hard. There continues to be a lot to=20
do. Focusing on the demonstration applications has energized the team.
--Apple-Mail-1-493396722
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
charset=WINDOWS-1252
<fontfamily><param>Arial</param>Java Architecture for Infrastructure
Services
Team Name: Java Architecture
Project Leader: Scott Thorne
Report Date: 6/10/2002
Submitted by: Chuck Shubert
Accomplishments:
In May we shifted our development focus to emphasize utilizing OKI
Common Services in demonstration applications. We have created
storyboards for two demonstration applications: one that we are
calling the Hierarchy demonstration and the other that we are calling
the Filing demonstration. The names may be adjusted (e.g. Hierarchy
may become Graph or Relations) on these applications, but the intent
is to exercise the OKI APIs in a multitier environment using both
application and servlet user interfaces.
We were delighted to host Gavin Eadie from the University of Michigan
this month. He worked with us here at Cambridge and continues to work
with us from Ann Arbor. His work focused on creating an
implementation of the Authorization API. Our current implementation
uses MIT Roles. Gavin is planning on deploying his implementation of
Authorization with a Telephone service application that he is creating
at the University of Michigan. We anticipate that his implementation
will be generic enough to serve as the Authorization API reference
implementation. In conjunction with Gavin=92s work we have refined the
Authorization API and the MIT Roles implementation.
We are confident now that we will be able to structure work to take
advantage of help coming from our OKI partners.
Goals:
There continues to be plenty to do: documentation, common service,
utility, and application layer API creation, implementation, testing,
documentation, and so on. We are using development of demo
applications to refine the OKI message, to create the environment
needed for testing system integration, and to serve as examples for
developers.
The bulk of work on the initial set of demonstration applications will
take place in June.
We will again take up the issues associated with the application layer
APIs. Specifically, we will be working on two major application layer
APIs: Content Management, and Course Administration.
Issues:
Structuring OKI work to handle the large number of activities
currently under way is the biggest current issue.
Key learnings:
Earlier lessons have been reinforced.
Team Dynamics:
The OKI team continues to work hard. There continues to be a lot to
do. Focusing on the demonstration applications has energized the team.
</fontfamily>=
--Apple-Mail-1-493396722--
