[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-courtfiling] Comment period for existing artifacts
I apologize for being miserably late
with these comments.
Policy and Policy MDE:
In the current work-product, there
exists a single CourtPolicy and PolicyMDE for the
system.
I do not believe this is what we
want.
It implies the older
LegalXML policy model (and other standards have adopted this as well), where
there exists a single 'policy' for the system describing how ALL components
are to interact.
A single policy for the
entire system, will become a large convoluted beast.
It will be difficult to
develop, maintain, manage, and consume.
Instead, we want to adopt
a model where each MDE has its own policy to describe how *that*
MDE behaves.
We need to think in terms
of 'FilingReview-Policy', 'FilingAssembly-Policy', 'CourtRecord-Policy,
etc
Query MDE:
In the current work-product, there
exists a single query MDE for the system.
I do not believe this is what we
want.
Just as each MDE has the potential to
support one or more transactional processes, each MDE also
has the potential to include query
interfaces.
So, there would not be a singular
'QueryMDE' for the system....
Instead:
A 'FilingReviewMDE' should/can include
query interfaces related to 'FilingReview' data.
Examples: 'GetFilingStatus',
'GetFiling', 'GetDocument', 'GetPolicy'
A 'CourtRecordMDE' should/can
include query interfaces related to 'CourtRecord' data.
Examples: 'GetCase',
'GetDocument', 'GetPolicy'
A 'FilingAssemblyMDE' should/can include query interfaces related to
'FilingAssembly' data.
Examples: 'GetPolicy',
'Get?? A 'ServiceMDE' should/can includes query interfaces related to
'Service' data.
Examples: 'GetPolicy'
Base message as
SOAP Message:
I think that ALL of our
XML messages should be in SOAP format.
I feel pretty
strongly about this too.
I know that, many of you
will quickie shake your heads 'No Way', though I am not entirely sure
why.
One argument is that
a SOAP message format would restrict us to a particular implementation
profile.
That is not
true.
We must remember that
SOAP messages, are merely an XML format for expressing
function-and-argument.
(i.e. Remote Procedure
Calls) At heart, it is an XML
message, that includes 'action', and 'arguments', as well as being able to
express 'caller' and 'recipient', and all other sorts of useful
data.
By function-and-argument,
I mean things like: 'GetCase (
myGjxdmCaseId )' and 'ReviewFiling ( myGjxdmFiling )'
SOAP messages
are XML. And, just like any other XML message, SOAP messages can be
exchanged between components, in any profile we like.
COM, CORBA, WebServices,
eBXML, and, yes, sneaker net.
We need to understand:
You don't have to implement WebServices to assemble OR parse SOAP
messages.
As with any XML message
format, you can read and write SOAP messages, using standard XML
tools.
It is no more difficult
than reading/writing the non-SOAP messages we are currently proposing to
invent.
I think it would be quite
silly and short-sighted of us to NOT use the well-defined SOAP format as
our base for expressing function-and-args.
We will not be anywhere
near as successful if we attempt to invent our OWN format for that
purpose.
These UML-ish
statements might help illustrate what I am advocating:
Instead of
this:
GjxdmMessage{ GetCase ( myGjxdmCaseId ) }
We have
this:
SoapMessage{ GetCase ( myGjxdmCaseId ) } In COM, instead of
this:
COM-->Send( GjxdmMessage )
We have
this:
COM-->Send( SoapMessage ) In HTTP, instead of
this:
Http.Send( GjxdmMessage )
We have
this:
Http.Send( SoapMessage ) NOTE: The HTTP example,
when implemented with WebServices/ebXM toolkits, can be simply thought of
as:
WebService-GetCase( myGjxdmCaseId )
...only because
WebService toolkits nicely hide the 'HTTP.Send' part of the
process.
No biggy.
In the
end, exchanging SOAP messages is the same as exchanging
XML.
SOAP *is*
XML.
- Shane
Durham
LexisNexis From: John M. Greacen [mailto:john@greacen.net] Sent: Tuesday, July 19, 2005 11:08 AM To: Electronic Court Filing Technical Committeee Subject: [legalxml-courtfiling] Comment period for existing artifacts Comments and suggested changes from
TC members by no later than the close of business on Wednesday, July 27th. Review of the comments by the
subcommittee of Cabral, Came, Clarke, Greacen and Tingom by Sunday, July 31st. Resolution of outstanding issues
identified by the subcommittee on a conference call at our regular Tuesday time,
August 2nd. I have scheduled a conference call
for that purpose as follows: Date
Tuesday, August 2, 2005 Time
1:00 pm Eastern time; 10:00 am Pacific
time Call in number
1-605-528-8855 Access code
2892164 We also decided on the following
additional steps: A subcommittee of Bergeron, Came,
Cusick, Complete minutes will follow in due
course. John
M. Greacen Greacen
Associates, LLC HCR
505-289-2164 505-289-2163
(fax) 505-780-1450
(cell) john@greacen.net |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]