RE: [soa-rm] another possible SOA diagram (revised)

[Ken Laskey <klaskey@mitre.org>]

Whatever is behind the service interface and provides either data and/or 
processing is a resource.  As intended for the 07 draft and unfortunately 
half finished in the version I actually sent to Matt:

Consider, for example, the descriptive elements that may apply for a data 
resource vs. a processing resource.  Here, we will assume the resources to 
be distinguished as follows:
·         A data resource is a source of content that accepts a request and 
returns a value or set of values in response.  The return can be an entity 
(such as a particular schema), an attribute of an entity (such as when the 
schema was last modified), or any numerical or textual value or set of 
values. The content can be static objects stored in some repository or 
dynamically generated through the use of a processing resource.
·         A processing resource is one that accepts a task and return a 
status indicating the extent to which the task was completed and 
information on how the state of entities changed as a result of the 
processing.  One or more processing resources may be invoked as part of a 
process of submitting a query and being returned a response.  From the 
standpoint of a user (either human or machine), it is unimportant what 
combination of data and processing resources are invoked as long as the 
request is satisfied.

Both types of resources are likely to have descriptive items such as a 
name, a textual description, and possibly a set of descriptors/keywords 
with a pointer to the vocabulary definition from which the 
descriptors/keywords are taken.  Both resources may also identify 
responsible parties, including who is responsible for operations, who is 
responsible for design, who is responsible for implementation.  However, it 
may be appropriate for a data resource to publish its update cycle so a 
consumer can decide if the resource is current enough for its needs.  The 
processing resource, on the other hand, might publish its current version 
number (with a reference giving a context for the version numbering 
semantics) and a development status (with a similar defining 
reference).  Additional constraints and policies could be connected with 
these descriptive elements.  For example, if a particular processing 
resource has a beta status, access may only be granted to certified beta 
testers.

Ken

At 11:52 AM 5/23/2005, Chiusano Joseph wrote:
>Ken,
>
>Given an example of a purchase order service (a service that accepts
>purchase orders and generates invoices, enables a user to check status
>of purchase orders, add line items to previously generated purchase
>orders, etc.):
>
>What would be an example of a resource?
>
>Thanks,
>Joe
>
>Joseph Chiusano
>Booz Allen Hamilton
>Visit us online@ http://www.boozallen.com
>
>
> > -----Original Message-----
> > From: Christopher Bashioum [mailto:cbashioum@mitre.org]
> > Sent: Monday, May 23, 2005 11:50 AM
> > To: 'Ken Laskey'
> > Cc: 'SOA-RM'
> > Subject: RE: [soa-rm] another possible SOA diagram (revised)
> >
> > Ken,
> >
> > I would have expected the service interface and the resource
> > to be smaller boxes inside of the service box.  It looks
> > funny to have the service off to the left, and the service
> > interface and resource on top.
> >
> > -----Original Message-----
> > From: Ken Laskey [mailto:klaskey@mitre.org]
> > Sent: Monday, May 23, 2005 11:13 AM
> > To: Christopher Bashioum
> > Cc: 'SOA-RM'
> > Subject: Re: [soa-rm] another possible SOA diagram (revised)
> >
> > The resource is the implementation that in many cases was
> > created to satisfy needs outside the SOA and only becomes
> > part of a SOA in the same way that any software package
> > becomes part of your computer.
> > Opacity says you know there is a resource but the only thing
> > you know about it is what is exposed through the service description.
> >
> > Attached is a very quick attempt to include in Duane's last diagram.
> >
> > Ken
> >
> >
> >
> >
> >

--
      ---------------------------------------------------------------------------------
   /   Ken 
Laskey                                                                \
  |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
  |    7515 Colshire Drive                    fax:      703-983-1379   |
   \   McLean VA 22102-7508                                              /
     ----------------------------------------------------------------------------------