Background

As part of an ongoing project where a light weight client application needs to communicate with a database via a webservice I have been trying to get my head around a the best way to encapsulate data within custom objects and pass it from the client 's GUI to the Web Service's Data Access layer without replicating too much code or having the the client hold a reference to the same assembly as the webservice.

The intention is for the client application to have 3 layers, the presentation layer, a Business Entity / Business Logic layer and an Webservice Adapter layer. The Webservice will have the WebService layer, it's own Business Entity / Business Logic layer and a Data Access layer.

Initial Thoughts

My initial thoughts were to create an assembly which would hold a set of interfaces that will describe the business entities that both parts of the application would use. For example the interface fot the job object would be:

public interface IJob
{
    int Id;
    string CreatedBy;
    DateTime CreatedOn;
    .
    .
    DateTime LastAccessed;
}

This would require that both pairs of business entity assemblies would need to have a reference to the assembly. My plan was then to return from the webservice's webmethods the interface rather than the object. For example.

[WebMethod]
public IJob GetJobById(int id)
{
.
.
}

My plan was then bind the form controls to the properties of the interface but among a couple of minor flaws in my plan, there was one big one... It appears that you can not return an interface from a web service. I assume do to it not being serialisable. A little research later it appears that a better way would be to would be to use a shared base class for the business entities on both sides of the void, so to speak. So back to the drawing board slightly..

Second Thoughts

So now I'm thinking I need to create an abstract base class for the objects in the business entitiy assemblies in both the client and the webservice to inherit from. If I ensure the base classes implement the interfaces, then I can still bind my controls to the interfaces properties. So ignoring the various properties of the class I now have a bas class that implements the previosu

protected abstract class BaseJob : IJob
{
.
.
}

So now the Job class in each business entity layer will inherit from the BaseJob abstract class which implements the IJob interface.

public class Job : BaseJob
{
.
.
}

So this means that now rather than just having a reference to the assembly with the interfaces in for each business entity assembly I now have a reference to the base class assembly too. Is this really the way I want to go?

To be continued...

Well it has been a steep learning curve of languages and syntax of the last two years since I started at NewLook. I came in with only HTML and what I thought was a reasonable knowledge of VB script in the form of classic ASP. Since then it's been Web and Windows programming in VB.Net and last year a move to C#. So what next?

Well, our team are aware that there is a plan in the company to have a new team of Java developers employed in the not too distant future. So I guess at some point it will be prudent to get a bit of back ground knowledge of this Java stuff.

Now I get a bit scared when thinking about learning another new programming language, incase it dilutes what little knowledge I have of my other languages. But I guess in reality, apart from forgetting not to put a semi-colon here and a curly brace there for the first 10 minutes of reworking an old project in another language, there is probably no disadvantage other than the time to learn the new syntax or new IDE to write it in. Infact from reading other developers blogs it appears it can help to improve your programming prowess in your original languages by exposing you to different architectures and ways of going about tackling problems.

What better way to give it a go than a need arising from an actual project! Seeing as we use a few Oracle products it seemed logical to find the JDeveloper set up file on the network and install and use that. I always find it disconcerting the way that you just unzip the files and flop them in a folder and create a shortcut to your start menu, if you feel like it. There is something to be said for MSI installer packages; if they complete without failure, you at least you have some confidence that the app will run! But run it did, and apart from having to point a setting to the folder that contained what I assume was the compiler, it was all good.

To be continued...

As part of the preliminary research and design process for a prospective new project at work one of the requirements will be for the application to provide a webservice that can be consumed from a third party's Java application.

So without further ado a quick .Net webservice was nocked up in C# with a single WebMethod. The WebMethod would return a formatted string containing within it the value passed in as a string parameter. The Webservice was deployed to localhost and tested using the simple webform test that is present on a local instal.

All good so far.

Next is to build a small Java web project that can consume the webservice. So having never written a Java application before, it's a quick trip to see Mr Google for a working example of how to call a webservice from Java. ( See My First Java App ) Google thankfully turned up David Hobbs' example "How to consume an ASP.NET webservice from Java via SOAP" on CodeProject. After a an hour or after nocking up a quick Java webpage with an embedded applet that will call the webservice and display the result, it should be a case of running it and seeing it work like clockwork.... After all the whole idea of a webservice is to platform unspecific, isn't it?....

Well, I shouldn't really have expected miracles, should I? After a whole afternoon of checking and double checking that the code was correct and using a free trial of ExamDiff Pro to ensure that XML that the java code was out putting was exactly what the XML that the server was expecting to receive I came to the conclusion that it must be something perculiar to our network. The XML output was identical except for the physical value of the parameter.

So at the end of the day I was at a loss. I'm not sure if it is an error in the code, or if the webservice expects different XML than what the description page offers up. Or if there is a network security issue which isn't allowing communication between the two applications. One of my .Net Windows applications calls a .Net webservice which is built in the same way as this test one perfectly, and has done for the last year! Event the third party representative was at a bit of a loss.

So I am at a bit of a loss with this one. May be a fresh look in a new week will shed some light. Who knows? If any one else has come accross this issue, and resolved or not resolved it, please post and let me know your findings!

Postscript: #1
I have just noticed on the botttom of David's CodeProject artical the following:

Notes
Some Java Virtual Machines (like the Microsoft one) only allow you to make a socket connection to the same machine that hosts the Java class files. Therefore, if you're using an applet like me, you will need to host the Java class files on the same machine where the webservice resides.

I wonder if this has anything to do with the problem... Oh well, maybe tomorrow I'll waste another fruitless afternoon trying to find out!!

Postscript: #2
Well after further investigation I haven't managed to determin the fault, but today we tried a different approach and used the "Web Service proxy" object from the Business Tier > Web Services category in the New Gallery.

We then followed the wizard and let it generate the code. The outputted code was tested and hey presto!!

So I guess this topic is closed for me now!

Hi and welcome to my blog...

Although I am employed as an application developer and have developed / co-developed a number of Windows and Web applications for my employer, NewLook Retailers, I wouldn't concider myself as any more than a meer beginner in the big picture of things! One of the biggest driving forces for me as a programmer is that fact that I know there is still a hell-of-a-lot that I still don't know!

This blog will not attempt to show best practices, or ingenious ways to overcome obscure problems; it will be nothing more than a log of my personal development as a programmer and no doubt an expression of some of my frustrations as I come across problems while writing applications and libraries for both NewLook and myself. It may not be factually correct all (or any) of the time but it may end up of use to anyone else who experience any of the issues that I post about.

Please feel free to offer advice and / or criticism regarding anything I post on this site.

Best regards,
Duane.

p.s. There is a real risk of me not completing posts on this blog. I can only apologise now, and hope it doesn't happen too often!!!