Hi Farrukh,
This sounds like an excellent approach; however, I'm not sufficiently versed
in ebXML to speak to its coverage of the requirements. But this brings up
the following:
To All:
I would like to point out that, at the behest of NARA's Assistant Director
of the ERA Program, we are bringing the NARA Records Management Services
Functional Requirements into the Object Management Group to serve as a basis
for an OMG standard specification. The Functional Requirements are being
"translated" into an OMG Request for Proposal (RFP) for a specification
compliant with OMG's Model Driven Architecture (MDA).
We had a kickoff meeting on this effort last Friday (31-Mar) in Fairfax VA.
Over 50 people attended and we had 20 government representatives from 11
agencies present in support of the effort. Major government contractors,
integrators, and solution providers were present. This effort will be a
joint government/industry undertaking.
Under the RFP, the OMG will request a Platform Independent Model (PIM), and
at least one Platform Specific Model (PSM) from the commercial technical
community. What Farrukh has proposed would be an approach to a PSM
implementing the yet-to-be defined PIM. (That PIM will be based on the
Functional Requirements that Farrukh is addressing). The intent is to have
multiple PSMs addressing the PIM, spanning our panoply of widely used
commercial technologies.
It would be great if as many of you as possible could join us in the OMG and
participate in the development of the RFP, and if it suits your business
model, propose a PIM/PSM specification in the context of a submission team
(a team can be singular, btw).
We plan to have a strawman RFP ready for discussion for our meeting in St.
Louis during the last week of April. And we plan to release the RFP in our
meeting in Boston during the last week of June (a little aggressive, but we
think we can do it). Between April & June there will be much munging of the
RFP via teleconferences and eMails.
Following the issuance of the RFP our group will accept and review
qualifying submissions of specifications, selecting the one that best meets
the goals of the requirements.
The RFP will be issued by the OMG Business Modeling and Integration Task
Force in conjunction with the US Government Special Interest Group.
for more information on OMG see... http://www.omg.org/
for more information on MDA see... http://www.omg.org/mda
(Note, however, that the OMG seems to be having problems with their server
at the moment. Your patience is appreciated.)
I've been following these threads and would *love* to bring the talent
reflected here to our task at the Object Management Group. I think it's an
important one. I hope you can join us.
Regards,
Larry L. Johnson
OMG Government SIG CoChair
TethersEnd Consulting
2023 Cleveland St
Clearwater, FL 33765-3107
V/F: 888-502-9847
V/F: 202-449-5637
http://www.TethersEnd.com/
-----Original Message-----
From: soa-forum-bounces@xxxxxxxxxxxxxx [mailto:soa-forum-bounces@xxxxxxxxxxx
net] On Behalf Of Farrukh Najmi
Sent: Tuesday, April 04, 2006 10:02 AM
To: Service-Oriented Architecture CoP
Subject: Re: [soa-forum] SOA Demo - Records Management Option
Cory Casanave wrote:
>Here is the document - I have no idea what the problem was.
>
>
Just a quick look at the document suggests that the reqirements could be
met with a profile of the OASIS ebXML Registry standard (ISO 15000, part
3 and 4).
For example the record capture service could be used to annote a record
with
>1. The Record Capture Service shall provide the capability to populate
the Record_Creator_Unique_Identifier3 attribute when a DECLARED RECORD
is set > aside producing a populated Record_Creator_Unique_Identifier
attribute.
A unique identifier representing the Creator, is automatically assigned
when a record is published
>2. The Record Capture Service shall provide the capability to populate
the Record_Unique_Identifier attribute when a DECLARED RECORD is set
aside >
> producing a populated Record_Unique_Identifier attribute.
A unique identifier representing the record, is automatically assigned
when a record is published if not provided by publisher.
>3. The Record Capture Service shall provide the capability to populate
the Record_Capture_Date attribute using the SYSTEM DATE when a DECLARED
> RECORD is set aside producing a populated Record_Capture_Date attribute.
The capture date is automatically assigned by registry upon publish
>4. The Record Capture Service shall provide the capability to make
available for output all data populating the attributes created by the
Record Capture Use
> Case.4
All content and metadata may be accessed modulo access control by anyone.
> PROVENANCE SERVICE
The ebXML Registry provides a provenance information model and
supporting protocols to establish and manage provenance information
regarding managed information assets.
> Functional Requirement(s)
> 1. The Provenance Establish Service shall provide the capability to
populate the Agency_Official_Name_Current1 attribute producing a
populated >
> Agency_Official_Name_Current attribute.
> 2. The Provenance Establish Service shall provide the capability to
populate the Agency_Official_Name_Current_Date attribute when the
> Agency_Official_Name attribute is populated using the SYSTEM DATE
producing a populated Agency_Official_Name_Current_Date attribute.
> 3. The Provenance Establish Service shall provide the capability to
populate the Agency_Official_Name_superordinate a…∞)_Current2 attribute
producing
> a populated Agency_Official_Name_(superordinate a…∞)_Current
>attribute.
> ....
The ebXML Registry ifno model is extensible so all of above metadata
attributes can be supported.
The remainder of the requirement look like apretty good fit.
The federated features of the ebXML Registry allow multiple archive
stores to be searched seamlessly and to have inter-artifcat links
between them modulo access control.
I wonder, seeing all this synergy, who should I explore the possibility
of creation of a new normative specification "ebXML Registry Repository
Profile for NARA-RMS" and using it as a standards-based answer to these
requirements?
>-Cory
>
>
>
>>-----Original Message-----
>>From: soa-forum-bounces@xxxxxxxxxxxxxx [mailto:soa-forum-
>>bounces@xxxxxxxxxxxxxx] On Behalf Of Andrew S. Townley
>>Sent: Tuesday, April 04, 2006 7:10 AM
>>To: Service-Oriented Architecture CoP
>>Subject: Re: [soa-forum] SOA Demo - Records Management Option
>>
>>
>>Hi Cory,
>>
>>I'm having trouble getting the document. At the moment, I can't load
>>any pages from the OMG website. Would it be possible for someone to
>>send this to me off-list?
>>
>>Thanks,
>>
>>ast
>>
>>On Mon, 2006-04-03 at 19:51, Cory Casanave wrote:
>>
>>
>>>Last week there was a meeting with the records management community
>>>headed by NARA (National Archives) in support of turning the recently
>>>adopted records management requirements into a standard.
>>>
>>>
>>>
>>>As part of that meeting the idea came up of using records management
>>>as the core of the SOA Demo and we would like your thoughts on that
>>>option. The requirements for record management can be found here;
>>>http://www.omg.org/cgi-bin/doc?gov/2006-03-01
>>>
>>>
>>>
>>>This would be a very positive convergence of a government architecture
>>>effort, an upcoming standards effort and SOA. On the other hand, it
>>>is an area that is less understood by many than the buyer/broker
>>>/manufacturer demo and there are less solutions that could be
>>>integrated by the SOA.
>>>
>>>
>>>
>>>In any case, we will need to come to some resolution on the subject of
>>>the demo very soon. Your thoughts would be appreciated.
>>>
>>>
>>>
>>>Regards,
>>>
>>>Cory Casanave
>>>
>>>
>>>
>>>______________________________________________________________________
>>> _________________________________________________________________
>>>Subscribe/Unsubscribe/Config:
>>>
>>>
>>http://colab.cim3.net/mailman/listinfo/soa-forum/
>>
>>
>>>Shared Files: http://colab.cim3.net/file/work/soa/
>>>Community Portal: http://colab.cim3.net/
>>>Community Wiki: http://colab.cim3.net/cgi-
>>>
>>>
>>bin/wiki.pl?AnnouncementofSOACoP
>>--
>>Join me in Dubrovnik, Croatia on May 8-10th when I will be speaking at
>>InfoSeCon 2006. For more information, see www.infosecon.org.
>>
>>**************************************************************************
>>*************************
>>The information in this email is confidential and may be legally
>>privileged. Access to this email by anyone other than the intended
>>addressee is unauthorized. If you are not the intended recipient of this
>>message, any review, disclosure, copying, distribution, retention, or any
>>action taken or omitted to be taken in reliance on it is prohibited and
>>may be unlawful. If you are not the intended recipient, please reply to
>>or forward a copy of this message to the sender and delete the message,
>>any attachments, and any copies thereof from your system.
>>**************************************************************************
>>*************************
>> _________________________________________________________________
>>Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/soa-
>>forum/
>>Shared Files: http://colab.cim3.net/file/work/soa/
>>Community Portal: http://colab.cim3.net/
>>Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP
>>
>>
>>------------------------------------------------------------------------
>>
>> _________________________________________________________________
>>Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/soa-forum/
>>Shared Files: http://colab.cim3.net/file/work/soa/
>>Community Portal: http://colab.cim3.net/
>>Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP
>>
>>
--
Regards,
Farrukh
_________________________________________________________________
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP
|