On 21 Feb, 09:16, mill... uk.ibm.com wrote:
> There is a W3C recommendation for 'XML Fragment
Interchange', on the
> way to handle large documents. We are sometimes faced
with a similar
> problem with WSDLs. The on the remote 'server' side SCA
does not need
> all of the WSDL to fulfill a request, but just a
fragment, and context
> that relates to the request being made. This might be
in the SOAP
> message, ( see earlier 'getTypeMap' discussion ), but
the overall
> namespace context may be missing.
>
> On 19 Feb, 11:34, mill...uk.ibm.com wrote:
>
> > My thoughts ( such as they are at this stage )
revolve around the
> > gathering of all data from information contained
in a wsdl, when SCA
> > only uses a small portion of that data to satisfy
a specific
> > procedural call when SCA is being used in a
client/server situation.
> > While on the client side this is necessary to
instantiate the client
> > environment ( no calls have been issued yet ). On
the reception of a
> > Soap call on the server side, we instantiate the
server environment
> > using all the data in a wsdl, when we only require
enough information
> > to carry out the call/response.
> > I think ( I need to confirm this ) that the SOAP
message contains
> > enough contextural information, types, parameters
etc, along with the
> > target method and response for us to extract a
'mini-wsdl'(???) or use
> > it directly to form the 'call' to the function.
> > Benefits might be an improved response time as
when SCA is deployed
> > into a scenario that uses very large wsdls the
server side need not
> > process a complete set of data, just enough to
carry out the request.
>
> > On 16 Feb, 15:22, simonsl...googlemail.com wrote:
>
> > > On 16 Feb, 13:08, mill...uk.ibm.com wrote:
>
> > > > Taking the previous 'getTypeMap()
proposal a step further, The xmaldas
> > > > is created from a wsdl. SCA is targeted
against a single method at the
> > > > server end in any one instance.
> > > > Do we need to think about fragmenting
the WSDL into small pieces.
> > > > ( Again this has a better effect with
the large commercial WSDLs we
> > > > are currently building against ) . Those
pieces are held within the
> > > > context of the original so the type
information ( etc ) is not lost
> > > > reducing the overhead of creating and
using large data objects.
> > > > The resulting amount of processing of
the information should be
> > > > reduced and more specific that SCA is
currently doing.
>
> > > I'm not sure what you are suggesting here
Chris in terms of
> > > fragmenting the WSDL. I understand that for a
given call we are only
> > > interested in a small part of a potentially
large XML documents. Can
> > > you explain a little more about how you are
proposing to achieve
> > > this?
>
> > > Simon- Hide quoted text -
>
> > - Show quoted text -
Hi Chris
These all sound like interesting ideas. I believe that
processing only
the information that is actually required is an approach
that can be
applied equally to both the client and the server
environment. I would
say that generally we need to get some stats out of the
runtime to
determine where best to spend our optimization effort.
Experience says
that the things we guess are causing problems sometimes
aren't. I tend
to agree with you that loading large WSDLs is problematic
for us at
present but there is an SDO overhead here that we need to
assess.
Anything you can do to help us pin down where the time is
spent is
greatly appreciated.
Regards
Simon
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "phpsoa" group.
To post to this group, send email to phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---
|
