SOCKET

Sumer is acumen in..

..and so is the next release of SOCKET. The Java commission has been completed and the amended Rose SOCKET factory now handles infinitely nested datatypes as well as attachments. Thanks to Atif Suleman who carried out the coding. The task was made significantly easier by using some classes from the Spring codebase. I suspect that this might have saved us a couple of weeks during the original project. Shoot the architect!

The new code is now in HEAD in our SourceForge CVS repository. After some prettying up of the XSLT and CSS style sheets I think that we will be ready to take SOCKET out of beta. (Just when the fashion turns to "permanent beta" we emerge from this state. Had to do it.)

Once the stylesheets are fit for looking at (the garish orange is a bit much, I'm told) I think we'll put up a couple of animated screen captures on what SOCKET can do now.

Even as the capabilities of IDEs such as NetBeans and Eclipse make the creation of Java clients for Web services the matter of literally a couple of button clicks, SOCKET has still got its nose in front with a paste-and-click generation of a Web app client for a Web service. As someone that is constantly sniffing around and testing Web services, SOCKET must have saved me hundreds of hours in the last year or so.

Posted at 06:04PM May 06, 2008 by Brian Peter Clark in General  | 

The SOCKET Roadmap

Some new development work on SOCKET has just commenced to modify the Rose factory so that it will be able to deal with nested complex datatypes in the WSDL. It will also be able to handle file attachments. These additions will greatly increase the range of services that SOCKET will be able to process. The work is scheduled to be completed mid-September.

Completion of this work will signal the start of more development. Firstly, Java Management Extensions (JMX) instrumentation will be added to the SOCKET client in order to provide a monitoring and configuration interface. Service performance metrics will be available to a management application.

Also, users will be able to customise operation and parameter names in the stylesheets, again through a management application.

Having the JMX agent incorporated into the SOCKET client is an important addition in that it will eventually help integration into a SOLA and will also enable configuration of Shibboleth/Guanxi protection of the application.

The final item on the medium distance SOCKET roadmap is to replace the homegrown XSLT handling by the excellent Cocoon framework. This should lead a lot more functionality and flexibility in the view layer.

Posted at 12:46PM Aug 12, 2007 by Brian Peter Clark in General  | 

SOCKET Case Studies

A new Case Studies page has been added to the SOCKET web site.

The first case study describes how it took no time at all for SOCKET and NetBeans to knock up a Protein Sequence Repository service that facilitates group work in a bioinformatics activity.

Job's a...

Posted at 10:00PM Dec 11, 2006 by Brian Peter Clark in General  | 

1 Registry Good, 2 Registries Better

Even though the subject matter is registries, this blog is filed under general rather than UDDI. It looks further afield than UDDI and a step beyond SOCKET to what might come after. To the team, SOCKET has always been regarded as an exploratory first step in the progression to a full-blooded Service-Oriented Virtual Learning Environment (SOVLE).
I cast my mind back to The Godfather when Tom Hagen was replaced as the consigliere to Don Corleone. Tom Hagen was a great peace time consigliere, but no good for war time. UDDI is a fine peace time Web services registry, but will not do for the bloody struggle that is runtime. A dynamic SOVLE in which services and components are being constantly deployed, undeployed, configured, reconfigured and monitored is too much of a war zone for UDDI. There is too much fine-grained and dynamic grape-shot flying around to be serviced by SOAP messages shuttling back and forth to the gentle jUDDI. So who is the Michael Corleone of the registry world? Who can save the SOVLE from runtime confusion and defeat? Jimmy X is his name, MBeanServer is his game. The MBeanServer is a runtime Java registry for Managed Beans, or MBeans. Each MBean is associated with a managed resource. In the SOVLE this will be a Web application or a Web service. These MBeans can carry out the full range of management functions: deployment, installation, control and monitoring. The pairing of an MBean with a SOVLE resource creates the basis of a comprehensive plugin architecture. Every resource, including access control and group management, plugs into the MBeanServer registry through its associated MBean.
Although jUDDI has been retired, she still has important words of advice to give to Jimmy X. Which services are dependent on which others? What might a good bootup strategy be? Which services and components are fit to join Jimmy X?
On their own, Jimmy and jUDDI don't have the power to support a SOVLE.. together they can take on the world.

Posted at 07:39PM Aug 22, 2006 by Brian Peter Clark in General  | 

Saturn and Pluto

Atif has just finished off two clients for the SOCKET engine, a command line tool, codenamed "Pluto", and a Web application, named "Saturn". A screenshot of Saturn is given below.

Credit: The Hubble Heritage Team (AURA/STScI/NASA).

One inputs the absolute URL of the WSDL document and, on submission of the form, a download link is returned for the service consumer war file.

A screen shot of Pluto in action is given below:

The sprint to the line is now on with the major remaining tasks, the most important being the handling of complex types. The grunt work has been done for this: essentially the job is to unravel a JavaBean to simple types where the existing SOCKET code can take over.

Posted at 05:47PM Aug 14, 2006 by Brian Peter Clark in General  | 

SOCKET Demo

There is a socketized Bods demo at:

http://socket.leeds.ac.uk/bodington/site/

Interested parties are welcome to use the guest account:

username: guest
pw: guest1

The SOCKET links lead to the QMShibb sub-project and the main
sub-project. The QMShibb page has shibbed links to a
QuestionMark Perception test, a list of tests and the admin app (to
which 'guest' will not have access).

We have put up 2 SOCKET web services and a 'SOCKET web
application'. (The create SOCKET service tool will not be visible to a
guest user.)

The web service producers are on an external server, while the
consumer apps are in socket.leeds.ac.uk along with the bodington
instance.

Chemical Elements

This is one of our test services. The stylesheets are development
versions - we are making no claims that these are fit for teaching
purposes.

Jabber

We have plugged in a Jabber applet which is served out from a remote server in a jsp. (The Jabber server uses an
embedded Hypersonic. Wouldn't want any conflict with
QuickBods.)

I simply chose what looked like the simplest Jabber applet around:
e4Applet 1.1.1

You can sign on with Jabber account:

username: guest01
password: socket01

You can join the following room:

socket@conference.webforwireless.co.uk

No pw required.

SSRun

Although we will sign off with the ability to handle complex data
types, the present socket engine handles simple datatypes only -
strings, ints, floats, doubles, booleans, dates. (Client-side js
validation comes as standard.) However, we have set up the
JISC/Icodeon ASSIS/SSRun web service and passed the wsdl
through the engine. The test data has not been loaded into the
Web service and there are complex data types so the service is
not functional, but this gives a basic impression of what the final
turnkey product will do. As with Chemical Elements, there has
been absolutely no tinkering with the Java, only some stylesheet
tweaks (I added a fetching orange/yellow gradient fill to SSRun, for
example). Two extremely valuable operations are working, though: ping and
createRunId, proving that the service is live.

We will be putting up a SOCKET development release soon, with
perhaps a couple more over the next few weeks leading up to 1.0:
simple types; arrays; complex types included.

For further information: email me, sign into Jabber Bods and I'll be
clayton ( or Brian: b.p.clark at leeds dot ac dot uk )

Posted at 03:04PM Aug 10, 2006 by Brian Peter Clark in General  | 

SOCKET.net?

A recent article on the Microsoft site:

Calling an Arbitrary Web Service

Scott Golightly, Microsoft Regional Director
Keane, Inc.

April 2006

Posted at 02:46PM May 15, 2006 by Brian Peter Clark in General  |  Comments[14]

11 May 2006

The French and British sides of the Channel Tunnel met on 22 May 1991.

The SOCKET service consumer software and the viewfactory filter met on 11 May 2006.

A data transformation was observed and a small breakthrough ceremony took place.

Posted at 07:28PM May 11, 2006 by Brian Peter Clark in General  | 

The Bad Easy

On first meeting Web services and WSDLs, the concepts of rpc-style and document-style services are confusing. The problem stems from the fact that there are two completely different considerations that are described using the same terminology, the implementation of the Web service itself and the structure of the soap content in the WSDL document.

The important facet is the programming model that the consumer and producer use to process their soap messages, not the style of the WSDL. This is where the real distinction between rpc-style and document-style services lies. Since the fundamental aim of SOCKET is to create consumer software for Web services from a WSDL it is essential that we know all the variations that services can throw at us so that we can proceed as far as possible in the process of setting up the consumer side of the service. For very simple services, SOCKET will be able to provide a one-step turnkey process for creating a client. For more complex rpc services and document-style services, SOCKET will probably provide a handler interface wrapped around the XML message which can then be implemented for a complete construction of the functionality of the service.

If we are using the Axis (JAX-RPC) programs Java2WSDL and WSDL2Java, or their equivalents in our language of choice, then we're probably doing rpc. And, bad news, rpc is bad. It's bad for interoperability. If Java shall speak only unto Java, and C# shall speak only to C# and Python shall speak only to Python, then we'd be OK, but then what'd be the point of Web services? It's when Java tries to talk to RosieLea, or when Python wrestles with Anaconda, that the rpc difficulties emerge, essentially through the minefield of mismatched datatypes, and also in the so-called XML-OO impedance mismatch.

So what is the document style? In a document-style Web service, you simply send the soap message to the producer and say, Look, we've talked about this, and we bashed out our schema, take the message and do what you want with it. The producer does this and sends a soap document back. There you are, consumer, we talked about this and we bashed out our schema, take the reply and do what you want with it. Using this style, I suspect that SAAJ 1.2 soap elements, which implement DOM, feeding into an XSLT/XPath engine will be the most important protocol, rather than using some tool-generated language-specific API. This will become clearer in the near future. So how is this better than rpc? Well, hopefully the problem spots have been identified and can be catered for. One field might be a date. The producers can say - look, this field is a date, but - hey - we might feed it in as a null value (nillable = true in the schema) - so watch out for this. In the rpc service, the null date might feed straight into an api that hasn't got null date types - it might go in as a zero...with hilarious consequences (I take this particular example from a Ted Neward interview on The Server Side).

So rpc is bad, and document is good. Document is also good from a related angle - message-oriented middleware and the Humptyhump Humpty Bus. I might say more about this at a later date - I usually do.

The bad news is that for simple services rpc is easier - all tool based, and taken directly from the WSDL operations and messages. With a bit of luck, for simple rpc-style services you are saved the problems that necessarily exist if an XML document has to be developed to implement complex service functionality. Having said this, even simple rpc-style services will have semantic problems, albeit of a different kind, in the absence of good annotations or documentation. Please input gas pressure. Surely - in Pascals, bars, torrs, atmospheres, psi...? Missions to Mars have perished on such semantic asteroids, and so will many a badly-drawn Web service.

So, there are rpc-style and document-style Web services. Either style can be employed using rpc-style or document-style WSDL documents. The WSDL styles are normally referred to as rpc-literal and doc(ument)-literal. So, if we can have an RPC-style Web Service (RWS) and a Document-style Web Service (DWS), there are 4 immediate possibilities: rpc-literal and doc-literal RWS; and rpc-literal and doc-literal DWS (I suppose we ought to give document-wrapped literal a namecheck, too, which makes it easier for tools to handle RWS with doc-style WSDLs).

SOCKET has started orff with the bad easy stuff, a natural place to start: rpc-literal RWS.

Posted at 10:16AM Apr 12, 2006 by Brian Peter Clark in General  | 

8080 restored

mea culpa stop silly ass stop permalink problem fixed stop utf-8 not configured properly stop arriving istanbul wed stop

Posted at 12:53PM Apr 11, 2006 by Brian Peter Clark in General  | 

Broken Links - RSS Feed Exporter Omits Port Number

212 characters for message stop cetis elrond links to individual blog items broken stop rss exporter omits port 8080 in permalinks stop access to blog via web site stop those puzzling at style ? the first 212 characters are visible in the aggregator stopp

Posted at 04:29PM Apr 08, 2006 by Brian Peter Clark in General  | 

SOCKET

This is the technical blog for SOCKET, a JISC ELF toolkit project.

The aim of the project is to assemble a toolkit that, given a WSDL file, will automatically generate consumer software for a Web service together with an interface that makes it available as a resource in a virtual learning environment.

Project Web site: http://www.www.agbooth.com/SOCKETSite/

Project dates: 1 February 2006 - 31 July 2006.

Members of the project team belong to the e-Learning Development Group in the Faculty of Biological Sciences at the University of Leeds.

Professor Andrew G. Booth, Project Director

Dr Brian P. Clark, Project Manager

Atif Suleman, Principal Developer

Rob J. Garbutt, Developer

We are pleased to have the following consultants for the project.

Alistair Young (Guanxi Consultant) from the UHI Millennium Institute at Sabhal Mòr Ostaig, Isle of Skye. Alistair wrote the alternative implementation of the Shibboleth profile used in the Guanxi Identity Provider and Service Provider.

John Kleeman (Questionmark Consultant) is the Chairman of Questionmark Computing Limited, the vendors of Questionmark Perception.

Posted at 02:55PM Apr 06, 2006 by Brian Peter Clark in General  |