The closest we get is we have a WCF service host that maintains a block
of logins for all of our .net apps that use UniObjects and handles
running the subs through the service reference.

-----Original Message-----
From: Brian Leach <>
To: 'U2 Users List' <>
Sent: Thu, Oct 4, 2012 4:05 am
Subject: Re: [U2] Consuming Web Services

Getting back to the original question:

In most, but not all cases, I use:

UniVerse => (socket) => .NET Service -> Web Service

Where the .net service is not necessarily on the same machine as
UniVerse (security/firewalling restrictions). Using UniVerse sockets to
drive services is something I do in a lot of my applications (mvPDF,
etc.) and works well.

I also have routines for calling web services directly over UniVerse
sockets, but you don't get the advantages of WSDL import and XML/JSON
serialization built into .Net. The CallHTTP stuff is a pretty rubbish
set of functions over the top of the socket API and XDOM is horrible so
it's easier and more flexible to do your own if you're going that way :)

As for the other stuff: we all love the u2 model (or we wouldn't be
here) but that shouldn't blind us to the fact that there are areas where
the implementation could be improved: indexing is one of those. Using
cache better is probably another, but restricted by the fact that this
is a multi-process model: caching would be much easier for single
process, multithreaded servers that don't have to load shared memory
segments to make data visible to all participants. In a replication
scenario, for example, being able to replicate directly to a
subscribers' cache could have advantages if you don't need the
subscriber to guarantee that it has committed to disk in good time
(unless it suddenly becomes a publisher/fail-over when it has to sync
the cache)..


U2-Users mailing list

U2-Users mailing list
U2-Users mailing list

Reply via email to