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.
Related
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.
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.
Sorry for such a naive question, but can anyone explain to me the difference between Java web services (jax-ws) and .Net web services behaviours?
Since the term "web service" is used with slightly diverging meanings, I assume we're talking about its W3C definition.
This definition basically defines to specifications: WSDL and SOAP. Additionally, there are a bunch of other specifications known as WS-* that define special usage of WSDL and SOAP for special purposes (e.g. security).
Both, Java and .NET try to implement a web service engine that adheres to these specifications. Since these specifications are fairly complex, both make mistakes. Furthermore, the goal of providing interoperability is not completely meet. For example, the SOAP specification defines an optional SOAPAction HTTP header that is not used in JAX-WS but is required in .NET (Don't know if this is still true for current versions).
So the Metro (Metro is a web service engine using JAX-WS) web site mentions regular interoperability tests with .NET
By the way, JAX-WS is the name of specification as well as a reference implementation thereof.
Ideally, the idea of web-services is to not give you a chance to have such a questions. :)
A client should not be able to distinguiish between web services implemented using either technology, or ideed any other technology. The promise of Web services is that they should be interoperable across many platforms, and service providers can use whatever technologies they prefer, so a Java shop would use Java, JAX-WS for example, and .NET shoop their technologies - clients just don't care, they use the WSDL.
Things get a bit more interesting when we move away from basic SOAP/HTTP web services and use standards for security, transactions, messaging etcs (the whole WS-* space). Ideally the implementation transparancy is still true, but you can't count on an arbitrary implementor supporting what you want to do. The WS-I organisation, and it's participating vendors, do a great deal of work to ensure interoperability, so the story is not too bad even for these more advanced WS-* standards.
Be carefull, wcf compares to metro, jax-ws has just the basics, not all the ws* stuff.
Metro and WCF implements an interoperation standar wse 3. And can communicate with each other through xml without any problem, you just do not know if the service is .net or java based.
Regards
I'm currently in the research phase of my dissertation project.
My project is a ticket booking system for a mobile device and I have chosen to target Android.
I anticipate the need for a client/server architecture with a central server, and so am currently looking at how Android could communicate with such a server. The server would grant the client access to ticketing information, and the client would send information about ticket bookings to the server. I'm looking at Java EE for the server as Java is the language I'm most experienced with.
I'm aware that Android comes with java.nio and java.net, as well as some org.apache packages, but am also looking for libraries/technologies that would be possible to use with Android.
So far I've not found anything massively helpful on the internet, so I'm seeing what SO can suggest.
Specifically I am interested in knowing:
What support is there for various middleware technologies in Android? e.g.
RPC based middleware
CORBA
Message based middleware
Web services such as XML-RPC, SOAP, REST
How well (or not) do existing Java libraries work when used on the Android platform? (e.g. If I wanted to use a library/API designed for Java SE rather than Android what problems might I encounter?)
Ideally, as the focus of my project isn't meant to be the communication between the server and client, I could use an existing middleware to handle the communication, but I am prepared for the worst case, which is having to write my own.
What support is there for various
middleware technologies in Android?
My personal opinion -- though I do not feel I am alone in thinking this way -- is that only protocols specifically designed to run over the Internet are remotely suitable for use with a mobile client. So, of your list, the only one that I would even entertain would be:
Web services such as XML-RPC, SOAP, REST
Some people have been maintaining an Android port of kSOAP2. However, I get the distinct impression that most Android developers working in this area have tended towards REST and REST-ish protocols. If nothing else, that's what all the fun Web sites and services are using for an API, particularly compared with XML-RPC (old) and SOAP (old and icky).
I have successfully used both the java.net.URLConnection and Apache HTTPClient libraries in Android for communicating with REST-style endpoints -- both directly and through third-party JARs -- with no real Android-specific issues.
How well (or not) do existing Java
libraries work when used on the
Android platform?
It is difficult to answer that in the abstract. Android implements a substantial subset of JavaSE, but not all of JavaSE, so there's a chance that any given JAR will expect something Android does not offer. Similarly, Android does not use environment variables, command-line switches, or a variety of other things that developers focused on the desktop might have introduced as semi-requirements. So, some things have worked for me with nothing more than a recompile (Beanshell), and some things have worked for me after removing redundant classs (JTwitter), and some things looked like they were going to be ghastly to get working (JavaMail).
I have a user interface in .net which needs to receive data from a server, on a request/reply/update model. The only constraint is to use Java only on the server box.
What is the best approach to achieve this ? Is it by creating a Webservice in Java and then accessing it in .net, or should I create Java proxies and convert them in .net by using IKM ? Or do you have any better idea ? It can be HTTP based, used a direct socket connection, or any middleware.
I recommend the web service route. It offers a standard interface that can be consumed by other client platforms in the future.
.NET clients interact with Java web services pretty well, though there are some gotchas. The best two technologies available for you for the .NET client are Microsoft Web Service Enhancements (WSE) and Windows Communication Foundation (WCF). WSE is an older technology that is no longer being updated by Microsoft, but still works great in Visual Studio 2005 and older. I find WSE to be a bit easier to get started with in terms of how you interface with basic services, but WCF has much more support for WS-* protocols (security, trust, etc.). If your needs are basic and you're still using Visual Studio 2005 (.NET framework 2 or older), then go with WSE. If you like the cutting edge, or you anticipate more advanced security needs (doesn't sound like you will), then go with WCF. Please note that WSE will not work easily in Visual Studio 2008 and newer, and WCF will not work in Visual Studio 2005 and older.
Going the web service route will mean that you will design to an interface that can be reused and will result in a more loosely coupled system when you're done than most of the other routes. The downside is primarily performance: xml serialization will be slower than binary over the wire, and web services do not handle large amounts of data well.
Write webservice in Java and access it in .net
Using a standard type of web service (e.g. SOAP or XML-RPC) is best because not only is it easy to produce/consume, it's easy in other languages as well.