Re: Multiple specification of constraints

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:tJ22c.55872$hh5.40943_at_newssvr33.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c2a78a$ams$1_at_news.netins.net...
> > I'll start with a couple of definitions of the word "service" as
requested
> > in a previous response in this topic.
> >
> > From Dale Asberry on the jini-users list:
> > "A service is a function that is well-defined, self-contained, and does
> not
> > depend on the context or state of other services."
>
> Well-defined meaning ... ?
> Self-contained meaning ... ?
> No dependencies meaning that it can't use other functions to accomplish
its
> task?
>
> This definition sounds like a "function" in general, sort of. I really
don't
> understand exactly what well-defined (in terms of what?) and
> "self-contained" mean. I realize these aren't your definitions, Dawn... I
> just have to agree with Fabian Pascal on how fad- and buzzword-driven the
> industry is. There may be decent concepts there, somewhere, but I'd like
to
> clarify them.
>
> > and from the W3C:
> >
> > "...a service is a software agent that performs some well-defined
> operation
> > (i.e., "provides a service") and can be invoked outside of the context
of
> a
> > larger application."
>
> "Agent" has a meaning distinct (I think) from the way it's used here.
While
> not crystal-clear, an agent is a piece of software that moves itself into
> different VMs, executing code in each new location. There are other
> meanings, but that's what most differentiates it (at least for me) from
> other concepts. I wouldn't say a service IS an agent. An agent may PROVIDE
> or INVOKE services, but in that respect they're like functions again.
>
> "Outside the content of a larger application"... what does that mean?
Unless
> we're clear on these things, it seems rather odd to base the "next new
wave"
> of computing on them.

OK, maybe I'll have to devise one of my own since there is a fairly well-defined and not very profound picture of what a service is in my thinking. Here's a first attempt:

A service is a function with the following properties:

1. It implements a "published" interface and is registered with a lookup service (such as UDDI UBR or a Jini LUS). There is a subset of all human beings and/or software with access to look up the specification of what the function takes as input, what it gives as output and what processing it does.
2. A client using the service must specify the name of the function, where to find it, and how to launch it (information it might get electronically from the lookup service) along with input parameters but does not provide the service with a run-time environment wherein to launch.

Is that any clearer, Eric? I suspect not, so I'll work on it more in the future.

> > What I mean by decoupling is that the constraint & validation "services"
> be
> > able to be used independent from the CRUD services. The CRUD services
> would
> > then be clients of the constraint services, as would the UI.
>
> I agree with you, and so does Bob (in a relational sense). Relations
aren't
> tied to CRUD, nor is something like Tutorial D. They're useful outside
those
> arenas. But while "validation" can be used outside CRUD, the reverse
should
> never be true, else bad data corrupt you.
>
> > I think of everything as functions and everything as objects.
>
> There's a fundamental conflict there.

No, there really isn't. The relations I care about are there with a key so they can be thought of as functions, such as Person("12345")=("Mary", "Fox", "4/6/56", "brown")

You can likely see that one direction is easy -- all functions are objects. They are objects of the type "function". The other direction is really based on the fact that computers need handles of some sort to find things. So, objects can be seen in terms of object is identical to seeing function(reference-id)=entity or function(simple-value)=entity. for example, the object that is the google home page could be represented as a single point in a broader WebDocumet function so that WebDocument(www.google.com)= ... (put page here).

We could make this a function specific only to this object if we wanted to, by narrowing down the domain of the function to just www.google.com -- this would only be done in order to be able to say that all objects are functions and all functions are objects. You take an object as input to a function and return another object, recognizing these objects are, themselves, functions.

> > Instead of
> > the term "relational operators" they beome functions on functions, for
> > example.
>
> Again, though, why would you program in Java? There are much, much better
> languages for such a philosophy - LISP, as well as Haskell and ML and the
> like, have much stronger support for functions of various orders. The
reuse
> you'll gain in such languages dwarfs anything from O-O polymorphism.
>
> > The client needs to know how to tell the service to start, pass it
> > parameters, and receive the output.
>
> A function call, right?

yup

> > The client does not need to know what
> > run-time environment the service will run in, nor anything else about
the
> > implementation of the service.
>
> OK, but the client does have to use SOME sort of protocol (e.g. SOAP), and
> thus needs a URL. Either that, or use a proxy, but that still comes from
> somewhere and requires configuration. The idea of looking up a function
> (service) in a trusted "directory", however, is a good one - rather than
> having the client do something like "String response = new
> FooService().doIt()".

Yes, the information about the protocol would also be in the services directory.
>
> > If there is a validation service for a specific type that is available
> > (anywhere on the internet, for example) to your UI or front-end service
> and
> > to your CRUD services, then your application could be a client of this
> same
> > service twice. A possibility would be that there be a States validation
> > service and a country validation service so your application need not
have
> a
> > table of states and another of countries itself. The service could
return
> a
> > boolean for whether the entered data is a state (counrty) and the name
of
> > the state based on the abbrev entered. My software application could
use
> > the same service as yours, which we could both license from a service
> > provider.
>
> As long as you're talking to a trusted provider of this service, it
doesn't
> matter where it came from. It's an implementation detail - you could write
a
> crude stub version, and then later call upon a service provider. As long
as
> your application code doesn't know where the service is coming from,
you're
> covered.

Exactly!

> However, in a relational context, why not just have the RDBMS expose this
> service as a relation? Then it could be clearly specified what the
> "relationship" is between the results of that service and your other data.
> You're still specifying the equivalent of a foreign key constraint - you
> don't want data with an invalid country going in there, do you? I think
what
> you're describing is more implementation - we're getting the data from
> elsewhere, rather than storing it in a base relation.

I think of it more as getting the service from whereever and that service could be one that validates data entered into a system, or data that is requesting storage in a repository or whatever. Where that service gets any data it needs other than the input parameters is irrelevant.

> > Just a thought -- as with every possible solution, there are pros and
> cons.
> > But this approach eliminates specifying constraints in your database
using
> > one set of tools and then again in your UI using another set of specs
(and
> > logic and run-time environment).
>
> I think it adds more complexity than you think. Properly factoring
services,
> and even invocations of remote services, can get very hairy in a
> moderately-complex application. I've seen it sink several projects. It's
> actually far more difficult than designing a normalized set of relations,
> because there are fewer solid guidelines on which to build. For example,
the
> "types" of the function calls become a major problem, unless of course you
> do what so many others do: make 'em all Strings.

That is my preference (all strings) but that is based more on experience than theory because I would like to control the response to the service client.

>
> > Given that most types of data handled by
> > one company are also handled in others,
>
> Ah... it all depends on what you mean by "type."
>
> > and that a significant part of
> > writing software has to do with the validation information related to
> > various types, there could conceivably be more reuse within a company
and
> > across companies.
>
> I will give XML one thing: it has gotten groups of companies talking about
> their data and what it means. I regret, though, that it provides such a
> crippled format in which to express those meanings.

I think of it as verbose -- where it is crippled compared to comma-quote or card column data transmissions that have occured historically?

> > Given that an order is prepared by one company and then
> > processed by another, they could both use the same services for
validating
> > the information so there is no guessing of what the validation
> > functions/services will do at the other company.
>
> You're assuming a lot of trust and a lot of commonality. While the
> commonality does exist at an abstract level, many in those companies
> (programmers included) view only the concrete manifestations of the data,
> and some of those manifestations are inextricably linked with internal
> procedures, automated and manual. You're still going to run into EDI X.12
> syndrome: customer A wants to use the <Customer-Order-External-Ref>
element
> to mean their customer's reference, while customer B's system exports it
> from the field containing their external warehouses' reference number.

Most definitely -- it does nothing to address common semantics.
>
> Validation would depend on a common agreement on "type." And there is much
> more to type than what XML can express.

or that anything can express, including English. Having a service that is agreed upon as a means to validate a particular data element does not eliminate such discussions between people on what the data really are.
>
> In any event, assuming such commonality does exist, relational languages
are
> still far and away the best ways to express them. As an example outside
the
> database realm, try Alloy - it's a specification language that uses only
> relations, and let allows you to do things like the authors have:
> demonstrate railroad safety protocol reliability, show errors in the MS
COM
> specification, etc. That power extends to data.

I'll check out Alloy, but I guess I'm not a believer right now, although I have been in the past. Maybe I'm a prodigal son who will return to preaching the merits of the relational model, but I'm finding more benefits in other approaches right now (such as modeling data as graphs, di-graphs, trees, and other functions).

>
> > If you track one piece of
> > data today from entry through to archival, how many different
> > programmers/dbas using how many different toolsets are writing
> > sortof-similar-and-should-be-the-same constraint logic? Too many,
> methinks.
>
> Right, which is why a good relational language would enable clear
> communication of those data.

OK, I'll buy that given this thread is about not having multiple specs -- but then those database services need to be usable by clients with a greater diversity of needs. For example, clients that need to toss a combo box on a screen (or even though that need to know what to toss up on the screen).

I know I'm still giving muddy answers. I'll keep trying to put words to thoughts. Thanks. --dawn Received on Fri Mar 05 2004 - 19:41:50 CET