project methodologies icon
continuous integration icon
continuous integration icon
development practices icon
project implementation continuous delivery continuous integration development practices
JV-ration logo http://jv-ration.com/2014/04/attempt-to-map-wcf-to-java-terms/
info@jv-ration.com

Attempt to map WCF to Java terms

April 9, 2014 | By Viktor Sadovnikov | 1 Comment

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.

Service ButtonWCF-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

  1. Alisa
    October 23rd, 2014 @ 11:52 am

    Take your time as you begin to figure out what niche is right for you.

    for those able to guide them through their learning. And this will
    be the simple and easiest way to make money online.

    My blog: profit maximiser scam

Leave a Reply




5 − three =