Binod's Blog: J2EE Archives

JSR 289 went final less than a month back. And we have the first implementation of JSR 289 at alpha stage available now. SailFin V1 Alpha has been released. Though a major chunk of JSR 289 is already implemented, it is still not yet compliant with the final release of the specification.

Prasad has written a nice overview of the release. Check it out .

As a round up, here is the journey of SailFin via blogs.

• Sreeram Duvur : Launching Project SailFin more than an year back

• Jan Luehe : Converged HTTP Sessions

• Kshitiz Saxena : Converged Load Balancer

• Yvo Bogers : Application Router

• Vince Kraemer : Netbeans Tooling

• Eltjo Boersma : Configuration

• Yamini : CallFlow

• Bhavani Shankar : Good Application Examples

• Venu : Security/Digest Authentication

• Me : At javaOne

And now, the Alpha has been released. It is likely to be much stabler, given the testing it has undergone already. Give it a whirl and give us feedback

SailFin at JavaOne

Posted by binod on May 06, 2008 at 06:10 PM | Permalink | Comments (0)

Tomorrow (Wednesday) morning at 9.30am, me and Kristoffer talk about SailFin architecture. The Venue is Hall E 134. This session gives the details about the project architecture, features and roadmap. Kristoffer and Ola have another session on Friday at 12.10 about End to End Communication Services with Java ME and Java EE. This is at Esplanade 303.

There is a hands on lab that demonstrates how to develop applications on SailFin. This is at 9.30am on Thursday at Hall E 130/131.

Then there is another hands on lab that shows performance analysis of SIP applications. This is at 1.00pm on Thursday, again at Hall E 130/131.

Many developers and architects from Sun and Ericsson are available in the SailFin booth in the Pavilion. Please do come and meet us!

FInally.... There is a Sun-Ericsson Application Competition that is launched this week. Please participate to win $5000 or a Sony Ericsson Phone.

Locating SIP servers using DNS in SailFin

Posted by binod on February 22, 2008 at 02:58 AM | Permalink | Comments (2)

As per RFC 3263, there are two new kind of records that are important for SIP. They are Naming Authority Pointer (NAPTR) Record and Service Record (SRV). In this example, NAPTR is used as a mechanism to specify the protocol (TCP or UDP) where as SRV records will be used locate the server and port from SailFin.

Example snippet from DNS zone file

_sip._udp.test.com. 3600 IN SRV 10 0 5090 sailfinserver.test.com.
_sip._tcp.test.com. 3600 IN SRV 10 0 5090 sailfinserver.test.com.
_sips._tcp.test.com. 3600 IN SRV 10 0 5061 sailfinserver.test.com.
_sips._udp.test.com. 3600 IN SRV 10 0 5061 sailfinserver.test.com.

;                  order pref flags service      regexp  replacement
test.com. IN NAPTR 0 0 "s" "SIPS+D2T" "" _sips._tcp.test.com.
test.com. IN NAPTR 1 0 "s" "SIP+D2T"  "" _sip._tcp.test.com.
test.com. IN NAPTR 2 0 "s" "SIP+D2U"  "" _sip._udp.test.com.

sailfinserver.test.com. IN A 192.168.1.100

Lets take the NAPTR record shown above, the third column, in these records suggest that the server support TLS over TCP, TCP and UDP protocols and are preferred in that order. Now, if the client support TCP and UDP, then the preference will be given to TCP as that has the lower order compared to UDP.

The SRV records suggest that the port used by the server for TCP and UDB communication is 5090 and not the usual 5060 and the actual server is sailfinserver.test.com.

Finally we have an A record that resolves the sailfinserver.test.com to the computer's IP address.

SailFin uses dnsjava apis for name resolution. It allows the user to configure a JVM option called dns.server for specifying the name server. We could specify that as a jvm-option in domain.xml

If this is not specified, dnsjava also searches /etc/resolve.conf to find the name server. For experimenting that was better for me, as I always have a local name server running in the laptop. (For a moment forget Sip/SailFin, local name server (bind) performs much better for me than BSNL or opendns. That itself is a reason to run a local name server).

Here is my /etc/resolve.conf file content.

nameserver 127.0.0.1
nameserver 218.248.240.208
nameserver 4.2.2.1

Once these are configured, SailFin will be able to resolve the domain "test.com" and find correct SIP server, protocol, port etc. Here is the example of the INVITE message that I tried.

With these settings, SailFin will resolve "To" address to 192.168.1.100:5090 and will use TCP protocol.

GlassFish and Windows Firewall

Posted by binod on December 08, 2006 at 09:57 AM | Permalink | Comments (0)

One of my Sun collegues (Bobby) noticed that glassfish web server stops responding soon after the startup. The most interesting thing he found was that he can access the webserver using http://localhost:8080 where as accessing it using IP address (http://x.x.x.x:8080) wasnt working. The plot thickened when we found that the webserver can be accessed once using the IP address and from second time onwards it started failing. Two web browsers and a wget.exe showed the same behaviour.

Bobby is located in Santa Clara and I am located in Bangalore office of Sun Microsystems. Bobby setup a VNC Server on the laptop during his night so that I can look at whats happening during my day. Global engineering certainly certainly has advantages :-)

Debugging spell was quite longer than usual. Finally, we found that the issue was because of a firewall setting in the norton windows firewall.

As explained here symantec firewall has a setting called "Default Inbound loopback" which is configured to allow only 127.0.0.1. When this configuration is changed to allow any IP address (well bobby was using DHCP) the server started working.

This is not the first firewall related issue glassfish team has faced. Another one is with the Windows java.nio Selector implementation. Windows selector implementation in JDK use a loopback socket to handle the wakeup mechanism. But some firewalls are particularly strict against loopback sockets. Typically the issue will surface with the following stacktrace

java.io.IOException: Unable to establish loopback connection
at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:106)
at java.security.AccessController.doPrivileged(Native Method)
at sun.nio.ch.PipeImpl.(PipeImpl.java:122)
at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:27)

There are so many reports about this issue. Here are some links where people faced it outside glassfish [apache, limeware]

A neat explanation about this issue can be found in this sun forum link on socket programming.

Thats all for today. Now that I have started working from home for 2 days a week, hopefully I will get time to write next blog soon.

Thanks to Bobby for his excellent support on debugging some of these issues.

GlassFish and Windows Firewall

Posted by binod on December 08, 2006 at 09:57 AM | Permalink | Comments (0)

Debugging spell was quite longer than usual. Finally, we found that the issue was because of a firewall setting in the norton windows firewall.

java.io.IOException: Unable to establish loopback connection
at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:106)
at java.security.AccessController.doPrivileged(Native Method)
at sun.nio.ch.PipeImpl.(PipeImpl.java:122)
at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:27)

There are so many reports about this issue. Here are some links where people faced it outside glassfish [apache, limeware]

A neat explanation about this issue can be found in this sun forum link on socket programming.

Thats all for today. Now that I have started working from home for 2 days a week, hopefully I will get time to write next blog soon.

Thanks to Bobby for his excellent support on debugging some of these issues.

Java EE Service Engine: Bridging Java EE and JBI

Posted by binod on July 10, 2006 at 02:20 AM | Permalink | Comments (10)

In a typical Java EE application, MDBs are used to listen to messages from the external systems and act as integration point between two systems. Wouldnt it be good, if that MDB become part of a composite application and thus leverage full capability of JBI also? The example composite application below explains how a BPEL app is accessed from MDB. To keep the things simple (unfortunately composite applications are not simple...) the BPEL sample accesses only a Java EE webservice (SLSB). BPEL is extremely powerful and to know how more about that, read Gopalan's blogs.

Ok, enough of theory, lets get into some action. Below is the architecture diagram of an example application.

As explained in the diagram, the client application sends a message to the Queue which is picked up by the MDB. Upon receiving that message, by using the Java EE Service Engine, the MDB contacts the JBI NMR for the service endpoint exposed by the BPEL process. When MDB executes the BPEL application (hosted by BPEL service engine) BPEL app will contact JBI NMR for finding its partner services. In our BPEL example, there is only one partner service and it is a stateless session bean (JSR 109 webservice) hosted in the same appserver JVM. The JSR 109 webservice's endpoint is enabled in JBI NMR by Java EE Service Engine when the stateless session bean gets deployed. This SLSB uses new Java EE persistence apis to access the database.

In fact, Java EE SDK and Netbeans Enterprise Pack hides many complexities from the developer. Thus a developer's view of the composite application is much simple and as given below. I just hid engines and NMR and made a simpler diagram.

As explained in the diagram above, the MDB just uses JAXWS client apis to access the BPEL process. The BPEL process then invokes the Java EE webservice. The SLSB(Java EE webservice) uses persistence API to access the database. So, a developer just need to code the MDB, the stateless session bean and persistence code and design a BPEL process using these in the BPEL designer.

Now, lets see some real code. To focus on our topic, I am just concentrating on the plumbing part.

Step-1

Develop a SLSB called StockWS. Annotate it with @Webservice to make it a JSR 109 webservice. See the code snippet below.

Deploy the service to the application server (Project GlassFish).

Step-2

Use BPEL designer to design a BPEL app. I am not explaining how exactly this needs to be done. Take a look at this article (its a bit too long) or read gopalan for details.

Basically, you need to import the WSDL of the SLSB webservice to the BPEL application and design the BPEL process using the BPEL designer in the netbeans enterprise pack. At the end of everything, the BPEL app will expose a service as shown below in the WSDL snippet.

Step-3>

Create a composite application project, add the BPEL app to the composite application project and deploy it. These are few clicks in the netbeans enterprise pack.

Step-4
Write the MDB. Import the WSDL of the BPEL application to the MDB as webservice client. The MDB snippet below explains everything.

Step-5
The last part of the story. Normally, the above JAXWS code in MDB will try to access a service using HTTP transport. Here we want the MDB to access the BPEL app in the same JVM. So, tweak the mdb deployment descriptor to route it to JBI.

JMS Pluggability and Generic RA for JMS

Posted by binod on May 26, 2006 at 05:01 AM | Permalink | Comments (2)

Each J2EE application server comes with their own JMS providers. For a developer, it is a good thing. He can write his jms apps and MDBs easily. But a production environment might be quite different. In many cases, people write a new J2EE application and use it with their existing software stack. That means, a lot of time, you will end up in using one J2EE application server and use a JMS provider that is written by some other vendor.

For most simple applications, it is still okay. Most JMS providers give some sort of JNDI capability so that an application can lookup javax.jms.QueueConnectionFactory and javax.jms.Queue objects and send a message.

The trouble comes, when you need to write a true J2EE application, that use container managed transaction and authentication management, that need to be performant (think of connection pools), need inbound communication with MDBs etc. Then add distributed (XA) transactions to the mix. It gets very complicated.

More than an year after we started http://genericjmsra.dev.java.net project, I did a bit of googling about Generic RA for JMS. It seems, many people are able to use different JMS providers with different application servers using this resource adapter.

The resource adapter is now bundled with two application servers. Sun Java System Application server (Project GlassFish) and Borland Application Server. It is also known to work with Websphere Application Server. These links (1 and 2) indicate that someone has got it working with Geronimo also. Hopefully, more application servers will get into the list sooner or later.

Look like jencks folks have got it working with their container. Since jenks is very close to Spring, it also can connect to any JMS provider using the resource adapter.

It has also been found working with the many JMS providers. WebsphereMQ, Tibco EMS, OpenJMS, ActiveMQ, Sun Java System Message Queue and Seebeyond Message Queue are found to be working with one or more application servers. Hopefully someone will try others (FioranoMQ, SonicMQ, JbossMQ, SwiftMQ etc) also soon.

Siva recently gave a community corner talk titled the availabilty features in the genericjmsra at JavaOne 2006. Those slides will be useful for folks who want to use the adapter in production. The other good resource is the user guide.

Lazy Initialization of Application Server Services.

Posted by binod on September 02, 2005 at 10:17 AM | Permalink | Comments (13)

This is my first ever blog. I am basically a developer/engineer by profession (not a writer). So, please don't expect my blogs to be anywhere near an organized reading material.

Lets come to the topic.

I got many e-mails recently, asking me details about a feature called on-demand initialization (or lazy initialization) in Sun Java System Application Server or GlassFish ... and I thought I could use this blog post to explain what it is all about.

What does this feature accomplish?

After this feature is implemented, the actual startup time for Application Server became nearly half of what it was in its previous version. The memory footprint has also reduced a lot. See Peter's blog about his experience

Why was it taking longer to startup earlier?

In my mind, Java EE is a mature and really capable technology for enterprise applications. As an Application Server compliant to Java EE, GlassFish supports many technologies or services specified in the Java EE specification. Lets try to name a few of them... Servlet, JSP, Webservices, EJB, JMS, Connectors, JDBC, JMX, JSF....

Application server, on startup, initialize containers/components that provide these services eagerly and this takes a long time AND lot of memory.

So, what does this new feature do?

Most of the developers are not going to use all the services in the Application Server. I am not talking about those who develop really complex EE applications all the time, but about developers who download the Application Server and just try out a few samples, or folks who learn one or two technologies at a time or even folks who work on small projects that use only some of the technologies from the Java EE stack. This group of developers would not like to incur the overhead of startup-time/memory for all the services they would not use.

Hence now, the Sun Java System Application Server does not start all the containers during startup. In fact when you install Application Server and start it afresh, there will be only a handful essential services initialized, namely a local JNDI provider, JMX connector (for administration).

Now, how would a developer configure the application server to use the
other services?

That is the best part of the feature. User doesn't need to do anything special to initialize the other services that are not started by default. The user uses the application server as he normally would. As and when a service is used, the Application Server will transparently start it.

Here are some details about the implementation.

Mainly there are 3 "entry points" to the Application Server. The entry points are basic functionality in the Application Server that will be used while accessing a user-facing service in Application Server.

1. JNDI Lookup.

Many services and resources in Application Server are looked up using a JNDI name. Examples?
Looking up an EJB, a JDBC resource, a JMS connection factory...

2. Server Ports.

Whenever you do something with the Application Server, a server port is accessed. It can be when you try to see the index.html of the webserver , or connect to the JMS provider from a standalone application, or it can be when you try to lookup a JDBC resource from server's JNDI provider from a standalone Java application.

3. Application Loader.

During the loading of an application,the application Server will read the deployment descriptor of the application for house keeping operations and initialization of the application.

Whenever a user-request reach any of these entry points,the Application Server will identify the type of incoming request and start all relevent services (or service groups) that are required. For example, if the user is accessing http port and if webserver is not started, then the webserver is started lazily/transparently. Or if user is accessing JMS port and JMS provider is not started, Application Server will start the JMS provider. When an ear file containing a EJB is loaded, and ORB is not yet started, Application Server will start ORB.

If you are interested in this feature, the code is available for you to see at GlassFish FishEye page.

If you like to download the latest MSbuild of glassfish, see the link here

For any questions/comments, please use the comments section below or post them at the GlassFish developer's mailing list dev@glassfish.dev.java.net

Powered by
Movable Type 3.01D

java.net RSS Feeds