We Keep Coding

Windows service design with WCF

Currently I'm working on a design for a Windows Service application to fetch reports from an Oracle database, aggregate them to a message and send it to an external WCF SOAP service.
I would be grateful for some design suggestions concerning Windows services.
Should Windows Services use e.g. dedicated WAS/self-hosted WCF service (net.pipe/net.tcp) that provides data to achieve better separation / reusability?
So I would add a WCF service (net.pipe) that provides data (e.g. a GetReport method).
The Windows Service application would call GetReport and call the remote SOAP service to forward the aggregated message. The remote service and its client code are likely to change. It might be adapted for different customer projects.

If I understand correctly, your windows service will periodically fetch some data from the database and upload that data to a remote web service.
This means that your windows service is a client in terms of WCF communication and you won't need to implement any WCF server code inside it.
All you'll have to do is to connect to the remove web service and upload the data, e.g. using a client proxy generated for this remove service.

I don't think that it is required to add another WCF service that provides the data instead of querying the database directly as long as you don't have the requirement that another application will use the same WCF service. Until then I wouldn't add the service for the following reasons:
Another WCF service increases the complexity of the deployment and makes it harder to install and configure.
The connection to the new WCF service is another point that can break.
If you handle lots of data, getting them from the database directly is much more efficient instead of transferring them over a service protocol. As I understand your question, you aggregate the data in the windows service not in the database. Therefore you'd have to move the aggregation code to the new service also.
As said before, this recommendation will change once you have another potential client to the new service. In order to prepare for that, you should of course choose a design in your windows service that separates concerns well and is a good starting point to move some components later.

can't find main static main method in WCF

I created WCF service and faced with a problem. I need to update database periodically, but i couldn't find static method like Main, that whould do it without client interaction. What can i do??? What wold you suggest in such case?

There is no Main method (or similar entry point) in WCF. You need to host your WCF service in another process (such as a Windows service, or IIS or self host) to "activate" it and make it available to other processes.
One of the concepts in WCF is that you write your service code to do the function you need without having to worry about infrastructure and hosting. Once you have written your service logic, you can then decorate and configure your service to expose it to other processes. Using this approach means you can change how your service is exposed to other processes without re-writing the actual service logic - you essentially just change your configuration. Hence, a main entry point is specific to how you choose to host and expose your WCF service to the outside world.
Just Google around for "WCF hosting" and you will find lots of information.
If you don't need to expose your service logic to an external process (which sounds like maybe the case from your question) then maybe you don't need to use WCF and you can just write a plain old Windows Service.

If your wcf service is self hosted then you can do it in your application before publishing the service.
If it is in IIS then there really isn't application_start kind of thing since the host may be created on first request. See WCF application start event

How to access client application from web application with service application

I would like to write a Web Application that can interact with 3D Cad program for our company. So I was thinking that I would create a program that would be locally installed on the client machines which would send and receive data back and forth from Client App to Web App. I would like to use xml for moving the data back and forth too. Does anyone suggestions or can this even be done?

In this case you need 2 way communication between app and service. and for solving that there are two way:
use two service and they must be client of each other (Hard way)
use Duplex Services. (you can use WCF-Duplex services - it's not simple)
in this case you must handle too many issue's.(take look at this)
As example:
app need to notify self on your service and service save address of active client's. so every time service want's to call one of client, service must find client's address in active-client's and then call that.
Let me know if this help you.

Creating web service and client with shared types

I have created two wsdl files with shared types imported from xsd schema file.
After that I have created web services using interface generated by wsdl.exe tool with parameter /serverInterface.
Frist web service, have web method “RegisterData” with put into queue some complex object to be processed, by system “A”. As result of this method is returned Boolean (with tell us that object was registered successful).
Second web service, have web method “UpdateData” to update some data in system “B” based on this same object , with was changed in process on system “A”.
So in system “A” I have to create client for second web service, where I will call method “UpdateData” with this modified complex object us argument.
But when I’m creating this client in Visual Studio (by add web reference or add service reference) I have to create some namespace for client. And then when I’m trying to call “UpdateData” agument have different namespace for this same object received from first web service “RegisterData” method.
I would like to create first web service and second web service client , where I can use this same type object between them.
Thank you very much for help.

I don't believe this is possible with ASMX web services.
WCF does support this, however.
WCF Links:
WCF Developer Center
Beginner's Guide to Windows Communication Foundation
How to: Configure a Service to Reuse Existing Types
Actually, I think I may have misread your question. I though you were trying to share the same types between the client and the server. ASMX cannot do that. However, it appears you are trying to share the same types between two client proxies. You can do that easily using the WSDL.EXE tool.
Consider a schema, DataTypes.xsd, and two WSDL files that import it, ServiceA.wsdl and ServiceB.wsdl. To create the server interfaces, use:
wsdl /serverInterface /n:SharedTypes.Servers /out:Services.cs ServiceA.wsdl ServiceB.wsdl DataTypes.xsd
This will create interfaces which you can implement in order to create your services. These interfaces will both use one set of classes created from DataTypes.xsd. To create the proxy classes, simply use:
wsdl /n:SharedTypes.Proxies /out:Proxies.cs ServiceA.wsdl ServiceB.wsdl DataTypes.xsd
Notice that you do not need the /sharedTypes switch. That has a different purpose. It is for combining types of external services when you need to download the WSDL and any XSD from the service.
I have tried this using an example like yours, ServiceA posting a message into a queue, and a client picking up that message and sending it to ServiceB. It works quite well.

I agree that it is not possible to do this via the VS Web Reference functionality. To meet your requirements you can use the wsdl.exe utility with the /sharetypes switch.
For more information see Web Services Description Language Tool (Wsdl.exe)

OO Design for communication methodology that will change

I am on a project where I will be creating a Web service that will act as a "facade" to several stand alone systems (via APIs) and databases. The web service will be the sole method that a separate web application will use to communicate with these external resources.
I know for a fact that the communication methodology of one of the APIs that the web service must communicate with will change at some undetermined point in the future.
I expect the web service itself to abstract the details of the change in communication methodology between the Web application and the external API. My main concern is how to design the internals of the web service. What are some prescribed ways of using OO design to create an appropriate level of abstraction such that the change in communication method can be handled cleanly? Is there a recommended design pattern?

As you described, it sounds like you are already using the facade pattern here. The web service is in fact the facade to the other services. If an API between the web service and one of the external resources changes, the key is to not let this affect the API of the web service itself. Users of the web services should not need to know the internals of how the web service communicates with the external resources.
If the web service has methods doX and doY for example, none of the callers of doX and doY should care what is going on under the hood. So as long as you maintain the API between the clients of the web service and the web service, you should be set.

I've frequently faced a similar problem, where I would have a new facade (typically a Java class), and then some new "middleware" that would eventually communicate to services located somewhere else.
I would have to support multiple mediums of communication, including in-process, and via the net (often with encryption).
My usual solution is define a notion of a data packet, with its subtypes containing specific forms of data (e.g., specific responses, specific requests), etc. The important thing is that all the packets must be Serializable in some form (Java has a notion for this, I'm not sure about C++).
I then have an agent and a provider. The agent takes program-domain requests, creates packats. It moves them to a stub-skeleton that is responsible only for communicating. The remote stub takes the packet and gives it to a provider. The provider translates it back to a domain object which it then provides to the actual services. It takes the response, sends it back to the agent via the skeleton-stub, etc.
The advantage of this approach is that I create several layers of abstraction. The agent/provider are focused on domain level and its translation into packets and back. The skeleton-stub pair is responsible for marhsalling and sending packets back and forth. By swapping my skeleton-stub pair with subtypes, I can have the same program communicate in different ways (e.g., embedded in the same JVM, via something like JMS, directly via sockets, etc.)

This shouldn't affect the service you create at all (from the user's perspective). Services are about contracts - your service will provide a contract with its users - they send you a specific request and you send back a specific response. You also have a contract with this other API. If they change how they want to communicate, you can handle that internally, but as long as your contract with your users does not change they wont notice a thing.
One way to accomplish this is to not simply pass through the exact object that you get from the "real" API. You can create your own object that you send back in response. You then translate their object into your object. That way if the "real" API changes things on their end you can choose how to send that back on your end.
As the middle man you should be set up so that your end users need to know nothing about the originating API.