[CNST] CNST Telecon - June 28

Tue Jul 10 10:30:33 EDT 2007

Adrian wrote:
> > we need a clear and standard way to
> > approach the identification and specification of a service. Does
> > any current CCSDS work address this?

"Service" itself is a very broad concept - there's a big difference
between a CCSDS cross support service and a pizza delivery service. Even
within the narrower confines of data processing and communications,
there are "client-server" and "peer-to-peer" type services (which one
can think of as horizontal) vs. layered ISO Open System Interconnection
(OSI) services (where the "service" is what's offered by a lower layer
to a higher layer, and thus can be thought of as vertical). 

The first year of development of the Cross Support Reference Model
(CSRM) (and in particular the SLE part) was largely consumed with
then-Panel 3 members talking past each other as some of us were thinking
"peer-to-peer" and others were thinking "OSI layered". In the process of
trying to sort out the different notions of service, we even put out the
"Terminology, Conventions, and Methodology" (TCM) Green Book (CCSDS
910.2-G-1, 
http://public.ccsds.org/publications/archive/910x2g1.pdf), which
established 
the peer-to-peer model as the basis for cross support services. The TCM
used the (since-deprecated) ISO Abstract Services Definition Conventions
(ASDC). (Note - even though the ASDC spec itself was deprecated by ISO,
the underlying notions parallel current modeling methodologies such as
UML and even the buzzwordy "Service Oriented Architecture". I think OSI
deprecated ASDC not because it was "wrong" but because other modeling
methodologies/taxonomies had gained more market share). 

But even ASDC was vague, in order to be applicable to the
widest-possible set of applications (they didn't put "abstract" in the
title for nothing). And indeed, everything was literally defined in the
abstract: "abstract-service" was defined as "a set of capabilities that
one abstract-object offers to another by means of one or more of its
abstract-ports." In itself, the definition is not sufficient to "do"
anything - you have to add context and qualification to make them useful
(kind of like abstract classes in object-oriented programming
languages).

But getting back to the question of whether CCSDS is doing anything
currently in this area - in the spring I had the action item out of the
CSTSWG to update the terminology that had appeared in the SLE transfer
service specifications to make it applicable to the more-general cross
support transfer service (CSTS) specifications. In the process of doing
this I revisited all of the current definitions in the CSRM and the SLE
transfer service specifications, and was surprised to find that in a
number of cases there were not explicit definitions for some pretty
fundamental terms (e.g., "cross support service"), but they could be
inferred from the context of those documents. In a technical note that
was sent to the CSTSWG in April, I proposed definitions for (among other
terms) "cross support service", "cross support transfer service"
(defined as a subclass of cross support service), "SLE transfer service"
(defined as a subclass of CSTS), space link service (defined as a
subclass of cross support service), "cross support transfer service
instance", "cross support service agreement", and "cross support service
package". A copy of the note is attached for anyone who wants to see
exactly what's been recommended. 

There's been no feedback from CSTSWG members yet on this note, but from
my experience that's not unusual - activity seems to ramp up as the
international meetings approach. Also, this note reflects something of a
"bottoms up" approach - i.e., how to morph the existing CSRM/SLE
terminology. I've tried to push that morph in the direction of being
consistent with the IOAG Cross Support Service Architecture, but the gap
is not completely closed.

John

> -----Original Message-----
> From: cnst-bounces at mailman.ccsds.org [mailto:cnst-
> bounces at mailman.ccsds.org] On Behalf Of Peter Shames
> Sent: Monday, July 09, 2007 5:05 PM
> To: Adrian J. Hooke
> Cc: NASA Consolidated Network Services Team
> Subject: Re: [CNST] CNST Telecon - June 28
> 
> The RASDS describes how to depict service interfaces, but it is
> rather abstract.  it also describes how to depict service interfaces
> from different viewpoints, as we have been doing.  The TERMA guy
> (Gert Villemos, I presume) wanted some sort of service interface spec
> that looked more like what RM-ODP defined.  This is essentially a
> service interface / binding spec, which is indeed useful, but is of
> more value from a software architecture view than from an
> interoperability view.
> 
> We could provide such a spec if we determined that it was really
> useful for interoperability.   However, as i've pointed out before,
> the Internet has interoperability up the wazoo without a single
> interface spec, and JMS has all sorts of interface (API) specs, but
> no interoperability.  You can have both, but one does not give you
> the other.
> 
> Peter
> 
> 
> 
> On Jun 28, 2007, at 7:01 AM, Adrian J. Hooke wrote:
> 
> > Also, the guy from TERMA here points out that if we are talking
> > about a service infrastructure, we need to first formally define
> > "what is a service?", i.e., we need a clear and standard way to
> > approach the identification and specification of a service. Does
> > any current CCSDS work address this?
> >
> > ESA's view is that we need an e2e architecture, that exposes "back
> > end" services from control centers and "front end" services in
> > space, as well as our current "middle" services.
> >
> > ///a
> >
> >
> >
> > _______________________________________________
> > CNST mailing list
> > CNST at mailman.ccsds.org
> > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/cnst
> 
> _______________________________________________________
> 
> Peter Shames
> Manager - JPL Data Systems Standards Program
> InterPlanetary Network Directorate
> Jet Propulsion Laboratory, MS 301-230
> California Institute of Technology
> Pasadena, CA 91109 USA
> 
> Telephone: +1 818 354-5740,  Fax: +1 818 393-0028
> 
> Internet:  Peter.Shames at jpl.nasa.gov
> ________________________________________________________
> "We shall not cease from exploration, and the end of all our exploring
> will be to arrive at where we started, and know the place for the
> first time"
> 
> 
>                        T.S. Eliot
> 
> 
> 
> _______________________________________________
> CNST mailing list
> CNST at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/cnst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TermsForCSTSProcSpecR1.doc
Type: application/msword
Size: 143872 bytes
Desc: TermsForCSTSProcSpecR1.doc
Url : http://mailman.ccsds.org/pipermail/cnst/attachments/20070710/39ba845a/TermsForCSTSProcSpecR1-0001.doc