Re: Multiple specification of constraints

"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.

> 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.

> 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?

> 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()".

 > 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.

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

> 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.

> 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.

> 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.

Validation would depend on a common agreement on "type." And there is much more to type than what XML can express.

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.

> 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.

• Eric