|
Well, if Shane thinks he is late, that would make
my comments out of date, but, unfortunately, my time has been very
consumed.
I agree that each MDE will have their own interface
and affect on the policy. I would imagine that MDE functions end up
grouped together by some vendors and in such a condition should create a single
point of reference.
I recognize that the LegalXML community has adopted
the SOAP envelope in replacement of the LegalXML envelope, which is fine as long
as the SOAP header contain the proper entries that it is a LegalXML
application. The net affect is that there should be a standard method for
LegalXML to recognize that the SOAP envelope is conforming to the LegalXML
standard. Without such a behavior it could create significant
problems.
I agree that adopting the SOAP XML structure does
not demand SOAP communications but without LegalXML markers in the header, with
version controls, possibly policy controls you will have problems. If I
have a system that has been running for mutliple years and I have several
external MDE systems interacting with it, I better know what they are sending
me, and I need to know up front the version of LegalXML, and policy version they
are conforming to. The idea that I can force each external system to
upgrade at a given time is never going to happen.
Dallas
----- Original Message -----
Sent: Monday, August 01, 2005 11:03
AM
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:
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
Scott
Came has posted on KAVI the domain
models, definitions, and GJXDM mapping spreadsheets for all of the ECF 3.0
messages. On the conference call
that just concluded we agreed to vet those documents
on the following timeframe:
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:
Jim
Cabral will continue to moderate the
eService discussion until it is resolved.
A subcommittee of Bergeron, Came,
Cusick, Durham
and Leff will develop the requirements for an ECF 3.0 profile, using the WS I
profile as a means of identifying all such requirements. This process will necessarily also
refine the non-functional requirements.
Complete minutes will follow in
due course.
John
M. Greacen
Greacen
Associates, LLC
HCR
78 Box
23
Regina,
New Mexico 87046
505-289-2164
505-289-2163
(fax)
505-780-1450
(cell)
john@greacen.net
|