|
|
WS-Policy and the restFabian's Blog on WS-Policy and the rest |
|
Monday Apr 21, 2008
Metro Hands-on Lab at JavaOne 2008 completely booked
I am being told that the hands-on lab for Metro at JavaOne 2008 is already completely booked. That is certainly a motivator for us to make sure you get the most out of this lab. Hope to see you there, and if you did not get in, try to stop by at the venue, there usually are some no-shows and I believe they will let in people from a waiting queue instead. Tags: Web Services, Metro, JavaOne 
Posted at 10:56AM Apr 21, 2008 by Fabian Ritzmann in Sun | Comments[0]
Thursday Apr 17, 2008
Metro Hands-on Lab at JavaOne 2008 Carol McDonald, Martin Grebac and me have developed a hands-on lab for Metro at JavaOne 2008. At the hands-on lab you bring your own laptop and can try out Metro in practice. We have a script with screenshots etc. that you can work through to familiarize yourself with Metro. Carol and I will talk you through the lab. There will be proctors who can help should you have any questions or difficulties. We hope to see you there. I am sure it will be worth your while, the lab involves kittens! (No animals are going to be harmed nor were they harmed when developing the lab and writing this blog.) You can find out more about the lab here: https://www28.cplan.com/cc191/session_details.jsp?isid=296941&ilocation_id=191-1&ilanguage=english The title of the lab is "Metro: Try Out Simple and Interoperable Web Services". Session ID is 3410. The lab takes place on Tuesday, 10:50 - 12:50. I don't know exactly what room it will be, please check the JavaOne program once you have registered. Here is the complete abstract: Metro is a high-performance, extensible, easy-to-use web service stack. You can use it for every type of web service, from simple to reliable, secured, and transacted web services that interoperate with .NET services. Metro bundles stable versions of the JAX-WS (Java™ API for XML Web Services) reference implementation and WSIT (Web Services Interoperability Technology). JAX-WS is a fundamental technology for developing SOAP-based and RESTful Java technology-based web services. WSIT enables secure, reliable interoperability between Java technology-based web services and Microsoft’s Windows Communication Foundation. This Hands-on Lab starts by developing a simple Metro web service and showing how to enhance this web service with Metro features such as reliability and security. The next part of the lab enables a web service client with Metro security features and has it interoperate with the previously built service. The lab shows the ease of development the NetBeans™ 6.0 release provides for achieving this. The lab uses the NetBeans 6.0 release to modify and configure both the web service and the client, using Sun’s GlassFish™ project application server as the container. The lab uses WS-Reliability and WS-Security as examples of Metro’s secure, reliable features. The lab comprises the following sections: Introduction to Metro
Prerequisites: some understanding of Servlets, XML, and SOAP At JavaOne, this lab will be presented in Hall E (Room# 132). Please bring your laptops to this lab as there no machines provided in this room. System requirements:
Software requirements: Also please make sure to install the following software prior to coming to this lab:
Posted at 03:16PM Apr 17, 2008 by Fabian Ritzmann in Sun | Comments[1]
Thursday Feb 14, 2008
Non-standard WSIT configuration file locations for Metro Rickard Lundin recently asked this question: "I need to be able [at] "runtime" to choose wsit config file. One way would be to have multiple "WEB-INF/..xml" and add exactly one of them to the jvm classpath." There are at least two ways to approach that question. The approach we designed the WSIT configuration for is that you know all your services that you are talking to in advance. That is a reasonable assumption since you need to know the structure of the SOAP messages, etc. to talk to a web service anyway. If you already know the service you are going to talk to, you can do the WSIT configuration before deployment. So the first approach boils down to: Configuring multiple WSIT web services or clients at onceCreating and configuring multiple web services has been designed into WSIT from the beginning. The WSIT tutorial has an extensive example how to configure one web service without the help of NetBeans. The important aspect of this example is that it uses a configuration file named The web service client is only slightly more complex to configure. A client has no notion of an implementation class. Thus it always searches for the configuration file
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
name="mainclientconfig">
<import location="EchoService.xml" namespace="http://service.echo.ws.xml.sun.com/"/>
</definitions>
The actual configuration is contained in the file EchoService.xml. That makes it very easy to configure clients for additional web services. Simply add more import statements to the Now while the above covers most use cases, we ran into a problem with Open ESB. Open ESB builds composite applications, which ultimately means in our case that it bundles web services inside an application inside a composite application. Consequently, looking up our configuration files from the class path did not work anymore because the files were inside a bundle on the class path. So we had to create a proprietary extension to: Pass configuration file location into WSITNote that the following is an unsupported extension to WSIT and the interfaces may change any time without notice. Moreover, the same mechanisms are used to pass servlet data into JAX-WS and you are likely introducing unpleasant side-effects if using this when running a web service as a servlet. On the client side, you need to create a client by using the The implementation on the web service side is pretty similar. Instead of Tags: GlassFish, WS-Policy, Web Services, Metro, JAX-WS, Project Tango, WSIT Posted at 07:12PM Feb 14, 2008 by Fabian Ritzmann in Sun | Comments[2]
Tuesday Feb 12, 2008
Policy code fully integrated again As I explained in my last blog entry, we moved the policy core code with support for WS-Policy into a separate workspace on java.net several weeks ago: https://policy.dev.java.net/. Since late January that code has been successfully reintegrated into Metro. It was a very smooth process indeed. I set up a build job to create a policy.jar with Maven 2. Then I removed the policy core code from the Project Tango code base and added the policy.jar to the compile class path. The builds have been working flawlessly ever since. You do not actually notice any difference from the outside because the policy.jar like all other run-time libraries for Metro is repackaged in Metro's webservices-rt.jar. One final step that is still outstanding and that we will realize with JAX-WS 2.2 remains. Right now Project Tango still contains all policy code that has a dependency on JAX-WS. That code will be moved into JAX-WS 2.2 and out of Project Tango entirely. This will allow us to support e.g. WS-Addressing policy assertions directly from JAX-WS without the addition of Project Tango. Tags: GlassFish, WS-Policy, Web Services, Metro, JAX-WS, Project Tango, WSIT Posted at 12:03AM Feb 12, 2008 by Fabian Ritzmann in Sun | Comments[0]
Monday Jan 14, 2008
New workspace for policy
We are currently working on moving the existing policy code out of Project Tango and into a separate workspace. This open source project is hosted as a part of the Metro community within GlassFish on java.net. The new workspace will allow us to do two things:
The web site is already fully operational and the policy base code checked in. We are now working on reintegrating that code into the Metro stack. Tags: GlassFish, WS-Policy, Web Services, Metro, JAX-WS, Project Tango, WSIT Posted at 07:00PM Jan 14, 2008 by Fabian Ritzmann in Sun |
Friday Dec 21, 2007
WS-Policy in Metro 1.0.1, 1.1 and GlassFish V2 UR1
There has been quite a flurry of release activities this week. We had Metro 1.0.1 and Metro 1.1. Metro 1.0.1 is included with the freshly released GlassFish V2 UR1. For more details about Metro and the releases, see e.g. Vivek Pandey's blog. Our WS-Policy implementation in the context of Project Tango / Web Services Interoperability Technology is an integral part of the Metro stack. So what is new in WS-Policy for Metro 1.0.1? We really didn't find any severe bugs we needed to fix, i.e. the WS-Policy implementation has no significant changes over Metro 1.0. The same goes for Metro 1.1. Well, there was one bug fix, issue #654: @Addressing annotation does not generate WS-Addressing policy assertions. In practice, this bug had no real practical repercussions because the addressing implementation would be enabled by the annotation anyway. The one new and exciting feature is that the Metro 1.1 runtime now supports WS-Policy 1.5! We had very successful tests with our implementation at the W3C interop test rounds in spring already and now we finally have proper support in the product. Marek did virtually all the work implementing that feature and it has worked smoothly ever since. Note that our tooling still generates WS-Policy 1.2 expressions to maintain backwards compatibility. Tags: GlassFish, V2UR1, WS-Policy, Web Services, Metro, Project Tango, WSIT  
Posted at 03:00PM Dec 21, 2007 by Fabian Ritzmann in Sun |
Tuesday Sep 18, 2007
WS-Policy in Metro
After almost two years of work, I am very pleased that our code has been released as part of the Metro Web Services stack yesterday! Jakub, Marek and me were responsible for the WS-Policy implementation in the run-time, Martin for tooling. Our implementation provides support for WS-Policy and WS-PolicyAttachment 1.2. It is an open source implementation and among others is built into GlassFish v2. Our implementation has been designed to work invisibly in the background. The only time you will notice WS-Policy is when policy expressions are included in the WSDL that JAX-WS is generating at run-time. There are no APIs that you need to bother with, you only write ordinary JAX-WS code. You do not need to compile stubs to make use of our WS-Policy implementation, the configuration is picked up at deploy/run-time. NetBeans is providing extensive support to generate the necessary configuration. In the mean time, we are of course working full swing on the next version already. We have a nice list of features that we plan on supporting in the future, e.g. support for WS-Policy 1.5, better policy enforcement, easier configuration, etc. Technorati: GlassFish Web Services WS-Policy wsit projectmetro Posted at 09:00PM Sep 18, 2007 by Fabian Ritzmann in Sun | Comments[2]
Friday Sep 07, 2007
WS-Policy 1.5 published as a W3C recommendation
A few days ago, WS-Policy 1.5 was published as a standard by the W3C. Check out the press release for the relevant links. Monica Martin and me have been active members of the working group and I have been impressed by Monica's capacity and dedication to creating standards of high quality. We are actively working on support for WS-Policy 1.5 in Project Tango. You can already see our work in action on our interop test site. Technorati: Web Services WS-Policy Interoperability WSIT Posted at 01:00PM Sep 07, 2007 by Fabian Ritzmann in Sun | Comments[2]
Monday Jun 18, 2007
WSIT with a Java SE endpoint
The JAX-WS RI is supporting an Endpoint API that allows you to implement a web service just in plain Java without the need for a Servlet or EJB container. While we don't explicitly test WSIT with this API, it is still working just fine with it. You just need to take into account a few caveats. Here is some sample web service code. It does not differ in any way from any other JAX-WS web service: import javax.jws.WebService; Since you don't have a container, you will need to write a little bit of code to start a server that can host the web service. This code is ripped right off the Endpoint API documentation: import javax.xml.ws.Endpoint; You will still need to generate the portable artifacts of your web service before you run it. See the JAX-WS RI User Guide for details. So far all we have is an ordinary JAX-WS web service. If you are running Java 6, please remember that you need to put the API library into an endorsed directory, otherwise the JAX-WS 2.0 APIs included in Java 6 will override the JAX-WS 2.1 APIs that we require. Put webservices-api.jar into an endorsed directory if you are running Java 6. At runtime you will need webservices-rt.jar and webservices-extra.jar on the classpath and to generate the portable artifacts you need webservices-tools.jar. So, this was still all plain JAX-WS. All that you need to do to unleash WSIT is provide a configuration file and put it into the META-INF directory of your JAR (or if you have not jared up your code yet, put it in a META-INF directory on your classpath.) Writing a correct configuration file manually is an unpleasant task. I strongly recommend that you use NetBeans to generate one for you and then copy it into your project. The WSIT tutorial has extensive documentation on how to generate a configuration file. Technorati: WSIT Web Services Posted at 02:00PM Jun 18, 2007 by Fabian Ritzmann in Sun | Comments[2]
Tuesday May 29, 2007
Public WS-Policy Test Site
The W3C Web Services Policy Working Group ran an interop event last week in Ottawa. We put up a web site for all the policy interop scenarios that we are supporting. All the functionality is built on the open source code of Project Tango / WSIT. The only significant difference is that the interop site supports the new W3C policy namespace while WSIT uses the member submission policy namespace. The address for our web site is http://wsinterop.sun.com:3280/wspolicy_interop/. The site is meant to demonstrate the current technology and aid our interop testing. I will keep it up as long as I can, but it is not meant to stay up forever or feature product quality. If you are having any issues with the site, please let me know. Technorati: WSIT GlassFish Web Services WS-Policy Interoperability Posted at 05:00PM May 29, 2007 by Fabian Ritzmann in Sun |
Friday May 04, 2007
WSIT and WS-Policy at JavaOne 2007
We have quite a number of sessions, BOFs and labs that talk about Web Services, JAX-WS, WSIT and .NET interoperability. WS-Policy plays a role everywhere that WSIT is covered. It is the base technology to configure all the required functionality. You may find me at POD #966 or our hands-on lab. Here is a list of events (shamelessly stolen and adapted from Arun Gupta's blog):
WSIT GlassFish WS-Policy Web Services JavaOne Posted at 03:17PM May 04, 2007 by Fabian Ritzmann in Sun |
Thursday Feb 22, 2007
WS-Policy in WSIT milestone 3
With WSIT milestone 3, we are now shipping a complete WS-Policy implementation. WSIT provides an open-source and fully compliant implementation of WS-Policy 1.2 and WS-PolicyAttachment 1.2. We have lately been able to solely focus on fixing bugs and polishing the code and documentation and we currently have only very few open bugs . This seems like a good time to examine how WSIT supports WS-Policy more closely. And if you are wondering now what WS-Policy is in the first place, take a look at Marek Potociar's blog . WSIT is an extension of JAX-WS and part of the GlassFish community. JAX-WS supports quite a number of approaches to develop and configure a web service. You can start with plain Java code and use annotations. If you need maximum flexibility, you would implement the Provider interface. If you have a WSDL document, you may want to start by having JAX-WS generate a service endpoint interface. There may be some deployment descriptors that allow you to configure your web service, see e.g. JSR 109. And on the client, you can use WebServiceFeatures. Generally, the WS-Policy support in WSIT distinguishes between whether you develop your service starting from Java or WSDL. If you provide a WSDL document with your service, WSIT uses it and the contained policies to configure the system. The WSDL document is published almost unaltered. I am saying almost because this WSDL may contain policy assertions that are considered private. You can e.g. specify the password of a certificate store with a policy assertion. This and similar elements are automatically removed from the WSDL document before it is published. When a service is developed from Java without any WSDL, WSIT relies on a separate configuration file. The file format is almost valid WSDL 1.1 and the actual configuration settings are contained as policies. That makes it very easy when JAX-WS generates a WSDL document for the service to attach the given policies to the generated WSDL document. As is the case when you develop your service from WSDL, private policy assertions are removed before the final WSDL is published. Web service clients retrieve the WSDL of the service that they want to talk to. If that WSDL document contains policies, the client configures itself automatically to comply with the requirements of the service. Note that a client usually retrieves the service WSDL at run-time, i.e. the client configures itself at run-time as well. That makes it very easy to e.g. tighten the configuration of a web service in production without having to change or redeploy any client. (There is one exception to that rule, namely if you are using WS-AtomicTransaction, but then you have to adapt your code to deal with transactions anyway.) The WSIT client can additionally read a separate configuration file. That configuration file serves two purposes. It allows to configure client-only settings, e.g. the certificate store of the client. And in case the service WSDL does not have any policies or the service has no retrievable WSDL at all, the service policies can be added to the client configuration instead. The client configuration file has the same format as the service configuration file, i.e. it is almost valid WSDL 1.1. Technorati: WSIT GlassFish Web Services WS-Policy Interoperability Posted at 11:31AM Feb 22, 2007 by Fabian Ritzmann in Sun | Comments[2]
Tuesday Feb 06, 2007
How to configure logging in GlassFish for the WS-Policy implementation in WSIT II How to configure logging in GlassFish for the WS-Policy implementation in WSIT by editing domain.xml.[Read More] Posted at 11:44AM Feb 06, 2007 by Fabian Ritzmann in Sun |
Tuesday Jan 30, 2007
Configure java.util.logging at run-time Configure java.util.logging at run-time[Read More] Posted at 02:27PM Jan 30, 2007 by Fabian Ritzmann in Sun |
Thursday Nov 23, 2006
Is catching NoClassDefFoundError more efficient than using reflection?
Is catching java.lang.NoClassDefFoundError more efficient than using reflection? Catching Posted at 02:14PM Nov 23, 2006 by Fabian Ritzmann in Sun | |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
