On 11/15/06, Michael Poulin <[EMAIL PROTECTED]> wrote:
>
> I am not clear on what Shashank meant by "a specific instance of service is
> identifiable by its description"...
>
> I do not think "a specific instance" is a run-time executable, aka class
> instance, i.e. object, in Java. And I am not sure I have to care about it.
> When a service contract is found n the Service Repository and accepted by the
> consumer, then service run-time connectivity description is found in the
> Service Registry and the consumer physically contacts the Service run-time
> code, why anyone might be interested in how the Service is implemented (one
> of SOA principle is implementation transparency, right?) - is the executable
> instantiated upon request (and what instantiated in the case of lazy
> invocation) or it is an application scoped 'multi-threaded' instance? Why is
> it important?
>
> To me, the matter is in what functionality is available in particular
> version of the service (the version is a part of the contract while version
> control may be implemented in many different places in the infrastructure
> including Registry, directory, ESB , etc.).
>
> I think the question Shashank asks is in whether a provider has to create a
> special service ("service instance") for each consumer or something may be
> reused. I believe that the entire service, including its Service Contract,
> may be perfectly reused or shared between multiple consumers. If go deeper, a
> lot of service functions may be reused in the scope of the service with only
> some differences (subsets of functions) defined in individual/sub-group
> Service Contracts (do not even mention reused code).
>
> It appears to me like the following: two consumers define two Service
> Contracts with the provider; Service Contracts include the same Service
> version but different subsets of accessible service interfaces, plus,
> different regulations/policies the provider has to preserve with respect to
> each consumer.
>
You have got me correct till this point.
>
For example, the same function has to be provided for internal and
external for an organization users, under different regulations and
via different interfaces. In particular, a Service cannot be reached
via IIOP for external users (this interface is not exposed to then in
the Service Contract) while internal users are not supposed to use
publicly opened Web port, i.e. another interface of the Service (e.g.
a provider is not responsible if some of the internal request with the
Web get rejected for the internal users).
>
Assume we need to provide internal and external service through same interface.
In this case how to describe service being accessed by having
independent contract.
Two clients are accessing different services,as service is completely
defined/described including its description/contract etc. or they are
accessing same service?
In case they both access/use same service this means service is
independent of individual contract by interacting client.
As correctly mentioned, these instances I don't meant as to be like
instances of a class (or objects) but just as an abstraction!!
regards,
shashank
> Well, I am not sure I am answering the question which I speculatively
> formulated...
> - Michael
>
>
>
>
> "shashank d. jha" <[EMAIL PROTECTED]> wrote:
>
>
>
> On 11/14/06, Michael Poulin <[EMAIL PROTECTED]> wrote:
>
> >
> > To me, if two consumers operate with my code+procedures in accordance to
> two different service contracts, this means that my code+procedures have
> different responsibilities.
> >
> > As I said before, for consumers, these are two different services or, in
> some cases, two different versions of the service. For IT, it is more complex
> issue because one set of responsibilities (capabilities) may fully include
> another set of responsibilities (capabilities),i.e. use a superset of the
> code base, which happens when a new feature added to the service without
> interference with old features. I would define a new version of the service
> but NEVER say these are two the same services. I've published several
> examples of this together with observations what happened when versioning
> was ignored.
> >
>
> This is new thought process I think. Service being defined with
> clients' perspective. So that service is same or not is defined by
> clients interaction with service.
> But than another interesting question...I am not sure it makes sense or not..
>
> Theoretically a service instance may exist (uniquely) only after a
> client has started interacting with a service right? As a specific
> instance of service is identifiable by its description ..including
> policy and contract negotiated with a unique client.
>
> Or a service instance exists or is created for each client by a
> service depending on policy and contract?
>
> regards,
> shashank
>
