I agree with Gregg on "this discussion is really not going down a path of
useful result".
What we have to find in the end: that programmatic service interface does not
include non-functional characteristics of the service described in the Service
Contract? - it is obvious. That the same code may be used under different
Service Contract? - it is obvious. That different service features may be used
behind the same programmatic interface? - it is also obvious. That service
consumer gets aware of non-functional features not from programmatic interface?
- it is trivial. May we call an implementation a service if its functions are
not defined in, e.g., WSDL only? - the SOA RM answers YES. Should a developer
know about such features and distinguish between "service instances" on this
basis? - my answer is 'not necessary; it is the architect's and BA job' but for
the service consumer it does not matter, right?
- Michael
Gregg Wonderly <[EMAIL PROTECTED]> wrote:
shashank d. jha wrote:
> Two instances of service is executing now? (may be possibly service is
> re-used from service repository (instances are not same as object
> instances as mentioned by you) . Still min. two instances of service
> must exist to support two different contract).
>
> Or single service is running, and different clients interact with
> service using different contract, as such service is same.?
I think this discussion is really not going down a path of useful result. It
is
true that all of the attributes of connectivity provide part of the 'contract'
of the service. But, variability of connectivity capabilities is also a
description of the service. So, in the end, the ability to provide access on
separate networks, using separate wire protocols, using separate invocation
layers etc. is nothing more than a more flexible service contract
implementation.
With Jini, we do this quite readily using the JERI stack to change these
things
at deployment time. Other messaging/invocation technologies have similar
capabilities. Unless the services operations are limited/controlled by these
details, it really is the same service.
A simple example would be encryption. The presence of such a wire protocol
facility, application data wrapping detail, might control which functions a
service would allow the user to execute. This is still part of the service
contract. It is controlled by the invocation environment, but that does not
change the fact that it is a capability of the service which is simply
controlled/requested by the access/invocation/transport mechanism/interface.
Gregg Wonderly
---------------------------------
Sponsored Link
$200,000 mortgage for $660/mo - 30/15 yr fixed, reduce debt, home equity -
Click now for info
