Michael Sikora on Java EE

Converting to JBoss-5.0.0.GA - EJB3 Security

In this post I'll describe the conversion of examples of chapter 12, which deals with EJB 3 Security, from Glassfish to JBoss 5.0.0.GA. There are two aspects to EJB 3 security: authentication and authorization. Authorization (namely restricting access to bean methods to a given role or roles) turns out to be completely portable and no code changes were required.

All Java EE compliant application servers support the JAAS standard for authentication (namely checking a user's identity is valid, typically by validating a username and password). So using JAAS is recommended for ensuring portable applications. However JAAS is awkward to use, requiring the creation of a callback handler class with a lot of boilerplate code and rather invasively injecting more boilerplate code into the client class. Consequently application servers either hide the JAAS in a proprietary manner or provide a proprietary work around.

The JBoss solution is for the client to use the non standard org.jboss.security.client.SecurityClient class and associated SecurityClientFactory.

First we need to add the JBoss specific org.jboss.ejb3.annotation.SecurityDomain annotation to the BankServiceBean as follows:

@Stateless

@SecurityDomain("other")

@RolesAllowed("bankemployee")

public class BankServiceBean implements BankService {

"other" indicates that we will use JBoss's default authentication mechanism. JBoss's authentication configuration file is login-config.xml situated in JBOSS_HOME\server\default\conf directory. In the case of "other", login-config.xml invokes a simple JBoss supplied login module which in turn expects 2 properties files: users.properties and roles.properties. The content of users.properties is:

scott=xyz12345

ramon=abc54321

This is a list of usernames and corresponding passwords. The content of roles.properties is:

scott=bankemployee

ramon=bankcustomer

This is a list of usernames and roles to which they have been assigned. Both users.properties and roles.properties need to be in the same directory as the JBoss supplied login-config.xml. After the properties files have been created the JBoss server will need to be restarted.

Alternatively the properties files can be created in the application's directory structure and included in the EJB jar file.

Finally we need to modify the client by first importing JBoss specific classes:

import org.jboss.security.client.SecurityClient;

import org.jboss.security.client.SecurityClientFactory;

Then we need to invoke SecurityClient login methods before invoking the BankServiceBean EJB:

SecurityClient securityClient = SecurityClientFactory.getSecurityClient();

securityClient.setSimple("scott", "xyz12345");

securityClient.login();

InitialContext ctx = new InitialContext();

BankService bank = (BankService) ctx.lookup("BankService/BankServiceBean/remote");

This is the last in the migrating EJB 3 to JBoss 5.0.0.GA series. All the source code should shortly be available for download from the book's website.

Converting to JBoss-5.0.0.GA - Part 3

In this post I'll describe the conversion of the examples from chapter 11, which deals with EJB 3 Web Services, from Glassfish to JBoss 5.0.0.GA. The modifications required were all concerned with deployment: in particular invoking application server specific tools which generate various web service artefacts. These tools are invoked from the build.xml file.

wsprovide is the JBoss equivalent of the Glassfish wsgen tool and the Weblogic jwsc tool. wsprovide takes as input a Java class file with embedded web service annotations and generates all the artefacts, including a wsdl file, required to create a web service. In JBoss explicit use of wsprovide is optional as web service artefacts are generated at deployment time if they have not already been created by wsprovide. (The use of the Glassfish wsgen tool is also optional; however the Weblogic jwsc tool always needs to be explicitly invoked.)

wsconsume is the JBoss equivalent of the Glassfish wsimport tool and the Weblogic clientgen tool. wsconsume generates from an existing wsdl file the client artefacts that client applications use to invoke JBoss and non-JBoss web services.

The client needs to use WS-Security by creating a META-INF/standard-jaxws-client-config.xml file. A sample file can be found in JBOSS_HOME\server\default\deployers\jbossws.deployer\META-INF. This file needs to be copied to the application directory tree. The file is then edited so that only the Standard WSSecurity Client configuration is left. The edited standard-jaxws-client-config.xml file should look as follows:

<jaxws-config xmlns="urn:jboss:jaxws-config:2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="urn:jboss:jaxws-config:2.0 jaxws-config_2_0.xsd">

<client-config>

<config-name>Standard WSSecurity Client</config-name>

<post-handler-chains>

<javaee:handler-chain>

<javaee:protocol-bindings>##SOAP11_HTTP ##SOAP11_HTTP_MTOM</javaee:protocol-bindings>

<javaee:handler>

<javaee:handler-name>WSSecurityHandlerOutbound</javaee:handler-name>

<javaee:handler-class>org.jboss.ws.extensions.security.jaxws.WSSecurityHandlerClient</javaee:handler-class>

</javaee:handler>

</javaee:handler-chain>

</post-handler-chains>

</client-config>

</jaxws-config>

This file then needs to be packaged in the client jar file.

There are a large number of jar files that need to be included in the run time classpath. I had quite a job figuring out which jar files these should be only to find the answer in the wsrunclient script which is in the JBOSS_HOME\bin directory.

That's it - the next post will be on JBoss EJB3 security.

.

Converting to JBoss-5.0.0.GA - Part 2

In this post I continue describing the conversion from glassfish to

JBoss-5.0.0.GA. This post covers the examples from chapter 5 to chapter 10 of my book. This has proved very straightforward with only a couple of items to take note of.

Native SQL

One problem I hit was in lab6 of chapter 5. This deals with native SQL queries in JPQL.

In JBoss if one field definition is specified in a @FieldResult, then all fields for that class need to be specified even if they map onto the same column name. For example we may have the query:

@SqlResultSetMapping(

name="CustomerAccountResults",

entities={@EntityResult(entityClass=ejb30.entity.Account.class,

fields={@FieldResult(name="id", column="ACC_ID"),

           @FieldResult(name="accountType", column="ACCOUNTTYPE"),

            @FieldResult(name="balance", column="BALANCE"),

           @FieldResult(name="customer", column="CUSTOMER_ID") } ),

          @EntityResult(entityClass=ejb30.entity.Customer.class)

         }

),

Because we need to add the first @FieldResult entry to map id to column ACC_ID, we need to add a @FieldResult entry for every field in Account. This applies for fields such as accountType and balance which map onto columns with the same name. According to the JPA spec such FieldResult mappings are optional.

If we dont have a FieldResult mapping in JBoss we get a runtime error along the lines:

[JDBCExceptionReporter] Column not found: balance6_0_

Messaging

Chapter 8 deals with JMS Messaging. To create JMS resources such as

a JMSQueue named BankServiceJMSQueue

a JMSTopic named BankServiceJMSTopic

a JMSConnectionFactory named BankServiceConnectionFactory

we first need to create the following chap08-service.xml file:

<?xml version="1.0" encoding="UTF-8"?>

<server>

<mbean code="org.jboss.mq.server.jmx.Queue"

name="jboss.mq.destination:service=Queue,name=BankServiceJMSQueue">

<attribute name="JNDIName">BankServiceJMSQueue</attribute>

<depends optional-attribute-name="DestinationManager">

jboss.mq:service=DestinationManager</depends>

</mbean>

<mbean code="org.jboss.mq.server.jmx.Topic"

name="jboss.mq.destination:service=Topic,name=BankServiceJMSTopic">

<attribute name="JNDIName">BankServiceJMSTopic</attribute>

<depends optional-attribute-name="DestinationManager">

jboss.mq:service=DestinationManager</depends>

</mbean>

<mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"

name="jboss.messaging.connectionfactory:service=BankServiceConnectionFactory"

xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">

<attribute name="JNDIBindings">

<bindings>

<binding>BankServiceConnectionFactory</binding>

</bindings>

</attribute>

<depends optional-attribute-name="ServerPeer">

jboss.messaging:service=ServerPeer

</depends>

<depends optional-attribute-name="Connector">

jboss.messaging:service=Connector,transport=bisocket

</depends>

<depends>jboss.messaging:service=PostOffice

</depends>

</mbean>

</server>

The above xml file can be named anything but must end in "-service.xml". We have chosen chap08-service.xml. This xml file is then copied to the deploy directory. We have the following ant target in our build file:

<target name="create-jms-resources">

<copy file="chap08-service.xml" todir="${jboss.home}/server/default/deploy"/>

</target>

That's it for now. My next post will deal with Web Services.

Configuring passivation parameters in JBoss 5.0.0.GA

One gotcha I came across was configuring passivation parameters in lab 5 of Chapter 2. There does not appear a way to do this in the administrator console. Instead you use the JBoss specific CacheConfig annotation in your stateful session bean as follows:

@Stateful

@CacheConfig(maxSize=2, idleTimeoutSeconds=15) // JBoss specific annotation

public class ShoppingCartBean implements ShoppingCart {

The default values are

maxSize=100000, idleTimeoutSeconds=300

Alternatively you can edit the ejb3-interceptors-aop.xml file in JBOSS_HOME/server/default/deploy directory. This will apply to all stateful session beans in the deployment.

Converting to JBoss-5.0.0.GA - Part 1

I have finally started converting the examples in my book from glassfish to JBoss-5.0.0.GA. I won't describe all the conversion steps in this blog, just JBoss features that differed from other Java EE containers, or gotchas that caught me out. I used JBoss in its standard packaging; using the default Hibernate persistence engine and the embedded Hypersonic (HSQL) relational database. In this post I'll cover chapters 2, 3 and 4. As before I avoided choosing an IDE, instead I converted the glassfish ant build scripts to run on JBoss. The conversion took the following steps:

(1)Create the JBOSS_HOME environment variable that points to the JBoss installation directory. In Windows do this from the System Control panel.

(2) Set the ant property jboss.home to the JBOSS_HOME environment variable in the env.properties file

(3) in build.xml file modify the classpath to use JBoss directories

${jboss.home}/lib and  ${jboss.home}/client

(4) in build.xml replace the glassfish asadmin tool for deployment with a simple copy of the EAR or JAR file to the 

${jboss.home}/server/default/deploy directory. 

.

JNDI

The very first example in chapter 2 has a Java client running outside an application client container invoke a stateless session bean using JNDI. Because of JNDI differences, for JBoss we need to have the statement

TimeService timeService = (TimeService) ctx.lookup("ejb30.session.TimeService");

replaced by

TimeService timeService = (TimeService) ctx.lookup("TimeServiceBean/remote");

in

Client.java.

In the above example we deployed the TimeService EJB packaged in a JAR file. If the EJB is packaged in an EAR file, which is the normal case, then the JNDI lookup would be "EAR file name/ejb name/remote" for remote interfaces or "EAR file name/ejb name/local" for local interfaces. So in lab3 of chapter 2 the JNDI lookup is:

TimeService timeService = (TimeService) ctx.lookup("TimeService/TimeServiceBean/remote");

PERSISTENCE

Chapter 3 deals with persistence which entails modifying the persistence.xml file. Following examples in JBoss documentation I initially tried

<persistence>

<persistence-unit name="BankService">

<provider>org.hibernate.ejb.HibernatePersistence</provider>

<jta-data-source>java:/DefaultDS</jta-data-source>

<properties>

<property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>

<property name="hibernate.hbm2ddl.auto" value="create-drop"/>

</properties>

</persistence-unit>

</persistence>

This gave the error

"org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve schema nsURI= location=persistence" at deploy time. I suspect the above persistence.xml file would work for JBoss version 4.3 and lower, but for version 5 you need to add header details in the <persistence> tag as follows:

<persistence

xmlns="http://java.sun.com/xml/ns/persistence"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"

version="1.0">

<persistence-unit name="BankService">

<provider>org.hibernate.ejb.HibernatePersistence</provider>

<jta-data-source>java:/DefaultDS</jta-data-source>

<properties>

<property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>

<property name="hibernate.hbm2ddl.auto" value="create-drop"/>

</properties>

</persistence-unit>

</persistence>

JBoss provides a GUI based tool, the HSQL Database Manager tool for querying tables created when persisting entities. This tool is accessed from the JBoss administrator console. To initiate the console enter

http://localhost:8080

in your web browser. Then click on the JMX Console link. This brings up the JMX Agent View screen. Then under the jboss subheading click on the database=localDB,service=Hypersonic link. On the resulting screen click on the Invoke button of the startDatabaseManager operation.

This will then bring up the HSQL Database Manager window. You can then perform standard SQL queries.

In lab4 of chapter 3 we use a strategy of GenerationType.AUTO to generate primary key values.

In JBoss (using default Hibernate persistence engine and HSQL database) specifying a primary key generation strategy of GenerationType.AUTO will default to an IDENTITY strategy. In this case HSQL will use an identity column for generating a primary key value. If a column has not been specified as an identity column then HSQL will use the primary key column as an identity column.

O/R Mapping

In chapter 4 lab1 the Customer.toString() method was modified so that addresses and accounts are not referenced. This is because these are lazily loaded by default, and would otherwise give the run time org.hibernate.LazyInitializationException. So the following code fragment

public String toString() {

return "[Customer Id =" + id + ",first name=" + firstName + ",last name="

+ lastName + ", referee=" + referee + ",addresses=" + addresses

+ ",accounts=" + accounts + "]";

was modified to

public String toString() {

return "[Customer Id =" + id + ",first name=" + firstName + ",last name="

+ lastName + ", referee=" + referee + ",addresses= {not initialized}"

+ ",accounts= {not initialized}" + "]";

In lab2 JBoss gives a deploy error of "org.hibernate.HibernateException: cannot simultaneously fetch multiple bags." This is a known Hibernate feature when using a bag (i.e. Collection or List) for eager fetches. For example the following fragment from the customer entity:

@OneToMany(mappedBy="customer", fetch=EAGER)

public Collection<Account> getAccounts() { return accounts; }

public void setAccounts(Collection<Account> accounts) { this.accounts = accounts; }

This can be resolved by (a) adding an @IndexColumn annotation or (b) using a Set instead. (a) is a Hibernate extension to Java EE, so I used option b, Sets.

That's all for this post.

Devoxx 2008 Debrief

I was very impressed with the conference overall. Many of the presentations were given by the JSR spec leads so you were being briefed by really authoritative sources. In this respect Devoxx is probably second only to JavaOne. However many of us in Europe can't make it to San Francisco, so Antwerp based Devoxx is a more convenient and less expensive alternative. This is just a summary of the presentations I happened to attend.

On day 1 we got started with a demonstration from a talented Belgian beatboxer.

The first keynote was from Danny Coward of Sun who gave a talk on the just released JavaFx 1.0. This is an API set for building RIA (rich internet applications). He demonstrated some really cool graphics.

The second part of the keynote was from IBM giving an overview of RFID technology and then describing an RFID based conference information system. Each DEVOXX attendee had a RFID tag attached to their name badge which was scanned on entry to each room. The application could then provide details such as pie charts showing each room attendance statistics.

Giovanni Asproni gave a talk on Software Estimation. There are three independent aspects: estimates, targets and commitments. Estimates are frequently misinterpreted as targets or commitments.

Sebastien DeerSnyder gave a talk on hacking and securing Java Web Applications. He described 2 hacking techniques: Javascript injection and SQL injection. He also talked about the OWASP (open web application security) project.

Mike Keith outlined the numerous new features in JPA 2.0. I won't list them all here, but the greatest additional functionality is the Expression and Criteria API. This allows queries to be dynamically created rather than being expressed as Strings. This feature is really needed in applications which build up a query in response to a series of user selections from a GUI client.

JPA 2.0 is being shipped out with GlassFish v3 which includes the EclipseLink JPA 2.0 reference

implementation persistence engine. I hope to download GlassFish v3 soon and I plan to blog about my experiences in the New Year.

I attended Pete Muir's Introduction to Web Beans. Web Beans in particular unifies JSF managed beans with EJBs and is a part of the forthcoming Java EE 6 standard.

I was still suffering from the tail end of a cold so I managed only one beer in the evening's free bar.

On day 2 there was no beatboxer to wake us up but Josh Bloch's keynote Effective Java Reloaded had us flexing our PECS instead. Josh has produced a second edition of his book to cover Java SE 5 and 6 features. In particular Josh described some generics, enumerated types and lazy initialization examples. The generics example dealt with using wildcard types as input parameters. If a parameterized type serves as an E producer, use <? extends E>. If a parameterized type serves as an E consumer, use <? super E>. So the PECS mnemonic stands for producer-extends, consumer-super. Hence the PECS flexing bit.

The second keynote was by Mark Reinhold from Sun on the forthcoming Java SE 7 (expected early 2010). His main point was how large Java had become with the JRE being 14MB and a helloWorld program requiring 332 classes to execute. So a major effort will be on modularizing the platform and packaging Java into a number of profiles. Up to now Java has always being upward compatible but Mark did warn that from Java SE 8 onwards this may no longer be the case.

Ivar Jacobson gave an excellent, entertaining account of good software building practice in his Be Smart presentation. According to Ivar we are always looking for silver bullets for building software, but there are no silver bullets to be found. By focusing too much on process we are forgetting how to be smart in creating software. Ivar then covered smart practices in a number of aspects of the software lifecycle.

Mark Little gave a talk on the JBOSS SOA platform. Mark managed to provide the details of JBOSS's offerings while at the same time giving a good introduction to SOA concepts.

Roberto Chinnici, the JSR 313 co spec lead, gave a Java EE 6 overview. The spec is currently under draft public review and is likely to be finalized around May next year.

Java EE 6 is an umbrella spec consisting of individual JSRs such as JSR 318 (EJB 3.1), JSR 317 (JPA 2.0), JSR 315 (Servlet 3.0), JSR 311 (JAX-RS), JSR 314 ( JavaServer Faces 2.0). Java EE has grown to be a huge specification and Java EE 6 tackles this by packaging Java EE into profiles according to use. The plan is to offer somewhere between 2 and 5 profiles, much more than that is too unwieldy. So the Web Profile is provided for web-based applications. The web profile most likely would include Servlet 3.0 and JSP but not JAX-WS, JAX-RS, and JAXB. What exactly is to be included and excluded from the profiles is still up for discussion however. A basic and an intermediate web profile are also on the table.

JSR 311 co spec lead Paul Sandoz gave a talk on JAX-RS. This is the Java API for RESTful (Representational State Transfer) Web Services. REST web services are being increasingly used as an alternative to SOAP based web services, so this is a technology I need to familiarize myself with in the near future.

Devoxx provided a movie in the evening, The Day the Earth Stood Still. This was coinciding with film's general release in Europe so I hadn't previously seen it. As one of the first 500 delegates I got a large bag of popcorn to keep me going through the film.

On day 3 there was no keynote just presentations as the conference finished at 12.30. Simone Brunozzi gave a talk on Amazon Web Services. Cloud Computing enables one to increase and shrink computing resources according to demand. This is a pay per use model. Simone then described Amazon's offering in this area.

I went to Adam Bien's presentation titled "EJB 3.1 From Legacy to Secret Weapon". Adam pointed out that while EJB 2.x was a rather heavyweight model and so not very cool, EJB 3.x is much more lightweight and so is really cool. With EJB 3.x the use of annotations nearly eliminates the need for verbose xml descriptor files which are still the hallmark of other frameworks. With EJB 3.x you also avoid the JAR file proliferation typical in other frameworks. Last but not least EJB 3.x is a specification and not a product, so the user can choose between competitive implementations of the EJB 3.x spec. EJB 3.x is also lightweight in terms of performance. Adam gave some timing comparisons between POJOs and their corresponding EJBs: the overhead was only a few percent. Adam then went through some of the new 3.1 features such as Session Bean optional interfaces, Singleton Beans, Calendar based EJB Timer expressions, Asynchronous session beans, packaging EJB components in a .war without an ejb-jar, and standardized Global JNDI naming. The last item was proposed by Adam himself and is really needed as any developer who has to deploy his applications to multiple application servers will appreciate. EJB 3.1 also gives the option of a Java SE application to instantiate an EJB container; in particular this should make testing easier. EJB 3.1 also provides a subset, EJB Lite, which a provider may choose to implement rather than the full EJB 3.1 set. EJB Lite dispenses with Session Bean remote interfaces, asynchronous invocation of Session Beans, Message Driven Beans and the Timer Service. EJB 3.1 is at the public draft stage and should be final in synch with Java EE 6 around next May. GlassFish v3 is the reference implementation. So in the New Year I plan to download GlassFish and blog about my EJB 3.1 experience.

Off to Devoxx

I'm going to Antwerp, Belgium to Devoxx 2008 next week. Formely known as Javapolis this is the largest European Java conference. I'm particularly interested in the EJB 3.1, JPA 2.0 and Java EE 6 presentations. I'll give a summary when I get back.

Weblogic 10.3 Example Source Code

The Weblogic 10.3 version of the examples source code is now available on the book's web site.

www.packtpub.com/developer-guide-for-ejb3/book

I'm thinking of producing a JBoss version as well, but I'm not sure of the timescales at the moment.

Converting to Weblogic 10.3 - EJB3 Security

In this post I describe the conversion of examples of chapter 12, which deals with EJB 3 Security, from Glassfish to Weblogic 10.3. No source code changes were required, only deployment and configuration of users and assigned roles was different.

In Glassfish we used the asadmin utility to create a user and associated role as a task in the build.xml file as follows:

<target name="create-file-user">

<exec executable="${glassfish.home}/bin/asadmin"

failonerror="true"

vmlauncher="false">

<arg line="create-file-user --user admin --passwordfile userpassword --groups bankemployee scott"/>

</exec>

</target>

In Weblogic users and corresponding passwords were created using the administrator console. If an ejb is invoked by a Java client, users cannot be assigned to a role or roles in the administrator console. Instead user/role assignment is done at deployment. We need to create the weblogic-ejb-jar.xml file as follows:

<security-role-assignment>

<role-name>bankemployee</role-name>

<principal-name>scott</principal-name>

</security-role-assignment>

<security-role-assignment>

<role-name>bankcustomer</role-name>

<principal-name>ramon</principal-name>

</security-role-assignment>

</weblogic-ejb-jar>

 

In the wldeploy ant task we need to add the line securityModel="DDOnly" to indicate security role assignment is done at deployment:

<wldeploy

user="${admin.username}"

password="${admin.password}"

adminurl="t3://${weblogic.hostname}:${weblogic.port}"

securityModel="DDOnly"

debug="true"

action="deploy"

name="BankService"

source="${build.dir}/BankService.ear"

failonerror="${failondeploy}"/>

Rather than use a JAAS login which would entail creating additional source code such as a CallBackHandler, JNDI login was used instead. This entailed creating a jndi.properties file for each user with the username and password included. So for user scott the corresponding jndi.properties file is:

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory

java.naming.provider.url=t3://localhost:7001

java.naming.security.principal=scott

java.naming.security.credentials=xyz12345

In lab4 we invoke an ejb from a servlet so we use web-tier authentication. In this case we can specify user/role assignments in the administrator console. Then we need to set the Security Model default flag in the administrator console as follows:

Select security realm in navigation pane, then select myrealm (this is the default realm). For the "Security Model default" select "Custom Roles and Policies" from drop down list.

This is the last in the migrating EJB3 to Weblogic 10.3 series. All the source code should shortly be available for download from the book's website.

Converting to Weblogic 10.3 - EJB3 WebSevices

In this post I describe the conversion of examples of chapter 11, which deals with EJB 3 Web Services, from Glassfish to Weblogic 10.3. Apart from one minor exception described below no source code changes were required. The only modifications required were to the application server specific ant tasks which generate various web service artifacts. These ant tasks were all defined in the build.xml file.

The equivalent of the Glassfish wsgen tool in Weblogic is the jwsc ant task. jwsc takes as input a Java class file with embedded web service annotations and generates all the artifacts required to create a web service. In Glassfish explicit use of wsgen is optional as web service artifacts are generated as deployment time if they have not already been created by wsgen. In Weblogic we do need to explicitly invoke jwsc before deployment.

The wsdl file created by jwsc creates a "REPLACE_WITH_ACTUAL_URL" placeholder for the web service URL. Consequently we need to edit the wsdl file and specify the actual URL. For example in lab1 we must edit the build\webservice\ArithmeticService.wsdl file from:

<service name="ArithmeticService">

<port name="ArithmeticPort" binding="tns:ArithmeticPortBinding">

<soap:address location="REPLACE_WITH_ACTUAL_URL"/>

</port>

</service>

to:

<service name="ArithmeticService">

<port name="ArithmeticPort" binding="tns:ArithmeticPortBinding">

<soap:address location="http://localhost:7001/Arithmetic/Arithmetic"/>

</port>

</service>

The equivalent of the Glassfish wsimport tool in Weblogic is the clientgen ant task. clientgen generates from an existing wsdl file the client artifacts that client applications use to invoke Weblogic and non-Weblogic web services.

In Weblogic we cannot use @WebServiceRef annotation to define a reference to a Web Service from a stand-alone Java client. In Weblogic @WebServiceRef is only used to invoke a web service from another web service. Consequently in lab1 the source code for WebServiceClient was changed from

public class WebServiceClient {

@WebServiceRef(wsdlLocation="http://localhost:8080/arithmetic-webservice/ArithmeticService?WSDL")

static ArithmeticService service;

public static void main(String[] args) {

try {

   ...

to

public class WebServiceClient {

public static void main(String[] args) {

try {

ArithmeticService service = new ArithmeticService();

   ...

It was not possible to have a Weblogic version of lab2. The glassfish version of lab2 has a MathematicsImpl implementation of the Mathematics interface:

@WebService(endpointInterface = "endpoint.Mathematics")

public class MathematicsImpl implements Mathematics {

   ...

We use the endpointInterface attribute to specify the interface. However in Weblogic we use the endpointInterface attribute to specify the service endpoint interface generated by the wsdlc ant task. The wsdlc ant task takes as input wsdl file and generates web service artifacts including the Java service endpoint interface (this is known as the top-down approach) .

In the next post I'll describe the conversion of chapter 12 examples which demonstrate EJB 3 security.

.