Loading ...
Sorry, an error occurred while loading the content.
 

Re: [service-orientated-architecture] Re: Joe on Avoiding Big Boo-Boos with SOA

Expand Messages
  • Michael Poulin
    Anne wrote Therefore it s not necessarily appropriate to configure QoS with the service definition... The QoS should be configured based on the contract, not
    Message 1 of 88 , Jul 31, 2007
      Anne wrote "Therefore it's not necessarily appropriate to configure QoS with the service definition... The QoS should be configured based on the contract, not on the service."

      I agree that QoS is managed/modified based onthe Service Contract. However, what to do with the case where the service sell point is performance? I think, that it makes sense to publish some minimal characteristics of QoS with the service description while QoS configuration better be based on the Contract.

      - Michael

      Anne Thomas Manes <atmanes@...> wrote:
      On 7/31/07, Shashank D. Jha <shashank.dj@ gmail.com> wrote:
      >
      > On 7/22/07, Anne Thomas Manes <atmanes@gmail. com> wrote:
      > >
      > > On 7/21/07, Shashank D. Jha <shashank.dj@ gmail.com> wrote:
      > > >
      > > > On 7/20/07, Rob Eamon <reamon@cableone. net> wrote:
      > > > >
      > > > > > Too simplistic.
      > > > >
      > > > > Perhaps.
      > > > >
      > > > > > What about deterministic and reliability aspect of
      > > > > > such software systems?
      > > >
      > > > I think QoS aspect of a service should be first class concept/aspect
      > > > to be addressed by SOA to ensure that SOA doesn't go OO or CBD way but
      > > > is more comprehensive and meaningfully usable.
      > >
      > > One of the core principles that I espouse for SOA is separation of
      > > concerns between the service and the infrastructure that supports it.
      > > The infrastructure is responsible for QoS. The service requirements
      > > dictate what type of infrastructure is required to support the service
      > > and may influence the technologies used to implement the service.
      > >
      > > The specific QoS capabilities required by a service/interaction are
      > > specified as policies as part of a runtime contract. The
      > > infrastructure is responsible for ensuring that policies are enforced.
      >
      > Like we did in component technology, where we had components and
      > deployment platform/infrastruc ture. But one of the difference from
      > component and object is that "configuration" is inherently part of a
      > component specification, as in CCM, other than specification for
      > services provided and services required by the component. Similarly I
      > feel QoS should be part of service definition itself. May be that will
      > complicate the "Service" so may be assigned to "Infrastructure"

      Would you agree that QoS requirements have a different lifecycle from
      a service? Based on today's requirements (contracts with consumers), a
      service requires this level of security, auditing, and performance.
      But tomorrow a new consumer might come along that requires more
      stringent QoS. And here's the rub: QoS requirements may be a function
      of a particular contract between a consumer and provider -- not just
      the service. Therefore it's not necessarily appropriate to configure
      QoS with the service definition. The QoS should be configured based on
      the contract, not on the service.
      >
      > > >
      > > > > IMO, those characteristics would be driven by other constraints, not
      > > > > SOA principles. The primary (only?) "-ility" SOA explicitly addresses
      > > > > is flexibility.
      > > > >
      > > > > > Do we need prefabricated services to collaborate or it will ad-hoc?
      > > > >
      > > > > I'm not sure what this means.
      > > >
      > > > Remember we are doing Enterprise Architecture. So service
      > > > specification should have enterprise features including consistency,
      > > > certain deterministic behavior, robustness etc. after from
      > > > governance, contracts, business behavior, so these characteristic
      > > > should be able to specify for a service.
      > >
      > > I think you're talking about what I refer to as infrastructure
      > > services. The bits and pieces of the infrastructure that implement
      > > common, reusable capabilities like security, auditing, reliability,
      > > persistence, etc.
      >
      > I was not sure if the current definition of SOA differentiates between
      > Infrastructure services and business services. So my suggestion.

      As far as I'm aware, there is no "current definition" of SOA. I tend
      to use the following taxonomy to describe different types of services:

      - functional services (services that expose a single, relatively
      discreet business function)
      - data services (services that expose data or information)
      - infrastructure services (services that implement non-functional capabilities)
      - composite services (services that expose a more comprehensive
      business function, typically orchestrating one or more other services)

      Anne

      >
      > regards,
      > Shashank D. Jha
      >
      >
      > > >
      > > > > > How to model a Service?
      > > > >
      > > > > SOA cares only that there is a defined interface and that it is
      > > > > separate from the implementation. SOA is mum on the details of the
      > > > > service itself. Modelling a service will be guided by other
      > > > > principles (e.g. OO, etc.).
      > > >
      > > > OO (Real world entities) principals were fundamentally different from
      > > > SOA (Industry's best practices for business agility) principals. they
      > > > were not developed to address enterprises IT concerns, but were to
      > > > address software development concerns. So same modeling concept is
      > > > limiting for a Service modeling.
      > >
      > > I agree that we don't have an effective modeling notation to represent
      > > policy-driven infrastructure.
      > >
      > > Anne
      > > >
      > > > regards,
      > > > Shashank D. Jha
      > > >
      > > > > > We need to address minimum set of requirement to start adopting SOA.
      > > > >
      > > > > To make sure I understand, are you saying "if you have this list of
      > > > > requirements, use SOA?"
      > > > >
      > > > > -Rob
      > > > >
      > > > >
      > > >
      > >
      >
      >
      >
      >


      Boardwalk for $500? In 2007? Ha!
      Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.

    • Shashank D. Jha
      What does I (Integration) of UDDI represents? regards, Shashank Dutt Jha ... Building a website is a piece of cake. ... Park yourself in front of a world of
      Message 88 of 88 , Aug 13, 2007
        What does I (Integration) of UDDI represents?

        regards,
        Shashank Dutt Jha

        On 8/13/07, Anne Thomas Manes <atmanes@...> wrote:
        >
        >
        >
        >
        >
        >
        > Bear in mind that UDDI is a general-purpose service registry, which you can use to register any type of service (not just web/digital services). Conceptually, you might have a service that doesn't have a binding. A service could represent an abstract concept or a human-driven activity ( e.g., legal services). Or perhaps it just represents a service that has not yet been implemented.
        >
        > Actually -- human-driven services should have at least one binding that represents the means to contact and engage the service -- e.g., via a phone number, email address, website, etc) (the URL scheme for the access point can be phone:, mailto:, fax:, etc.)
        >
        > Anne
        >
        >
        >
        > On 8/12/07, Michael Poulin <m3poulin@...> wrote:
        > >
        > >
        > >
        > >
        > >
        > >
        > > Anne, could you, please, comment on the following:
        > > looking into UDDI, I have notices that 'Business Service entities' MAY contain 'Binding Template entities, each of which represents a service endpoint', it is not a mandatory inclusion.
        > >
        > > This opens an error-prone activities like 1) registering the 'Business Service entities' w/o registering 'Binding Template entities' (including references to the WSDL); 2) uncontrolled removal of the 'Binding Template entities' leaving 'dead' reference in the 'Business Service entities'. The same relates to all other 'Technical Models' including Service Contracts. Am I correct?
        > >
        > > If YES, what means might protect users in such cases?
        > >
        > >
        > > - Michael
        > >
        > > Anne Thomas Manes <atmanes@... > wrote:
        > >
        > >
        > > Indeed. UDDI provides no standard repository capabilities for maintaining WSDL and XSD files. (Note that some UDDI vendors have extended their UDDI-compliant registries to also provide repository capabilities, though.)
        > >
        > > From UDDI's perspective, WSDL and XSD files are various types of "technical models". (In particular, they are specifications.) UDDI is designed to allow you to register any number of technical models that relate to one or more services. And it works on the assumption that there is a many-to-many relationship between services and technical models. e.g., a service has many models that collectively define the "technical fingerprint" of the service, and a particular model may apply to any number of services.
        > >
        > > Services are represented by three data entities which have a hierarchical relationship:
        > >
        > > BusinessEntity entity represents some type of organization that contains a set of
        > > BusinessService entities, each of which represents a service which contains a set of
        > > BindingTemplate entities, each of which represents a service endpoint and points to a set of tModels
        > > that describe the technical fingerprint of the service (all info you need to know about the service)
        > >
        > > Technical Models are represented by the tModel data entity.
        > >
        > > The distinction between contains and points to is important. The UDDI data model is defined via XML Schema. The BindingTemplate is a child of BusinessService, which is a child of BusinessEntity. The tModel is a root element, not a child of any other element.
        > >
        > > You register specifications, such as WSDL and XSD files, as tModels, but you don't store the actual specifications in the registry. Here's an example of a tModel that represents a WSDL defining a service's binding:
        > >
        > >
        > >
        > > <tModel tModelKey="uuid:49662926-f4a5-4ba5-b8d0-32ab388dadda">
        > > <name>Example StockQuote Binding WSDL</name>
        > > <categoryBag>
        > > <keyedReference
        > > tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824"
        > > keyName="binding namespace"
        > > keyValue=" http://example.com/stockquote/"/>
        > > <keyedReference
        > > tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
        > > keyName="WSDL type"
        > > keyValue="binding"/>
        > > <keyedReference
        > > tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e"
        > > keyName="portType reference"
        > > keyValue="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3"/>
        > > <keyedReference
        > > tModelKey="uuid:4dc74177-7806-34d9-aecd-33c57dc3a865"
        > > keyName="SOAP protocol"
        > > keyValue="uuid:aa254698-93de-3870-8df3-a5c075d64a0e"/>
        > > <keyedReference
        > > tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
        > > keyName="uddi-org:types"
        > > keyValue="wsdlSpec"/>
        > > </categoryBag>
        > > <overviewDoc>
        > > <overviewURL> http://location/sample.wsdl</overviewURL>
        > > </overviewDoc>
        > > </tModel>
        > > You'll notice that it does not include the WSDL -- it only provides a pointer to the WSDL (via its URL in the <overviewDoc> element).
        > >
        > > This example comes from the "Using WSDL in a UDDI Registry" technical note [1]. I recommend you read this document if you'd like to learn more about how UDDI works.
        > >
        > > As for policies, WS-PolicyAttachment, Section 6 [2] defines a standard set of tModels for registering WS-Policy files and associating them with a service. UDDI registry and WSM vendors rely on these tModels to share policy and runtime contract information. Here's an example of a tModel representing a WS-Policy file:
        > >
        > > <tModel tModelKey="uuid:04cfa…">
        > > <name>…</name>
        > >
        > > <description xml:lang="EN">
        > > Policy Expression for example's Web services
        > > </description>
        > >
        > >
        > > <overviewDoc>
        > > <description xml:lang="EN">Web Services Policy Expression</description>
        > > <overviewURL>
        > > http://www.example.com/myservice/policy
        > > </overviewURL>
        > > </overviewDoc>
        > > <categoryBag>
        > > <keyedReference
        > > keyName="Reusable policy Expression"
        > > keyValue="policy"
        > >
        > > tModelKey="uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941" />
        > >
        > > <keyedReference
        > > keyName="Policy Expression for example's Web services"
        > > keyValue="
        > > http://www.example.com/myservice/policy "
        > > tModelKey="uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" />
        > > </categoryBag>
        > > </tModel>
        > > As I said before, UDDI works on the assumption that a particular service's BindingTemplate points to a number of tModels that collectively represent all information related to the service, including specifications, documentation, code samples, contracts, policies, etc. This was the original intent behind UDDI -- provide a central index to all information about a service, and provide a means to search for services based on a variety of search criteria -- represented by tModels.
        > >
        > > There is no other standard that provides this type of index capability. Without a standard, it's very challenging to get multi-vendor products to share the information they need to interoperate. Until the industry defines another standard, UDDI provides the best option.
        > >
        > > Bear in mind that humans should not be expected to interact directly with UDDI. Humans should have an intuitive UI and search facility that abstracts and hides the complexity of the UDDI data model. From my perspective, the UI, search, and reporting capabilities are some of the most important features that should be examined when evaluating registry/repository products.
        > >
        > > [1] http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.htm
        > > [2] http://www.w3.org/TR/ws-policy-attach/
        > >
        > > Anne
        > >
        > >
        > > On 8/6/07, Michael Poulin < m3poulin@...> wrote:
        > > >
        > > >
        > > >
        > > >
        > > >
        > > > UDDI does not maintain WSDLs and schemas. Indeed? What does mean service registration in the UDDI (separatly from the service registration, BTW)?
        > > >
        > > > Yes, the tModel can register all policy and contract references. But, is this the righ place for such information or it is a proposal based on the status of UDDI as a standardised registry?
        > > >
        > > > - Michael
        > > >
        > > > Anne Thomas Manes <atmanes@...> wrote:
        > > >
        > > >
        > > > Just to clarify -- a UDDI registry doesn't "store" contracts. Contracts should be stored in an appropriate contract repository. But I recommend that you also register those contracts in UDDI. Think of UDDI as an index to all information related to a service. It's not a repository -- it doesn't maintain artifacts such as WSDLs, schemas, policies, contracts, etc. But it does maintain links to all these artifacts (which are likely to be stored in a number of different repositories).
        > > >
        > > > Anne
        > > >
        > > >
        > > > On 8/3/07, Michael Poulin < m3poulin@...> wrote:
        > > > >
        > > > >
        > > > >
        > > > >
        > > > >
        > > > >
        > > > > I agree - a use of Repository at run-time needs a standard protocol, probably, similar to the use of UDDI.
        > > > >
        > > > > While a registry like UDDI can store the service contracts, I think it should not do it based on the separation of concerns principle.
        > > > >
        > > > > I do not see a problem in registering the service contract with a management system because it is a shared entity already. Unfortunately, it is not doable today (yet). In any case, how a management system access service contracts today (for the purposes of "enforcing runtime aspects of the contract") ?
        > > > >
        > > > > - Michael
        > > > >
        > > > >
        > > > > Anne Thomas Manes < atmanes@...> wrote:
        > > > >
        > > > >
        > > > > On 8/1/07, Michael Poulin < m3poulin@...> wrote:
        > > > > >
        > > > > > What would be your opinion on this:
        > > > > > Service Contract Repository stores Service Contracts (with or w/o controlled
        > > > > > access); each Contract contains a URI of the record in the Service Registry
        > > > > > where the Consumer can find the Service Interface and related physical
        > > > > > end-point(s).
        > > > > >
        > > > > > Thus, a Service Contract Repository may be used in the run-time by the
        > > > > > Consumers to find/refresh location of the service registration (Repository
        > > > > > becomes the 'firster' citizen than Registry).
        > > > > >
        > > > > > - Michael
        > > > >
        > > > > But then how does a management system (responsible for enforcing
        > > > > runtime aspects of the contract) locate the service contract? This
        > > > > model would work only if the industry defined a standard for a service
        > > > > contract repository. (This is my primary beef with IBM regarding WSRR.
        > > > > IBM stores runtime contract information for ESB, Message Broker,
        > > > > Process Server, and DataPower in WSRR -- but no other management
        > > > > systems have access to this information because there is no standard
        > > > > protocol or information model for this repository.)
        > > > >
        > > > > A more standardized approach would be that a contract is registered in
        > > > > the registry, and the contract registration specifies the URL of the
        > > > > contract (which is likely to be stored in a contract repository). (See
        > > > > the continuing debate on REST for enlightenment on the remarkable
        > > > > benefits of exposing a resource via a URL and HTTP.)
        > > > >
        > > > > Anne
        > > > > >
        > > > > >
        > > > > > Anne Thomas Manes < atmanes@...> wrote:
        > > > > >
        > > > > >
        > > > > > Mike,
        > > > > >
        > > > > > Thanks very much for this excellent explanation of contract management.
        > > > > >
        > > > > > A number of products provide some level of support for contract management, including HP/Systinet, Software AG/Infravio, SOA Software Workshop, Amberpoint, and Layer 7. Note that most of these products concentrate on managing the runtime aspects of a contract ( i.e., runtime policies) rather than the full comprehensive agreement between consumer and provider (which may also include support agreements, remuneration agreements, SLA violation compensation agreements, incident management agreements, etc).
        > > > > >
        > > > > > I haven't analyzed all the products in great detail. Of the ones I have looked at, HP/Systinet seems to have the most comprehensive contract management support. It provides a workflow driven system that manages the process by which a potential consumer can request access to service and negotiate a contract with a service provider, and the open content model in the repository allows organizations to define and capture all the different types of agreements that might go into a contract. (It is the only solution I've seen that doesn't focus only on the runtime aspects.)
        > > > > >
        > > > > > As for privacy concerns, I think all the repositories now provide object-level access control, so it should be pretty easy to ensure that only authorized people are permitted access to the contract information.
        > > > > >
        > > > > > Anne
        > > > > >
        > > > > >
        > > > > > On 8/1/07, Mike Glendinning <mikeg@...> wrote:
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > > --- In service-orientated-architecture@yahoogroups.com , "Shashank D.
        > > > > > > Jha" <shashank.dj@...> wrote:
        > > > > > > >
        > > > > > > > Things are getting little blurred now, with the introduction of
        > > > > > > > "contract" between Service Provider and Consumer.
        > > > > > > >
        > > > > > > > The service description contains information needed to use a service.
        > > > > > > > Service description contains contract information.
        > > > > > > >
        > > > > > >
        > > > > > > There is a common misconception that a "contract" is merely part of the
        > > > > > > description of a service. People talk about "design by contract" and
        > > > > > > about things like WSDL "defining a contract" which tends to reinforce
        > > > > > > the idea that a contract is just an attribute of the service itself.
        > > > > > >
        > > > > > > In fact, a contract defines and is defined by an agreement between two
        > > > > > > [or more] parties. The contract specifies the responsibilities of the
        > > > > > > parties and the rules under which the parties will interact.
        > > > > > >
        > > > > > > So, in the SOA model, a new contract is created each time a "service
        > > > > > > consumer" engages with a "service provider". These contracts can and
        > > > > > > probably will be different for each service consumer. That is, the
        > > > > > > agreement is negotiated through a process of offer, counter-offer and
        > > > > > > ultimately acceptance.
        > > > > > >
        > > > > > > In this way, the exact and minimum set of dependencies between service
        > > > > > > provider and service consumer can be recorded. This helps
        > > > > > > promote "loose coupling" and assists greatly with the management of
        > > > > > > change by minimising the overall "surface area" of the dependencies.
        > > > > > >
        > > > > > > For example, if a service consumer only wishes to make use of a single
        > > > > > > operation offered by a service provider, then this should be specified
        > > > > > > in the contract. That particular service consumer is therefore not
        > > > > > > dependent on any changes made by the service provider that do not
        > > > > > > affect that particular operation.
        > > > > > >
        > > > > > > I believe that managing dependencies between service consumers and
        > > > > > > service providers is one of the major challenges in SOA. If I put my
        > > > > > > consultant hat on, I might give this the grand title of "change time
        > > > > > > governance" :-) Managing contracts as first-class entities in the SOA
        > > > > > > is the way to do this.
        > > > > > >
        > > > > > > For obvious reasons, it is critical to try and minimise dependencies
        > > > > > > between services in as many ways as possible. Recognising the true
        > > > > > > nature of contracts as I describe above is a necessary first step in
        > > > > > > this process.
        > > > > > >
        > > > > > > I haven't checked for a while, but the last time I looked the available
        > > > > > > SOA infrastructure products were very weak in their support for
        > > > > > > managing contracts and dependencies in this way. I would be very
        > > > > > > interested in an up-to-date status report that tells me otherwise.
        > > > > > >
        > > > > > > Now a separate question is how and where these contracts should be
        > > > > > > managed by the SOA infrastructure. Here, I'm not at all convinced that
        > > > > > > a centralised registry or repository is the right way to go. Surely
        > > > > > > contracts are private matters to be managed by the service providers
        > > > > > > and service consumers themselves, thus enforcing the notion of "privity
        > > > > > > of contract". All that is needed is the ability to ask a service
        > > > > > > consumer "which services do you make use of?" and a service
        > > > > > > provider "who makes use of your service?"
        > > > > > >
        > > > > > > Regards,
        > > > > > >
        > > > > > > -Mike Glendinning.
        > > > > > >
        > > > > > >
        > > > > >
        > > > > >
        > > > > >
        > > > > >
        > > > > >
        > > > > > ________________________________
        > > > > Building a website is a piece of cake.
        > > > > > Yahoo! Small Business gives you all the tools to get online.
        > > > > >
        > > > > >
        > > > > >
        > > > > >
        > > > >
        > > > >
        > > > > ________________________________
        Building a website is a piece of cake.
        > > > > Yahoo! Small Business gives you all the tools to get online.
        > > > >
        > > > >
        > > > >
        > > >
        > > >
        > > >
        > > >
        > > > ________________________________
        Park yourself in front of a world of choices in alternative vehicles.
        > > > Visit the Yahoo! Auto Green Center.
        > > >
        > > >
        > >
        > >
        > >
        > >
        > >
        > > ________________________________
        Choose the right car based on your needs. Check out Yahoo! Autos
        new Car Finder tool.
        > >
        > >
        > >
        > >
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.