[
Lists Home |
Date Index |
Thread Index
]
WSRP allows for load balancing through several
mechanisms. Caching, Cookies (though discouraged)
and navigational state maintenance where the url
is pushed out to the browser for bookmarking and
refresh. Load balancing isn't addressed directly
in the spec, because that was considered too fine
grained for effective management of a WSRP 1.0
environment, if I remember correctly. So far we
haven't been getting a lot of feedback about it
from those who are implementing the spec, but its
hard to say if we have a large enough set of
installations yet to begin to get a good idea of
how important this is likely to become. However,
the notion of adding a specific set of operations
to account for load balancing directly in the
WSDL seems worth exploring.
Ciao,
Rex
At 9:43 AM -0400 8/31/04, Chiusano Joseph wrote:
>Seetharama Rao Durbha wrote:
>>
>> I thought so - but then was not quite sure if a solution akin to the web
>> load balancing/fail-over is a better one, or giving individual control to
>> the customers is a better one.
>
>Not sure what you're driving at here - load-balancing should be provided
>if required, wherever it is required - that is, whether one is a service
>provider or service consumer - or both - should not make a difference.
>It's all about whether or not it is required given the load.
>
>> The advantage with current way (of providing
>> load-balancing / fail-over at the network service provider or perimeter) is
>> that it is already in place, at least for those people with high content and
>> visits. However, I am sure that Orgs with high-content web requests are not
>> the ones who need to provide highly reliable web services (at least not
>> 1-1), so others would need different solutions.
>
>Web Services reliability is actually a different, but somtimes related,
>topic that involves quality of service (QoS) requirements such as
>guaranteed delivery and guaranteed message ordering (see the work that
>we have been doing in OASIS WS-Reliability). An example of these being
>related is where a receiving system does not have adequate load
>balancing capabilities, and a response to a sent message (using
>reliability features) is not received by the sender within a predefined
>window - which will cause either a resend or a termination of attempts
>to resend that message, depending on the number of attempts vs. some
>predefined parameter on the sender side.
>
>> And, probably, making the
>> choices part of the WSDL,
>
>If you mean the choice of using load balancing or not, then this could
>be incorporated into a WSDL document in the manner described below
>(multiple soap:address values). Of course, simply having multiple
>addresses does not mean that load balancing is done - it just sets up
>the foundation for it.
>
>> or a dynamic retrieval of those choices from a
>> UDDI repository (basically a standards-based way) would be a good idea.
>
>Yes, one can use UDDI to dynamically retrieve a WSDL document of course.
>So if this means retreiving a WSDL document that contains multiple
>soap:address values, then that is on target.
>
>> I will take a look at WSRP.
>
>I don't believe that WSRP incorporates the notion of load balancing into
>their spec (at least the last I read), because it's more of an
>implementation issue. Rex will correct me if I am wrong.
>
>Kind Regards,
>Joe Chiusano
>Booz Allen Hamilton
>Strategy and Technology Consultants to the World
>
>> Thanks,
>> Seetharama
>>
>> -----Original Message-----
>> From: Rex Brooks [mailto:rexb@starbourne.com]
>> Sent: Monday, August 30, 2004 7:17 AM
>> To: Chiusano Joseph; Seetharama Rao Durbha
>> Cc: xml-dev@lists.xml.org
>> Subject: Re: [xml-dev] Fault-tolerance in web services
>>
>> Indeed, not naive at all. Load balancing and
>> scalability issues are here already in WSRP, and
>> will need to be taken into account by IT
>> architects as they begin to fashion portal-based
> > IT solutions end to end of an enterprise.
>> Although heterogeneous environments can be
>> accommodated, the tier of largest companies will
>> almost certainly need to rethink IT strategies in
>> terms of investing in the most efficient and
>> scalable systems. That is going to be more
>> efficient with systems designed to scale from day
>> one AND work with more heterogeneous partners.
>> Not easy. Not simple.
>>
>> Ciao,
>> Rex
>>
>> At 3:51 PM -0400 8/30/04, Chiusano Joseph wrote:
>> >That doesn't seem at all like a naïve question, especially since your
>> >additional information is right on the mark. The situation you imagine
>> >is - I am certain - often done in practice, by offering a service at
>> >multiple addresses.
>> >
>> >Kind Regards,
>> >Joe Chiusano
>> >Booz Allen Hamilton
>> >Strategy and Technology Consultants to the World
>> >
>> >Seetharama Rao Durbha wrote:
>> >>
>> >> Just a naïve question - fault tolerance in web services - for example,
>> >> providing multiple service/soap:address - should that be part of a
>> WSDL/SOAP
>> >> client functionality, or should that be a native support provided by the
>> >> provider?
>> >>
>> >> I can imagine situation where services are multi-hosted and a particular
>> >> provider would like to be able to explicitly identify those locations to
>> the
>> >> clients, in case one fails, or even for load-balancing, if that is a
>> >> concern.
>> >>
>> >> Thanks,
>> >> Seetharama Rao Durbha
>> >> Cell : 510-673-1843
>> >> Office : 510-742-4228
>> >>
>> >> -----------------------------------------------------------------
>> >> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>> >> initiative of OASIS <http://www.oasis-open.org>
>> >>
>> >> The list archives are at http://lists.xml.org/archives/xml-dev/
>> >>
>> >> To subscribe or unsubscribe from this list use the subscription
>> >> manager: <http://www.oasis-open.org/mlmanage/index.php>
>> >
>> >--
>> >Kind Regards,
>> >Joseph Chiusano
>> >Associate
>> >Booz Allen Hamilton
>> >
>> >-----------------------------------------------------------------
>> >The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>> >initiative of OASIS <http://www.oasis-open.org>
>> >
>> >The list archives are at http://lists.xml.org/archives/xml-dev/
>> >
>> >To subscribe or unsubscribe from this list use the subscription
>> >manager: <http://www.oasis-open.org/mlmanage/index.php>
>>
>> --
>> Rex Brooks
>> GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
>> W3Address: http://www.starbourne.com
>> Email: rexb@starbourne.com
>> Tel: 510-849-2309
>> Fax: By Request
>>
>> -----------------------------------------------------------------
>> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>> initiative of OASIS <http://www.oasis-open.org>
>>
>> The list archives are at http://lists.xml.org/archives/xml-dev/
>>
>> To subscribe or unsubscribe from this list use the subscription
>> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>--
>Kind Regards,
>Joseph Chiusano
>Associate
>Booz Allen Hamilton
--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request
|
