Mark D. Hansen

Proxisoft has released the Netrifex platform for web service enabling existing Java applications. Add SOAP and REST endpoints at runtime. No source code modifications required.


Netrifex Instantly Adds Web Services to Existing Java SE and Java EE Applications, Enabling Rapid and Low Cost Deployment of Web Services Across the Enterprise

Proxisoft today announced the release of Netrifex 1.0.

Netrifex adds web services to existing Java applications using a point-and-click browser interface. The product enables users to:

* Create web service APIs in a fraction of the time and cost required by traditional programming methods.
* Add SOAP and REST services to applications without modifying their code.
* Start, stop, add, modify, and delete web services without shutting down or disrupting production applications.
* Create and administer web services through a simple point-and-click user interface. Common use-cases require no programming.
* Generate web service interfaces automatically for applications built from common frameworks such as Apache Struts.
* Implement stateful web services that are aware of user sessions and other types of application state.
* Web-service-enable applications without source code (e.g., third party products, libraries). Netrifex does not need to read or re-compile source code.

Netrifex adds web services to stand-alone Java programs and applications running in Java EE containers. Netrifex works with Java 1.4.2 and higher. Windows, Linux, and Mac OS X operating systems are supported. Supported containers include Apache Tomcat and Oracle WebLogic Server. WebSphere, JBoss and others will be added soon.

Download Netrifex with a 30-day trial license from http://proxisoft.com/trial.html.

Read the full press release.

For more information, see http://proxisoft.com.

[size=big]ServiceLayer instantly adds web services to any Java application or class library using a point-and-click GUI.[/size]

Download now from: http://agileitinc.com/download.

AgileIT (http://www.agileitinc.com) has released a new product, ServiceLayer, which enables you to SOAP and REST web services to Java applications at runtime. No coding is required. With the graphical user interface, you navigate an application and simply point-and-click to select classes and methods to deploy as services.

ServiceLayer runs under Windows and Linux. It can add web services to standalone applications, container-based systems, third-party programs, and class libraries.

Compared with traditional methods for web service enablement, ServiceLayer has these benefits:
• Dramatically lower project costs and shorter implementation times.
• Eliminate expensive custom programming required to create or deploy web services.
• Short learning curve. No need to master the complexities of JAX-WS, JAXB, SOAP, XML Schema, REST, JSON, or other web services technologies.

Customers use ServiceLayer to:
• Provide customers and partners with web services access to internal systems via Internet, intranet, or VPN.
• Create programmable APIs for web sites.
• Integrate Java applications with an enterprise SOA or ESB.
• Enable web service for web applications built on Struts and other MVC frameworks.
• Provide web interfaces to standalone (i.e., fat client) Java applications.
• Replace Swing and SWT user interfaces with browser-based front ends.
• Add web services to third party binaries or in other situations where source code is not available.

ServiceLayer provides a runtime framework that automatically proxies existing classes and enables you to dynamically add and remove web services – even while the target application is running in production.

Using ServiceLayer, you create a custom web services API for a Java program or class library at runtime - without modifying or recompiling any code. The simple administration console allows you to configure ServiceLayer to bind selected Java components to SOAP or REST endpoints. ServiceLayer automatically generates and deploys proxies that implement the endpoints. Proxies are generated by inspecting bytecode, so source code access is not required.

To enable web services, you simply:
• Install ServiceLayer.
• Run the ServiceLayer administration graphical user interface.
• Select the classes and methods to deploy as web service endpoints.


[size=big]Example Use Case: Inventory Management Integration[/size]

Consider the example of a widget manufacturing company – WidgetCo - that has an order processing application written in Java. The company lands a big customer, say Walmart, and Walmart tells WidgetCo that they need to integrate their order processing application with Walmart’s inventory management system using web services.

With ServiceLayer, WidgetCo can publish the existing Java class (named ProcessOrder) that currently processes order entry forms, as a web service. Now, Walmart’s inventory management system can immediately begin sending orders to the new web service. The Walmart orders will be processed just like any other order entered into WidgetCo’s system. ServiceLayer handles all the web service communication to and from the Walmart inventory management system and translates it into Java method calls that are handled natively by the WidgetCo order processing system. Other than installing ServiceLayer, no changes are made to the WidgetCo systems. Publishing the ProcessOrder class as a web service can be done in minutes with a few mouse clicks.

ServiceLayer can be downloaded from: http://agileitinc.com/download.

[size=big]ServiceLayer Screen Shot[/size]

Somehow, I missed this post last week. Sorry for that.

Check out David Chappell's blog post on this topic.

I haven't used SCA and I have only briefly studied it. My knee-jerk reaction to it is, "why do we need one more set of enterprise architecture specifications for SOA??" when we've got SOAP, WSDL, WS-*, and BPEL.

But, IBM is big on SCA. In fact, I think they are more focussed on SCA than Java EE at this point. So, I'm sure it will get some traction.

The book covers Web Services using the mainstream Java APIs, i.e., JAX-WS, JAXB, JSR-181, and JSR-109.

If you use Spring with XFire and/or Spring with XFire and JSR-181, the book will be helpful.

It does not cover Spring Web Services.

OK. Java -> WSDL mapping works the same way for JAX-RPC 1.1. Class maps to port. Method maps to operation.

Thanks for hosting me this week on JavaRanch. It was fun to be here. Good luck with all your SOA / Web Services projects

-- Mark

I'm not sure that I completely understand your question, but here is some explanation that might help. Respond back if you need more information.

JAX-WS, which is the standard for writing and consuming Web services in Java, maps a Java class to a single wsdl ort. Each public method gets mapped to a single wsdl peration on that port. That is the default behavior when you simply annotate the class with @WebService.

With WSDL, you can have multiple ports for each service. But, the JAX-WS mapping doesn't work that way. I.e., there is no way to bundle two classes and have them generate a single WSDL. The work around is to create a wrapper class that simply passes method invocations to the appropriate method on the appropriate class. Then use the wrapper class to generated your WSDL.

So, if you simply apply the @WebService annotation to your service class you'll get a single WSDL, with a single port, that has 15 operations. There is nothing wrong with that.

Do you work for Microsoft ;-)

This question seems like a new spin on the age old Java vs. C# debate. The best guy I have heard talk about that is Ted Neward (who wrote the Foreward of my book). Check out Ted's article on that topic here.

I haven't worked with WCF, but I hear that people think it is a step forward. And this WCF book is selling well.

I think Java and .NET will coexist for a long, long time as platforms for SOA development. That is the whole point of SOA - that you can write code in whatever language you are most comfortable, and have it interoperate with other people's stuff.

I like Java because there is a lot of innovation in the Java world - particularly in the open source community. For Java Web Services, you've now got the mainstream standards (JAX-WS, JAXB, JSR-181) which are built in to Java EE 5 and Java SE 6. But, you have also got great alternatives coming out of the open source community such as XFire, XFire with Spring, Axis2, and the new Apache CXF.

The Java vs. .Net this is good for everybody because competition keeps both platforms improving and improving.

Yes, it should be fine for beginners. It helps to know some XML and have some basic idea about server side Java (e.g., Servlets). Please see this post.

http://docs.oasis-open.org/wss/oasis-wsswssecurity-secext-1.1.xsd

The WS-Security 1.1 Core Spec is here: http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

Unless you want to publish the servlet functionality so that other clients can use it, there is no reason to convert to a Web service. If it is only a single client using it - and you are designing both the client and the servlet - then it is fine.

The benefit of Web Services is that you could publish your server side application so that a variety of clients could access it using XML/HTTP or SOAP.

If you want to convert the application to Web Services technology, just as a learning exercise, then you can do that. Chapter 3 of my book shows how to do the kind of thing you are describing both with servlets and with the javax.xml.ws.Provider class for creating RESTful Web services.

I think you (and Erl and the WS-I people) are right. SOAP level sessions and the support of intermediaries are important. That is one of the main problems solved by SOAP (vs. POX/HTTP and REST).

We'll see how all this shakes out over the next few years. My guess is that SOA fragments into 2 versions - (1) Basic SOA: that is tightly coupled with HTTP and is widely used for applications running over the public Internet. This is build on REST (and maybe WADL). (2) Enterprise SOA: that takes advantage of SOAP, WSDL, and the WS-* stack.

One idea that I have for my blog is to include posts and code examples on SOA and Java Web Services topics that didn't make it into the book. I've been getting some ideas from our discussions here. So, far, I am thinking about:
* SOAP-based session management.
* RESTful services using the new JSR-311 API

Are there any other topics that you guys would like to see me blog about?

Good question

JAX-WS 2.0 supports HTTP based mechanisms for Session Management. I did not cover them in my book, because they seemed to me to be an "advanced topic". Maybe I will add something in the next version.

Here is a little information and some pointers where you can learn more.

The JAX-WS specification discusses HTTP based session support via cookies, URL rewriting, and SSL session ID. Only URL rewriting is required. As you point out, however, none of these are usable when you require sessions to be managed at the SOAP level, so that messages can travel over intermediaries.

For that purpose, JAX-WS 2.0/2.1 defines as a goal (in Section 1.3.9) the support of SOAP based sessions. However, the only SOAP-based sessions defined in the JAX-WS specifications are for the SOAP/HTTP binding. So, still, there is no real SOAP session implementation required in JAX-WS 2.0/2.1.

However, JAX-WS 2.1, which was only finalized in May 2007 (too late for my book), requires support for WS-Addressing. WS-Addressing provides a framework for SOAP sessions.

Although not required in JAX-WS 2.1, the Sun JAX-WS 2.1 reference implementation does support true SOAP sessions. One of the Sun developers, Kohsuke Kawaguchi, describes it in his blog

Please have a look at the detailed Table of Contents and let me know if you have some more specific questions about what is covered or not covered.