By writing this post I’m taking a huge risk of being rejected by both .NET and Java communities. This is an attempt to explain what WCF, which stands for Windows Communication Foundation, is in Java terms.
WCF-to-Java mapping is not really trivial. I’m lacking understanding to what extend WFC consumer should be aware about the type of communication with the service: request/response or asynchronous messaging. I have difficulties imagining this is completely transparent for the consumer… unless WCF framework “removes” asynchronousity of messaging and takes care of waiting for a response message(s). If the latest happens, then there is actually no asynchronous messaging!
As usual with Java (and I was truly missing it working with .NET), there are Specifications of technologies and there are various Implementations of these specifications. Although normally the applications are being tested with and therefore claim to support explicit Implementations of used Specifications, in theory the final selection of those is done during deployment or just before the application starts.
Whenever we talk about a service, we have the actual service and its consumers.
Let’s start with consumers. For sending asynchronous messages they’d better be written against JMS – Specification for Java Messaging System. Consumers of JMS just need to know logical name of the target queue or topic. For request/response communication consumers should be written against a plain Interface of service. This Interface is agnostic to the technologies used on the service side and in the transportation layer. To obtain an explicit implementation of the Interface at run-time the consumer uses an externally configurable Factory. This factory will use something like JAX-WS for Web Services, JAX-RS for RESTful services, RMI for remote EJBs (Enterprise Java Beans) or plain object (POJO) for in-process services.
Are you still here? Then let’s move to the service side. If the service consumes messages, it can be implemented using JMS directly or as Message-Driven Bean (flavor of EJB). The last option provides you with all that transactivity and scalability from Application Server (something like IIS). If the service should provide responses (including failures), the golden rule is to let them implement a plain Interface – the one, which will be used by the service consumer. Then either by adding annotations to the Interface Implementation code or by using external configuration in Application Server your implementation becomes accessible as Web Service or Session EJB. Actually nowadays most of the Servers are capable of exposing Session EJBs as Web Services. If you use Proxy pattern, you also have a clean, unspoiled implementation of the Interface, which can be used by in-process consumers.
This is a very lengthy explanation. A shorter translation of “All cross-layer entities are WCF services” would be:
“All entities are defined by their Interfaces and written against Interfaces of other entities. Implementations of the entities are Plain Old Java Objects (POJOs), possibly wrapped by EJB Proxies“
| Reference: | Attempt to map WCF to Java terms from our JCG partner Viktor Sadovnikov at the jv-ration blog. |
