by Jim White (Intertech Director of Training and Instructor)
I attended fellow instructor Andrew Troelsen?s Complete Windows Communication Foundation (WCF) class last week (recently updated for .NET 4.0). Andrew is a gifted teacher with a deep deep knowledge of .NET. If you want to learn anything about .NET, you really need to take a class from Andrew. Regardless of the topic, you are going to learn more in a day with Andrew than you will reading an entire library of books on your own. For those not aware, WCF is Microsoft?s relatively new service oriented framework. In Java, this would be equivalent to your JAX-WS and JAX-RS more on that in a bit APIs.
If you had to put me in one of the software-centricities today, I guess you would say I am a ?Java developer.? I have been doing Java for over 14 years. However, I have recently ?crossed to the dark side? (as some of my Java friends would say) as I am participating in and leading Intertech?s Cloud Computing efforts ? most notably with Windows Azure (Microsoft?s cloud platform). WCF is at the heart of a lot of Azure capabilities and APIs. I took Andrew?s class to get better insight into this Azure foundational element.
However, as a Java developer, I was also curious to see how the other world treated SOA and Web services. When writing interoperable Web services or consumer applications, I am always very curious how non-Java applications might work with my Java service or Java consumer. After all, SOA and Web services are all about interoperability. This week?s class gave me a much better appreciation for that, at least from the current Microsoft stack. Below, I have provided a kind of compare and contrast look at how Java and .NET provide developers with tools and APIs for wresting with services. For those that spend a lot of time in SOA worlds, I hope you find the discussion encouraging. The point of this post is not to highlight the differences, but to really spotlight the fact that the two have to address many of the same issues and are therefore more alike than you might think. In other words, there is more that binds us (pun intended) than separates us.
First, some of the differences I saw. Note, ?differences? doesn?t not mean better or worse ? just different.
Support for Multiple Bindings
Java has an API for everything. Unfortunately, that means for each job, you need a different API. The JAX-WS API provides a great environment for writing interoperable SOAP-based Web Services and Web Service Clients. What if you need to communicate Java-to-Java using a different (more Java centric) protocol? Well, then it?s probably another distributed technology API (like RMI or EJB) that you probably want to explore ? at least if you want the performance and Java objects passed around. Want to do REST in Java? You need JAX-RS. In the .NET world, its WCF - period. In fact, what I was impressed with is that WCF has taken over as the communications framework in the Microsoft camps. Gone (not deprecated, but certainly relegated to legacy support) are .NET Remoting, ASP.NET web services, and other such APIs. Everything is now WCF. .NET to .NET, or .NET to Java using SOAP, it?s all the same. WCF offers multiple bindings. Bindings dictate the protocols, encoding mechanisms, and the transport layer used between consumers and service providers. What?s more, when you write a WCF service, the code doesn?t know or care what binding you choose. The binding is taken care of through configuration and hosting operations. In class, we wrote simple services in our lab that ran SOAP over HTTP in one minute and in TCP or named-pipe, .NET-centric fashion the next minute. Java wonks will argue you can do multiple bindings with Java APIs too. Yes you can, just like I can cut my yard with scissors ? doesn?t mean I want to or that it?s a good idea either.
WCF Host vs. the App Server
In Java, you typically create your service as a simple Java object (POJO or plain old Java object as it is know) and hand it off (with some configuration) to a Java application server/container to do the rest of the work. While Java services (like those produced in JAX-WS) can run in multiple environments, by and large, they are really engineered to be simply packaged and deployed into a managed Java runtime container (a Java application server). Nicely, the container manages the lifecycle of the service, routes traffic to and from the service, and generally handles all the details of the service as it is deployed and running. In the WCF, once you have created the service (which is also just a simple object), your work may only be half done. Now, you need to pick and possibly build its host environment. You can choose something like IIS to host the service (your job is now simpler) or you may choose to have a custom Windows service, or console application, Windows Server (through Windows Activation Service) host your service objects. Some choices will require you to write the code that essentially manages your service at runtime. Other options just need some configuration. Choices are good. Allowing for you to pick how and what manages the life of your service. However, choices can also lead to some complexity. I can see that making the wrong choice (or coding the host inappropriately) could lead to some issues (like poor service performance).
To be fair and honest, as those in the Java community know, running in an application container is not always a picnic - i.e. seamless or easy. Your Java Web services don't always deploy simply or easily in containers as it often requires special libraries and/or configuration. In fact, there is even a JSR (JSR-109) that attempts to address the deployment issue interoperable Web services.
Development Approaches (top-down, bottom up)
As Java?s main Web service stack (JAX-WS) is all about interoperable SOAP-based Web services, it should come as no surprise that the IDEs, tools, and API support both top-down (a.k.a. WSDL or contract first) and bottom-up (a.k.a. code first) approaches to building Web services. I?ll leave the pros/cons of both approaches to material you can find on the Internet. However, both are supported with neither relegated to an ?alternate approach? status. While you can do top-down service development in WCF, you need to use a command prompt tool (SvcUtil) to generate code from the WSDL and related schema documents. This seemed a bit kludgey to me. I am sure the tool works fine and once you are used to working with it, you can make it do all sorts of neat tricks. However, when I have a WSDL URL, I?d like to point my IDE to the WSDL and say ? go generate skeleton code for my new service. I didn?t see anything like that in WCF, which leads me to feel that the top-down approach is relegated to second class status in .NET. However, remember again that WCF deals with multi-bindings and the service code itself doesn?t know or care that it is doing SOAP or .NET binary. Top-down development is about using a contract to drive development of consumers and services. In an all .NET world, a top-down contract approach probably isn?t going to be an option (no WSDL to leverage there).
REST
Formal REST support is something added to WCF with the latest release (.NET 4.0). Frankly, it kind of looks like it was added recently. For example, a number of configuration simplifications were made for "normal" services in .NET 4.0. However, RESTful Web services must use the older form of configuration. Further, the WCF templates in Visual Studio 2010 may still require a few reference updates and configuration changes when creating a RESTful service project. These are minor issues, and I think we can all presume that things will be better and different in a future release of WCF. However, WCF is the framework for any type of "communications" - REST or otherwise. So again, when building a service using WCF, you can create a simple class that performs some sort of offering and you can make it available as a Web service, .NET named-pipe, or RESTful Web service all with the same framework. Java's RESTful API (JAX-RS which is relatively young itself) is a separate API (and implementation) from its other service types (notably JAX-WS). While it might be possible to have a class implement both JAX-WS and JAX-RS simultaneously, you are really talking about two different frameworks and two APIs for Java Web vs. RESTful services.
Security
WCF leverages Microsoft's Role Based Security system for most in-house (.NET to .NET) types of services. This makes security slick and easy for service providers and consumers. The API for determining who is the caller and what access they have is built into the API as well as a declarative model that makes securing services pretty easy. For externally facing services, authentication and authorization are, like Java, a bit more manual (generating, handling and passing credentials and/or certificates in the message), and takes a bit more work on the part of the service provider/consumer to setup. However, WCF applications can leverage the SQL Membership Provider API. The SQL Membership Provider API, for non-.NET developers, is an auto-generated custom database (at runtime) for registering users and granting access.
Proxy API
In both Java and WCF, proxy classes are generated for the consumer developer. The proxy makes communicating with the service easy and abstracts away the details of the protocol being used or even the fact that it is distributed computing going on. Working with a WCF proxy is so simple, as they say in the commercials, even a caveman can do it.
BasicMathClient proxy = new BasicMathClient();
Console.WriteLine("1 + 1 = {0}", proxy.Add(1, 1));
proxy.Close();
In Java, there are actually two types of proxies. Using the dynamic proxy client (a generated proxy), is very similar to using the WCF proxy. I think JAX-WS client proxy coding is a bit more complex, but also offers the ability (in theory) to use different ports on the service (e.g. SOAP vs. RMI).
BasicMathService service = new BasicMathService();
BasicMath port - service.getBasicMathSOAPPort();
System.out.println("1 + 1 = " + port.Add(1,1));
Java also offers the Dispatch Client. This client requires more work (a lot more work), but allows the developer to have more direct control of the raw message (typically SOAP).
More That's The Same Than Different
As mentioned, there is really more that is similar between Java and .NET's Web service frameworks than is different.
Services as Simple Classes
Both rely on objects that come from simple classes dictated by interfaces for implementing services. Plain old Java, C#, or VB objects are running the SOA world! In fact, I even found it interesting that both environments encourage but do not require the use of an interface for defining the service. Of course, services can contain complex logic and complex calls to other classes to get business done, but the service structure itself is simple and easy to understand.
Annotations or Attributes
Both rely on metadata (Annotations in Java and Attributes in .NET) to demarcate the service, its operations, and much of its runtime behavior. Its fun to see that there is almost a one-to-one correspondence in the metadata tags in both worlds. If you were a Java developers, I dare say you could pick up a C# Web service and translate it into Java code with only a little assistance. And of course the opposite holds true for .NET developers.
//C# attributes
[ServiceContract]
public class ServiceTypeAsContract
{
[OperationContract]
public void SomeMethod() { /* Some interesting code. */ }
[OperationContract(IsOneWay = true)]
public void AnotherMethod() { /* Some interesting code. */ }
}
//Java annotations
@WebService
public class ServiceTypeAsContract
{
@WebMethod
public void SomeMethod() { /* Some interesting code. */ }
@WebMethod
@OneWay
public void AnotherMethod() { /* Some interesting code. */ }
}
Serialization/Deserialization
The frameworks are largely responsible for the creation of the request and response messages and marshalling/unmarshalling data to the applications. The days of manipulating raw XML, JSON, or other formatted requests and responses are over in any language. Let the framework do the grunge work of distributed communications and data formatting.
WS-* and WS-I adherence
Both Java (JAX-WS) and WCF are now fully WS-I compliant. This is good news for everyone. While you can certainly use annotations/attributes or configuration to construct non-interoperable services, it requires work (and presumably acknowledgement on your part) to implement only for a certain platform. There are still many gotchas in Web service interoperability, but developers now have a fighting chance of making things work with other platforms without having to know every detail about the other platforms.
Exceptions as faults
Both WCF and the Java frameworks translate language exceptions into faults. Both provide a similar means of creating application specific faults that can contain more details about what went wrong to the client.
Filters vs. Channel
Both the Java frameworks and WCF provide for pre and post processes to operate on in bound and out bound messages at both the consumer and service provider levels. They have different names, but provide similar capability to alter the message on the way to and from its destination and even to alter message flow under the right circumstances (say authentication failure). In Java, these processes are called handlers. In .NET/WCF they are called channels, but they serve the same general purpose.
I am sure a more experienced practitioner in both the Java and .NET SOA worlds can provide you with more detailed and better comparisons than I have here. Hopefully, you get the idea that the software community is more united in its approach to SOA than divided - at least when it needs to be. Sure, you can write applications in Java or C# that just need to communicate with their ilk and then things often get simpler. But the design, patterns and approach to building services, no matter the platform, is starting to get more similar and that's good news for everyone.
Sign up today for Complete WCF or Complete Java Web Services to learn more about SOA in any environment.
5a031afd-c552-49f5-8f4e-a72413627035|6|4.5