Re: More efficient web service choice
Re: More efficient web service choice
- Subject: Re: More efficient web service choice
- From: Lachlan Deck <email@hidden>
- Date: Fri, 20 Jun 2008 10:52:32 +1000
On 20/06/2008, at 2:19 AM, Guido Neitzer wrote:
On 19.06.2008, at 01:21, David den Boer wrote:
Same with us. A properly architected API solves all of these
problems and then some. You have to architect it using only
standard java data types -- dont use EOF/NS or collections -- you
screw yourself when working with non-java clients.
That is a really good advice and seems to mostly work - it just
wasn't that nice, when you tried using DirectToWebServices.
What I like best about SOAP -- its dead simple to develop for when
you use WO, and rock-solid.
Not my experience but as I"m not really into WebServices - YMMV.
If you're developing rock-solid enterprise class API's to be used
by clients across a wide spectrum of tools/operating systems, I
think you can do no wrong using SOAP. If you like PHP or RoR, go
the other way :-)
Hmmm. That's a pretty tough statement. Again: SOAP is anything but
simple and there are MANY MANY things that can go wrong - especially
with WebObjects where a lot of the important stuff like the WSDL is
created for you and you don't have to understand the things when
doing the simple example - and then it blows up when you try
something real ... I'm pretty sure I still have 5 year old bugs open
related to that ... but again, I might be wrong, I stopped using
SOAP because it never worked out for me. It always worked in my WO
to WO cases but customers had often problems getting their .Net apps
connect and we solved ALL these problems with a REST interface.
But that might just be a matter of taste (and requirements of
course). I like to keep it simple and SOAP is not a simple protocol
anymore ...
Like David (den Boer) was suggesting, I've got soap beans that do not
have any EOF/WO properties in them. The services provided also only
provide WOless interfaces. I simply register these like so (called
from app constructor):
/**
* Initialises the WebServices that we provide.
*/
private void initaliseWebServices()
{
NSArray nameSpaces =
ERXProperties.arrayForKeyWithDefault( "SOAPBeanFactories",
NSArray.EmptyArray );
for ( Enumeration en = nameSpaces.objectEnumerator();
en.hasMoreElements(); )
{
String aNameSpace = en.nextElement().toString().trim();
try
{
Class aClass = Class.forName( aNameSpace );
NSMutableArray reverseBits = new NSMutableArray();
Enumeration rn = NSArray.componentsSeparatedByString( aNameSpace,
"." ).reverseObjectEnumerator();
NSArray n = new NSArray( Collections.list( rn ) );
String urn = reverseBits.subarrayWithRange( new NSRange( 1,
reverseBits.count() - 1 ) ).componentsJoinedByString( "." );
LOG.info( "urn:" + urn + " ClassName:" +
reverseBits.objectAtIndex( 0 ).toString() );
QName aQName = new QName( "urn:" + urn,
reverseBits.objectAtIndex( 0 ).toString() );
BeanSerializerFactory serializer = new
BeanSerializerFactory( aClass, aQName );
BeanDeserializerFactory deserializer = new
BeanDeserializerFactory( aClass, aQName );
WOWebServiceRegistrar.registerFactoriesForClassWithQName( serializer,
deserializer, aClass, aQName );
}
catch ( Exception e )
{
LOG.error( "Failed to register soap bean for " + aNameSpace, e );
}
}
nameSpaces = ERXProperties.arrayForKeyWithDefault( "SOAPServices",
NSArray.EmptyArray );
for ( Enumeration en = nameSpaces.objectEnumerator();
en.hasMoreElements(); )
{
String aNameSpace = en.nextElement().toString().trim();
try
{
Class aClass = Class.forName( aNameSpace );
String name =
aClass.getName().substring( aClass.getName().lastIndexOf( "." ) + 1 );
LOG.info( "register webservice:"; + name + " Class:" +
aClass.getName() );
WOWebServiceRegistrar.registerWebService( name, aClass, true );
}
catch ( Exception e )
{
LOG.error( "Failed to register web service " + aNameSpace, e );
}
}
}
Then there's some glue code (in the services' relevant controllers) to
create/update/delete the relevant EOs initiate/restore sessions etc.
Granted the client apps are Java-based and not ObjC Cocoa apps, so for
these YMMV, but it's not too difficult. But choice is good :-)
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden