We Keep Coding

SOA Architecture understanding

I have been asked to work on a project, based on SOA, using WCF. I have dabbled with WCF (Creating and consuming), but never with SOA. Am I right in saying that a single service would have the usual service layer, business layer and data access layer (if one's needed). The service layer would then expose methods.
Can Service A reference Service B, and service B reference service A?
And then a UI can access these services, via references - and that's essentially SOA? I am battling to find up to date, recent tutorials (Youtube), and the 'guides' I see online seem extremely complicated.

This Wikipedia entry is pretty clear I think?
Lets try a simple example. Say we have Library application that lets you check books in and out.
If you look at the "traditional" non-SOA way to approach n-tier systems then you have a service called MyService that has methods called something like CheckOutBook. This would go away and internally have a Book class and a Person class and would perform say Book.IsAvailable = False and Person.NumberOfBooks.
That is fine, but say you now have another application that wants to work with People. You can't just use the above service because the logic is tightly coupled with what you are doing, i.e. Library transactions. Instead you would have to copy / paste code into a new service "BookShop".
With SOA you would have a Book service and a Person service. The Person service would have an action such as Person.AssociateWithBook that both Library and BookShop could use without having to alter as it is simple enough to do the minimum. It is then down to the application to call the right service(s) to do the job required. This means that it is reusable without needing to modify the various services.
This is very simplistic but hopefully shows the architectural differences and get you going?

I'd skip question about SOA, since each one can call SOA whatever he understand SOA (Service Oriented Architecture) is. I mean, each architecture, using services, can be called SOA...
From technical aspect, I'd build it in next way:
IMO, Services by themselves should have as less logic as they can (like facade pattern), all there logic should be moved down to Business logic.
Service A using ServiceA.BusinessLogic, calls service B (proxy for service B is available for ServiceA.BL).
Same for Service B, calling service A.
This will give you bi-directional communication, without issues of Duplex (broken callbacks, ...).
UI should access the services as well - using UI.BusinessLogic ( I usually prefer think about service communication as sort of Communication Data Access Layer).

Prevent WCF exposing my whole class?

I've just begun learning WCF, and I'm coming from a total non-web background.
I have built a 3-tier desktop application, which compiles into one exe, which runs locally.
Now I want to move the whole business logics layer to a centric server, and make the GUI a client application.
As far as I understand, WCF should be my solution, as indeed, it helped me achieved what I wanted.
I mange to run remote functions, which is the basic of what I need.
My problem now, is that I don't quite understand the architecture.
For example, one of my services, returns a data type (class), from my Business Logics layer.
This class automatically becomes available to the client through the WCF mechanism.
But the problem is, this class contains some methods, which i definitely do not want to expose to the client.
For example a Save method (saves to the db).
Further more, sometimes I don't even want to allow the client to change all the properties of the class, since this class might be sent to one of my services.
I do not want to re-validate the class instance in the service.
What should I do? Should I build another layer, restricted version of the Business Logics, which I expose to the client? Or is there any way expose only part of my class to the client, without restricting the server it self?
I know this is a basic question, but honestly i've searched a lot before asking here. My problem is I don't quite know what to search.
My second question is then, do you have any recommendation for any resource that can explain me this architecture...?

Typically, if you want to encapsulate your business layer, you would not want to expose the business objects directly. This is because you now have a de-coupled client and you don't necessarily want to have to update the client every time the business logic/properties change.
This is where Data Transfer Objects (DTO) come into play nicely. Usually, you want to have control over your contract (data and methods) that you expose. Therefore, you would explicitly make other objects (DTOs) that make up the transfer layer. Then, you can safely change your client and server code independently (as long as both still fulfill the contract objects).
This usually requires a little more mapping (before you send or receive on each side) but it is often worth it.
For WCF, your interfaces and classes marked with [ServiceContract] and your classes marked with [DataContract] usually make up this transfer layer.

In WCF to expose method to client you have to mark it with OperationContractAttribute. So if you don't want clients to use your Save method, just don't mark them with with this attribute.
More info here: http://msdn.microsoft.com/en-us/library/system.servicemodel.servicecontractattribute.aspx
Pretty much same thing with properties, but different attribute: DataMemberAttribute. If you don't wont client to see it, just don't mark them with it (DataMember attribute)

But the problem is, this class contains some methods, which i definitely do not want to expose to the client.
Are you able to provide an example of your class and interface code? If so I'm sure you might be able to get more specific answers.
For example a Save method (saves to the db).
One possible approach would be to separate your class into 2 classes. Define the properties in the first class and then use that class as the base class of your second class. Then use the second class to define the methods. This would allow you to return only the properties while allowing you to keep your code DRY.
Further more, sometimes I don't even want to allow the client to change all the properties of the class, since this class might be sent to one of my services.
I do not want to re-validate the class instance in the service.
While you are able to define logic in the get and set methods for each property I would highly recommend revalidating any input received between services simply because any future changes or errors in one service could potentially lead to larger problems across your application. In addition this also helps to ensure your application is more secure against any potential attacks.
Should I build another layer, restricted version of the Business Logics, which I expose to the client? Or is there any way expose only part of my class to the client, without restricting the server it self?
I agree with the above answers that you should be able to limit access to the different properties and methods using the data and method attributes within your interfaces.
My second question is then, do you have any recommendation for any resource that can explain me this architecture...?
If you are looking for inexpensive but highly valuable video based training I've found the courses that Pluralsight offers to be quite good for both architecture as well as WFC services (btw, I am not associated with them, just enjoyed their training).

Web Service wrapper

I am writing a dll that is referencing to some WCF service.
The dll is functioning as a Gateway of the service and all calls are going through it.
Probably there can be concurrent calls .
I have referenced the service but now I cannot decide how to write the wrapper functions correctly.
Is there some example or best practice for this functionality.

I would make wrapper that matches the web service interface. It would also be a good idea to wrap up all of the objects exposed. Basically create a proxy. What I find really useful for this type of thing is to create an interface that matches the API and implement that. That way, you can create a dummy version of the DLL for testing without the overhead (or potential costs) associated with the WCF call. It would also make it much simpler if you need to replace the WCF call with an alternate provider in the future.
As an example, lets assume that we have an WCF service to an external provider for processing a payment. Something like this:
void ProcessPayment(float amount);
We could easily hook this into our code. The problem is that a simple change to the interface would result in us having to make changes everywhere the code is referenced. The same would be necessary if we changed providers to someone else, even if the interface was almost identical. Adding something like a simple interface:
interface IPaymentProvider
{
void ProcessPayment(float amount);
}
Would completely decouple our code from the WCF service. We could easily build a class like this:
class PaymentProviderAWrapper : IPaymentProvider
{
void ProcessPayment()
{
// Call the WCF service
}
}
That we could load dynamically with a factory or dependency injection framework like Spring.NET. Changing to a provider B would be as simple as creating a new wrapper:
class PaymentProviderBWrapper : IPaymentProvider
{
void ProcessPayment()
{
// Call provider B's Native DLL
}
}
Switching your code from provider A to B would be as simple as changing a configuration setting.
Even if we compiled the library directly into our code, all we would need to do is change the construction logic to use the new library. The rest of our application would not change at all. Just a simple recompile.

In response to Graymatter's answer I don't see what the difference is between calling a service wrapper which exposes the same calls and then forwards the calls to the real service, and just calling the service, assuming a one-to-one mapping on individual calls and no change in transport binding.
The only reason you would want to create a wrapper in the first place is that the interface exposed in some way does not meet your requirement on it's own. There are several reasons you may want to do this but a few common ones:
Protocol translation - the service is not exposed across the correct transport binding for your needs
Service Composition - the interface operations are too granular and don't represent business-level operations.
Authentication - perhaps you require an authentication layer on top of the endpoint you are consuming.
So how to wrap the service endpoint depends on why you want to wrap the service...

Business Logic Classes Naming

I have a business layer that has some business objects/POCOs/entities/whatever. I also have some repositories for the data access. Up until this point, I've been accessing the repositories directly from my UI layer. I'm at a point where I actually need some more classes that aren't straight CRUD, so I'm going to create some business logic classes that will do the logic, and CRUD, and the repositories won't be accessed by the UI anymore (which should probably have been done from the start).
What should I call these classes? The only thing I can think of are service classes, but I have actual WCF services in this application, so that will make it confusing. The WCF services will also be using these classes, so having a service use a service class seems odd and confusing.

I use the "Service" naming convention as well. It's true the "service" has become a very overloaded term in the industry, but it makes the most sense. Developers reviewing the code should be able to determine the difference between a Application/Domain Service vs a WCF service, and while having a WCF service call other service classes may seem confusing, I think you'll find that it isn't. The idea of a service is that it is code that performs a function, and is available for use by other code. It might be an internal service, or it might be a service externally exposed via http or whatever. But the idea of what the code does is the same.

If your 'services' are orchestrating business logic using a number of domain objects, you're likely implementing the Facade Pattern - so perhaps you can name them with this suffix, eg OrderManagementFacade

From your description, it sounds like the WCF classes are actually implementing a service host. I typically name such classes with a "ServiceHost" suffix. It separates them nicely from the actual service classes.
So, for example, you would have your business logic in a class named "CustomerService" and the corresponding WCF class would be named "CustomerServiceHost".

WCF Service - Coding Standard - Where to put my class library?

I'm trying to implement a WCF Service in my program , howevery I don't understand something:
According to the book "Programming WCF Services" , Juval Löwy 2007 O'Reilly Media,.
Appendix C. - WCF Coding Standard C2 - Essential :
1. Place service code in a class library and not in any hosting EXE.
I don't understand this, where should I put my code? all my class are defined in my form application , How should I call my classes of the winforms from the Class Library of the service.
Am I missing here something??
Thanks,
Eyal

I like to structure my WCF solutions like this:
YourProject.Contracts (class library)
Contains all the service, operations, fault, and data contracts. Can be shared between server and client in a pure .NET-to-.NET scenario
YourProject.Service (class library)
Contains the code to implement the services, and any support/helper methods needed to achieve this. Nothing else.
YourProject.ServiceHost (optional - can be Winforms, Console App, NT Service)
Contains service host(s) for debugging/testing, or possibly also for production.
This basically gives me the server-side of things.
On the client side:
YourClient.ClientProxies (class library)
I like to package my client proxies into a separate class library, so that they can be reused by multiple actual client apps. This can be done using svcutil or "Add Service Reference" and manually tweaking the resulting horrible app.config's, or by doing manual implementation of client proxies (when sharing the contracts assembly) using ClientBase<T> or ChannelFactory<T> constructs.
1-n actual clients (any type of app)
Will typically only reference the client proxies assembly, or maybe the contracts assembly, too, if it's being shared. This can be ASP.NET, WPF, Winforms, console app, other services - you name it.
That way; I have a nice and clean layout, I use it consistently over and over again, and I really think this has made my code cleaner and easier to maintain.
This was inspired by Miguel Castro's Extreme WCF screen cast on DotNet Rocks TV with Carl Franklin - highly recommended screen cast !

Yes, it's a bit confusing.
We're talking about the service implementation here. What Loewy means here is that the code to implement the service should be in a separate project. The code that hosts the WCF service (i.e. the class that implements your service contract) should do nothing but call that service implementation code.
So your Windows Forms client application uses a proxy, which in turn calls the WCF service application hosting layer, which in turn calls your service logic.
It's a very good idea to go further and have three layers on the UI side and four on the service side. The namespaces might be
Company.Project.UI.WinForms
Company.Project.UI
Company.Project.ServiceClient
Company.Project.ServiceHost
Company.Project.Service
Company.Project.BusinessLogic
Company.Project.Persistence
For simpler projects this would be overkill, but for anything more than (say) one form or two service methods it will make life much easier. Not least, testing each layer in isolation should be fairly straightforward.

Here's a typical project structure following Löwy's recommendation:
MyProject.Data
MyProject.Logic
MyProject.Services
MyProject.ServiceHosts
MyProject.Presentation
Then MyProject.ServiceHosts will reference MyProject.Services and exposes the services defined there. So in Löwy's language, MyProject.Services is the class library, and MyProject.ServiceHosts contains the hosting executable.