We Keep Coding

Java and .NET application interoperability

I am having a Java application and a .NET application both residing in two different machines and need to design a communication layer between these two applications. Any inputs or ideas would be really helpful. Below mentioned is the nature of interaction between these two applications.
Java applications sends large amounts of data to the .NET application
Data latency should be kept to a minimum
.NET application should also be able to request for some data (synchronously/asynchronously)

The easyest way .Net and Java can talk is using Web-Services - we have done in my company with much success (using apache's cxf and standard code on the .Net side).
But if latency and size are the main requirements, you should use Sockets - both platforms offer a pretty extensive socketing frameworks and it would give you the best performance possible.

I think this can be done by setting up an xml webservices layer on the java side. You can use RestEasy for restful web services. Just my .2 cents.

Another alternative is some form of MOM (Message Oriented Middleware). There are a lot of implementations, but one to look at first might be ActiveMQ as it has both Java and C# bindings (among others).
I'm not saying this is better than using a web-service, it entirely depends on what your requirements are.

We have had good experiences with providing web services with JAX-WS (part of standard runtime in Java 6). They explicitly list .NET compatibility as a goal and is well supported in IDE's.
The Endpoint.publish() mechanism allow for small, simple deployments.

You can use Web Services. Jax-WS is the API in java that allow you to use it. As the implementation of this API I recommend metro (http://metro.java.net/), this already came with the SDK, and has a great integration with netbeans.
As already someone referred yet, you can use a socket, and create a communication channel on that, but this have some problems, starting with security. Don´t use this in real life applications.
If you need help with this subject you can start reading this:
Getting started with JAX-WS

It really depends on your requirements. The simple way is generally Web services. However, if you want higher performance, or more fine-grained access to the API on the other platform, you might want to consider JNBridgePro (www.jnbridge.com).
Disclosure: I work for JNBridge.

WCF Interoperability Test

Could anyone please suggest how to test whether WCF with wsHttpBinding you built is interoperable to PHP, Java and other tools?
Is there any tool that exist to test above
Thank you

No such tool exists for PHP because PHP doesn't have native support for WS-* standards. You always need some specific third party library / framework to make it work. These libraries are usually based on C++ or Java and exposing functionality to PHP. Different libraries can support different feature set. I have previously integrated with WSO2 for PHP and features demanded by customer required complete custom binding for WCF.
The same is theoretically true with Java. In contrast to .NET and its WCF, Java application servers provide different implementations of WS-* standards. WCF team recently published first preview of interoperable bindings which should provide only features available by targeted Java client.
Anyway if you want to test that it works you must indeed write a client on the targeted platform. Here you have very nice article about exposing the service with interoperable binding and consuming the service in Java.
The general tool for testing services is SoapUI but it test just functionality. You still have to understand if your target platform supports additional features required by the service or not.

What approach for java web service to use?

I'm developing a web application with multiple frameworks (spring, hibernate, spring-security, ZK for GUI), and using Tomcat as app server. I must say I have absolutely no experience with java web services technologies. Thing is, I will almost certainly have to expose number of services for some external applications in the near future, and I was wondering what would be the way to go (considering the frameworks I'm using)...
I saw and read various tutorials and some questions (link) regarding Axis, Axis2, JAX-WS... Thing that confuses me a little bit is that I don't know what is the common practice (if any) to integrate services within existing web application (mainly in the terms of project organization). As I see it now, these services that I need to implement will rely partially on the existing source code, so I don't know whether I should use completely separate project, or I can put it inside my existing web app folder (which I tried with Axis2, but don't know if it's a good practice).
Thanks.

How to organize the projects?
In general I agree with #ericacm, but there is one thing you should keep in mind... You said you're going to develop a number of services in the near future. You may come to a point at which you want to host the services on a separate server, e.g. for performance, availability or maintainability reasons. This may influence your decision of separating the projects. Furthermore, separation "enforces" loose coupling, but therefore introduces other challenges like session sharing across multiple WARs. It's a case-by-case decision.
If I were in your situation I'd first ask myself whether the service(s) logically belongs to the web application or not.
Implementation
When in comes to WS-* implementations you have to make 2 decisions:
Decide for an API to use; today, I can't see any reason for not going with JAX-WS together with JAXB as API, they work well and they are standardized.
Decide for a Framework; I've experience using Axis2 as well as METRO (keep in mind that JSE 1.6+ provides basic JAX-WS support). Both work well. It's fairly easy to change the frameworks if you use the JAX-WS APIs.

I have good experience with Spring-WS 2+ and manual Castor mapping . Is is easy but powerful combination.
Spring-ws 2:
provides contract-first development (specially good for the web app with number of services).
provides WS annotation
supports XML mapping (Castor, JaxB, etc)
Castor:
mapping based on xml configuration
allows map multiple messages (requests/responses) to one java object (based on xml configuration)
If you are using some Java EE 6 server, consider also JAXB for manual mapping:
mapping based on annotation
should be faster than Castor
allows map multiple messages (requests/response) to one java object (when you use java inheritance)

You can go ahead and put them into the same project. Each web service will be an additional interface and implementation class along with some configuration.
Since you are using Spring CXF is a good choice as a for JAX-WS as it integrates well with Spring. See this page as a starter.

Spring-WS is complex framework for simple web services. If you want to understand web services completely and to know the nuts and bolts of web services, learn Spring-WS. It is extremely flexible and provides lot of options.
Else, if you want simpler alternative use JAX-WS. Spring supports JAX-WS annotations. Refer to the section 17.5.7. Exporting web services using the JAX-WS RI's Spring support.
http://static.springsource.org/spring/docs/2.5.x/reference/remoting.html

Is it possible to create WS Server and WS Client manually (without generators) by JAX-WS? Specially if you are developing a big application you want to re-use objects but generators are generating a lot of classes that can be in 99% the same (for example if your app is WS Client and you have to connect to badly designed external WS Server). Is there some tutorial how co create ws manually?
There is a lot of reasons why I don't like generators and completely agree with http://ogrigas.eu/spring/2010/04/spring-ws-and-jaxb-without-a-code-generator

Advantages of SCA over Spring?

I have experience developing java web applications with Spring, but not so much with the world of SOA. I was reading about SCA- SCA4J - http://www.service-conduit.org/user-guide.pdf - and alot of this seems very similar to Spring.
I was trying to learn about what situations SCA would be useful, but still dont understand what features / benefits SCA offers over using Spring standalone.
I found this old blog post - http://rajith.2rlabs.com/2007/08/05/sca-vs-spring-a-reply-to-dans-post/ - but nothing really stood out to me from the SOA jargon.
I'd appreciate it if anyone could give an explanation geared more towards a spring developer (who is very green in the world of SOA terminology / methodology).
Thanks

I'm not the most knowledgeable about Spring, but am pretty familiar with SCA from having worked with it in IBM's WebSphere Integration Developer IDE and the environments it deploys to: WebSphere Enterprise Service Bus and WebSphere Process Server.
It really all has to do with abstraction and the thought of allowing developers to focus on what is most important - business logic. We are all familiar with the concept of Object-Oriented Programming and how that abstraction better represents the "real world". Then along comes web services and the service-oriented architecture approach. Web services further abstract our logic by making it less dependent on what language is behind our logic. Now C++ or .Net or Java or even RPG or COBOL or whatever could be behind our web service. We can get languages and systems to talk to each other in a way that doesn't depend on CORBA and libraries and what not.
SCA (Service Component Architecture) attempts to take SOA to the next level. It attempts to abstract the protocol and address used to talk to another system or service. Here's the why: With working with web services, you as a developer still need to work with protocol and write or hook in a LOT of boilerplate code. You have to know if you are http or https. You have to know if you are (in the Java world) JAX-RPC, JAX-WS 2.0, JAX-WS 2.1, JAX-WS 2.2 or even JAX-RS (REST based). You need to know if you are working with JSON, XML, or SOAP and if SOAP, is it 1.0, 1.1, or 1.2? And sometimes you even have to know how the vendor of your application server implements certain things (you shouldn't, but it can be the case). And then what happens if you want your web service to talk to another service. But that second service happens to be messaging based. Does that mean JMS? MQ? JMS over MQ? other? And what about just pure HTTP POST and GET?
This is where SCA comes in. SCA attempts to abstract the end points of your services and hide the protocol implementation from you the developer. When you need a service you just look it up via the SCA API's and then invoke the service (I think the method is execute? At least it is in IBM's extension of SCA). But anyway....Now you do not have to know that the service you are communicating with is JAX-WS 2.1 or REST or even MQ. You don't have to know that you working with SOAP/HTTP or JSON/XML or SOAP/JMS or whatever. SCA hides this all from you. It allows you to connect services of differing implementations to each other so they can all talk to one another via a common "service interface".
As you can imagine, this is another layer of abstraction and technology on top of existing abstracted technologies. But having seen it myself, I believe it is worth looking into. I know IBM and Apache (and I think others that just don't come to mind at the moment) worked on coming up with the SCA standard. (And actually IBM's version of SCA is now built on the open standard that Apache presented. Hopefully other vendors that support SCA do the same.)
I think it is worth taking the time to look at. It can help you to focus not so much on the integration of services based on their protocols, but rather the business logic of the services, which is really the value they bring to the table.

SCA is being standardized through OASIS (Assembly Specification), so you can chose from different implementations (e.g. Apache Tuscany or Fabric3).
SCA defines applications in terms of the following basic building blocks:
interface: defines available operations
component: describes an implementation artifact in terms of which "services" it offers, which "references" it requires, and which configurable "properties" it exposes
binding: declares the communication protocol used by a service or reference
policy: captures non-functional requirements for services, references, or implementations
To build SOA applications, concrete "types" of these entities are assembled into composites. For example:
interface: WSDL port type, Java interface
component implementation: Java class, BPEL process, Python, Spring
binding: JMS, Web Service, RMI/IIOP
policy: transaction, security
In addition, SCA defines unified client APIs to invoke components both synchronously and asynchronously (including one-way). For Java this includes annotation-based reference injection.
Combining these capabilities enables you to easily create distributed applications from heterogeneous technologies and evolve them by adding or swapping binding, implementation, interface, or policy technologies.

It is worth looking at Spring Integration (http://www.springsource.org/spring-integration) as opposed to basic Spring when comparing to SCA, since Spring Integration offers a very nice framework for transparently wiring together remote components.

Jetty vs CXF / Which one to choose?

I am fairly new to the Java world and pretty overwhelmed by the beauty of choice between dozens of libraries doing more or less the same thing, or not.
So with Jetty and CXF. I am looking for a web services stack that has built-in support for a wide range of transports and protocols.
I was under the impression that CXF is the more recent project and would be the preferred choice for new software projects. Especially when it comes to applications that have to talk a variety of different protocols and standards like WS-*.
Can you give your opinion on how those frameworks differ from each other?
Which one has broader support for different protocols and standards?
Which one would you prefer regarding its design e.g. how well they hide transport, authentication, authorization, serialization aspects from application logic?
Any kind of answer very welcome!
Cheers,
Alex

Jetty is a web server and servlet container. CXF is a library for web services. If you want to serve out content like is done with a web server, choose Jetty. If you need to connect to or provide web services, choose CXF. I'm not sure there's any blurred area between the two.

There is a misunderstanding here, Jetty and CXF are like apples and oranges, it doesn't make sense to compare them. One is a light servlet engine, the other one is a web services stack.
If you're looking for a web services stack (which is my understanding), consider JAX-WS RI or CXF if you are looking for a JAX-WS compliant stack (both support contract-first or java-first), or SpringWS ("only" contract-first), or maybe Axis2 (I don't like it personally it because of its development and deployment model and its performances).
If you don't need fancy WS-* stuff, I'd suggest to use JAX-WS RI which is included in Java 6 and is compliant with the WS-I Basic Profile 1.1 (so it covers a decent bunch of WS-* standards). If you need more advanced things (like WS-SecureConversation, WS-SecurityPolicy, WS-ReliableMessaging, WS-Trust, WS-AtomicTransactions/Coordination, WS-MetadataExchange, SOAP over TCP which are provided by WSIT/Tango), consider using Metro (Metro = JAX-WS RI + WSIT/Tango).
(EDIT: Answering a comment from the OP about WS-SecureConversation support.
Actually, I think that the stack that supports the most WS-* standards is Metro. You might want to check Apache Axis2, CXF and Sun JAX-WS RI in comparison for more details. But, it is very unlikely that you'll need all of them and things might have slightly changed since the article has been published. So CXF might indeed be an alternative. For example, regarding WS-SecureConversation, CXF does support it too according to its documentation but only with "wsdl-first" projects. Without more details about what you're going to do, it's hard to give you a more accurate answer about which one is the best for you.)

Jetty is a server(a servlet container), so is Tomcat and few others. Jetty is decent, Tomcat has been around for a while and has more documentation and tutorials.
CXF looks like an interesting choice. I've only use directly implementations and CXF was fairly new, I think it's the continuation of XFire project.
CXF looks like a wise choice. When in doubt, I would say go with standards and frameworks built upon them. I would say go through the documentation and for complicated matters, you might want to subscribe to some mailing lists.