"To the pundits out there, where should the processing fee be represented in a Web Services world? Would these be something to specify via WS-Policy?"
It should be part of the policy.Jan said:
"But with SOAs the situation is exactly the same. There is nothing in
the API definition that is machine readable and would provide
information about the call order."
That's what WS-CDL is for. (But I don't know of any tooling that supports it yet.)the API definition that is machine readable and would provide
information about the call order."
I recall in the early 1990's talking about the benefits of using a well-defined interface -- and in those days I was talking about CORBA IDL. There are degrees of well-defined-ness. Most distributed object technologies provide machine-readable interface definitions that can generate client proxy code. Compare that to the typical MOM interface -- definitely not well defined...
Anne
On 2/24/06,
Todd Biske <[EMAIL PROTECTED]> wrote:
This is actually a very interesting question. I think Anne hits all
the technical points right on the nose (as she always does). There
are some elements that Anne points out that do differentiate a well-
defined interface in the Web Services world from a typical Java or C#
class or interface definition. The bulk of it is centered around the
non-functional aspects and interoperability goals of a Web Services
based SOA. If we're dealing with local invocation of objects, the
transport, message formats, etc. are all defined by the underlying
platform. Some non-functional aspects can be externalized, such as
Security, in the same way that WS-Security and WS-SecurityPolicy
externalize it within a Web Services model.
If you move to a remote invocations, as long as you stay within a
platform-specific model, such as .NET Enterprise Services or Java
RMI, things like transport bindings may still be defined or implied
by the platform. CORBA moves into a more heterogeneous model, with
CORBA IDL being more analogous to WSDL, but I think each new
description language has tackled the problem better than the
predecessors.
Now, the more interesting part of the question to me are the
qualitative aspects of "well-defined." You can have WSDL and WS-
Policy and still have something that does not constitute well-defined
in terms of benefit to an SOA. Here's where having a background in
usability or human factors come into play. User interfaces are
clearly NOT well-defined. A bad user interface may lack clarity of
purpose, be mismatched to the context in which it is being used, have
hidden elements, etc. The same thing applies to a services
interface, or even an object interface. Simply put, the interface
should demonstrate to the consumer exactly what behavior will be
executed, no more and no less, and all of the constraints associated
with it. A very easy example to comprehend is the notion of side
effects. If I have a "deposit" operation in my bank account
interface, I expect that it will increase my balance by the amount I
deposit. If, however, it takes out $2.00 for a processing fee and
I'm not aware of that, it's a poorly defined interface. These
aspects may not always be easy to define in terms of a functional
interface. Actually, this is a better example than I thought for the
discussion. To the pundits out there, where should the processing
fee be represented in a Web Services world? Would these be something
to specify via WS-Policy? In the real world, examples of this
include ATM machines that now warn you that you're going to be
assessed bank charges prior to executing a transaction, and TurboTax,
which gives you multiple options for paying for the filing fees at
the time you submit your return. It can be paid via credit card,
deducted from your refund (if you're getting one), etc. If it
automatically took it out of a refund without telling you, that would
be bad.
I'm interested in what others have to say. Now I'll go back and try
to help my wife figure out which button in the minivan is the rear
defroster versus the front defroster. One button has a rectangular
window with wavy lines in it, one button has an arced window with
wavy lines in it. Completely intuitive, right?
For those of you with an interest in human factors, Mark Hurst has a
newsletter and blog available from http://www.goodexperience.com/ and
also maintains a site with examples of bad interfaces at http://
www.thisisbroken.com/.
-tb
On Feb 24, 2006, at 8:37 AM, Jan Algermissen wrote:
> Anne,
>
> thanks - but...
>
> Any common OO API is then also 'well defined' because what I need
> technically is all right there in the method signatures (and it is
> even machine readable, too - of course).
>
> What is not in a common OO API is the order in which the methods are
> to be called - that 'additional semantic information' just gets hard
> coded in the client.
>
> But with SOAs the situation is exactly the same. There is nothing in
> the API definition that is machine readable and would provide
> information about the call order.
>
> So, how is moving the API description into an XML file any more 'well
> defined' than traditional OO API class definitions with method
> signatures?
>
> IMHO, the notion of well definedness of an API just doesn't hold as a
> distinguishing ... umm ... constraint ... between the SOA and the OO
> paradigm.
>
> Remaining confused...
>
> Jan
>
>
>
> On Feb 24, 2006, at 2:20 PM, Anne Thomas Manes wrote:
>
>> A well-defined interface is an interface that is defined using
>> standard interface description languages. The interface description
>> should be machine-readable so that code can be generated from it. A
>> comprehensive interface description should describe the location of
>> the service (or some means to find it), the protocol bindings
>> supported by the interface, the operations supported by the
>> service, the message formats that are exchanged with each
>> operation, any constraints and capabilities associated with the
>> interface, supported interchange patterns, and semantic information.
>
>
>>
>>
>> In web services, a comprehensive interface description would be
>> defined using XML Schema, WSDL, WS-Policy, WS-CDL, and RDF.
>>
>> A poorly-defined interface requires human communication to
>> determine the formats and protocols required to access the service.
>>
>> Anne
>>
>> On 2/23/06, Jan Algermissen < [EMAIL PROTECTED] > wrote:
>> SOAists,
>>
>> I keep reading about "consumers communicating with services through
>> *well defined interfaces*" as being one of the essential aspects of a
>> SOA.
>>
>> But I cannot figure out, what it means that an interface is "well
>> defined". Especially I do not understand what an interface is that is
>> *not* well defined.
>>
>> Can someone shed some light on this?
>>
>> Jan
>>
>>
>> _____________________________________________________________________
>> _
>> __
>> _______________
>> Jan Algermissen, Consultant & Programmer
>> http://jalgermissen.com
>> Tugboat Consulting, 'Applying Web technology to enterprise IT'
>> http://www.tugboat.de
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> SPONSORED LINKS
>> Computer software Computer aided design software Computer job
>> Soa Service-oriented architecture
>>
>> YAHOO! GROUPS LINKS
>>
>> Visit your group "service-orientated-architecture" on the web.
>>
>> To unsubscribe from this group, send an email to:
>> [EMAIL PROTECTED]
>>
>> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>>
>>
>
> ______________________________________________________________________
> __
> _______________
> Jan Algermissen, Consultant & Programmer
> http://jalgermissen.com
> Tugboat Consulting, 'Applying Web technology to enterprise IT'
> http://www.tugboat.de
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
