Interview with Mark Hapner

转载 2006年06月14日 13:25:00

 Distinguished Engineer, J2EE architect, Sun Microsystems, Inc.

Topic:Whats new in J2EE 1.4 Date: May 2003

Mark Hapner is the specification lead for J2EE 1.4 and is also Sun's representative to the Web Services Interoperability Organization. In short, he is one of the key individuals at Sun driving J2EE's technical direction. Mark joined Sun's Java Software Division in 1996 to participate in the development of the JDBC API. Following that, he co-authored the Enterprise JavaBeans specification and authored the Java Message Service specification. In this Hard Core Tech Talk, Floyd Marinescu of TheServerSide.com interviews Mark about whats new in J2EE 1.4, technical issues surrounding the platform, and future directions.


Floyd: What are some key new features of J2EE 1.4?

Mark: Highlights are rich Web services support integrated with Servlets and EJBs, an enhanced version of the Connector architecture that provides sophisticated bidirectional integration with external systems; standard J2EE Management and Deployment functionality; Java Server Pages fragments and standard expression language; and, a new standard for extending J2EE containers with a pluggable authorization facility.


Floyd: It looks like there are a lot of additions to J2EE 1.4, will there be a steep learning curve for developers? Will vendors come out with 1.4 compliant servers quickly?

Mark: The short answer to the first part of your question is no. And here's why. The primary 1.4 technology that impacts developers is Web services. Developers are already gaining experience with this using the Java Web services Developer Pack and with J2EE products that included initial support for Web services. I expect developers to quickly pick up on 1.4's Web service support since it leverages their existing knowledge of Servlets and EJBs.

A majority of 1.4's functionality - Connectors, Deployment, Management, Authorization - provide a more seamless integration of J2EE containers in an enterprise's computing environment. Developers indirectly benefit from this better integration but it does not complicate their world with a raft of new APIs to learn.

Re the second part of your question, I can't speak for J2EE vendors plans for 1.4 products; however, given the customer demand for Web service standards, I expect that vendors will be competing vigorously to deliver 1.4 products.


Floyd: You mentioned that the Connector Architecture is now 2-way. Can you tell us more about that?

Mark: The Connector that is part of J2EE 1.3 allows an external system to become a J2EE resource that can be called by J2EE components. This has been enhanced in 1.4 to support external systems that asynchronously deliver events, notifications and other forms of messages directly from the external system to a Message Driven Bean component.

One part of this enhanced Connector is a work management facility supplied by all J2EE 1.4 containers that minimizes the work needed to implement an asynchronous Connector and insures its workload is properly managed by the container.


Floyd: EJB 2.1 Message Driven Beans coupled with a Resource Adapter could open up a whole new category of EAI functionality. Can you comment on what new use cases and functionality are open to J2EE developers as a result of this combination?

Mark: EJB 2.1 MDBs together with the Connector provide a standard way to integrate a broad range of external event handling, notification processing and general message server facilities into J2EE applications. Applications just see all these as sources of different message objects. This allows developers to apply the MDB model they are already familiar with for JMS message processing to an open-ended set of external message sources. These could be notifications from ERP systems, special forms of email connectors, etc.


Floyd: How would a developer decide between an EJB or a servlet to implement a WS?

Mark: Since both servlets and EJBs support the full capabilities of JAX-RPC for implementing Web services, a developer would select between them based on their basic component approaches. Those that desire a more formal business component with declarative transaction support and method level authorization would select EJBs. Those that like a less formal, HTTP request handler style would use Servlets. In 1.4, both make it easy to implement a Web service.


Floyd: Adding Web services over servlets essentially adds remoteability to servlet code. Some have said that this could reduce the EJB value proposition. What is your take on this?

Mark: EJBs' primary value is its support for a more formal business component for partitioning business logic; Container Managed Persistence that simplifies the development of persistent domain models; and, its support for messaging driven services via MDBs. In addition, EJB will continue to provide support for RMI-IIOP distributed programming for those apps that need the more closely coupled model it supports. You could look at this the other way around, EJB is now directly supporting what used to require a servlet.


Floyd: When writing servlet/EJB Web services, do you need to code WS semantics into your code?

Mark: J2EE and JAX-RPC allow developers to use the full functionality of Web services. They do this in a way that is natural for Java and J2EE developers and that hides the complexity of WSDL, Soap, XML, UDDI, etc.

J2EE 1.4 also gives developers full control over the Java/WS mapping if they desire. Most developers don't need this level of control; however, it comes in handy when maintaining existing J2EE Web services as they evolve to cope with changing internal and external requirements.

J2EE 1.4 also provides support for developing clients that dynamically integrate with new Web services via the JAX-RPC Dynamic Invocation Interface (DII).


Floyd: What use cases would require the use of the JAX-RPC Dynamic Invocation Interface (DII)?

Mark: One use case would be a specialized app that generically exercises a port, possibly to check its availability or performance. Most J2EE apps will be written to a specific WSDL port type so only more specialized apps will use this feature. It's just good to know it's there if it's needed.


Floyd: Do the new Web services features make the J2EE platform up-to-date with .NET's Web services support?

Mark: Floyd, many J2EE vendors have been shipping production support for Web services for over a year. The JAX-RPC technology has been a Java Standard since June of last year. So, the Java Community is not having a problem 'keeping up' with Microsoft. J2EE 1.4 is the first release of J2EE since JAX-RPC has been available so it is the community's first opportunity to make it a required part of J2EE; however, J2EE developers are deploying Web services now with J2EE 1.3 and JAX-RPC.

Both J2EE and .Net are focused on the same application space - Web site and Web service applications. Each is delivering support for the evolving set of standards that allow these applications to interoperate. The standards themselves are no longer a point of competition. J2EE 1.4 delivers comprehensive support for Soap 1.1 and WSDL 1.1 and has tightly integrated them with the existing servlet and EJB component models. J2EE will continue to focus on complete, interoperable support for Web standards. The Java/ J2EE community has and is making a major contribution to these standards and views them as central to the future of application development.

The primary difference between J2EE 1.4 and .Net is that the Web sites and Web services implemented with .Net only run on Windows while the Java/J2EE community has created a fully open/portable application stack. This includes competition at the JVM level; competition at the application server level; competition at the tools level; and most importantly, delivers full machine architecture and OS independence. MS could have done the same if they had really wanted to compete with Java/J2EE. Instead they have taken a path with .Net that has locked its developers into Windows and prevented their huge investment in training and tools from being used on other platforms.

The world of the Web is bigger than Windows. Whether it is J2EE, PHP, Perl or other open approaches to developing Web applications, developers are demanding technologies that give them the freedom to apply their knowledge broadly across computing environments. If MS had not embraced Web services and a VM-based stack they would have lost their developers. Now that .Net has begun to deliver this functionality they are hoping that developers won't notice that this is yet another proprietary MS stack with a veneer of Web service interoperability.


Floyd: How does J2EE 1.4's recent decision to require support for the WS-I Basic Profile 1.0 affect developers?

Mark: First, this is a major commitment by the J2EE vendor community to deliver support for WS-I BP 1.0. This is proof that the J2EE community takes Web service interoperability very seriously.

To J2EE developers, this means that, by default, the J2EE 1.4 Web service clients and Web service endpoints they build will conform to BP 1.0. This should take the guess work out of actually getting Web services to talk to each other. Currently, developers who attempt to design more sophisticated Web services based on XML Schema are taking a risk because support and interoperability for this is spotty. Since BP 1.0 includes strong support for XML Schema, developers can be more confident that these more complex services will work and interoperate.

J2EE 1.4 also contains Web service support for functionality that is outside BP 1.0, such as the Soap Encoding binding. These non BP 1.0 compliant features will still be supported; however, the J2EE 1.4 defaults will be changed to align with BP 1.0.

The J2EE Community clearly felt that it was worth a few months wait to include this extra measure of interoperability in 1.4. Sun expects to have the final version of the J2EE 1.4 platform available this summer with J2EE 1.4 products coming soon after.


Floyd: When is it appropriate to use traditional J2EE facilities (JCA, JMS, RMI-IIOP) for integration between systems, as opposed to Web services?

Mark: Each form of integration has its strong points so it is difficult to describe in a few sentences when to use each. Broadly, Web services should be used when maximum interoperability is desired; J2EE Connectors (JCA is the Java Crytography API) should be used when closely coupled integration with an external system is needed; RMI-IIOP should be used when a rich object oriented distributed object model is needed; and JMS should be used when a reliable, store-and-forward, publish/subscribe messaging system is needed to integrate asynchronous services.

I expect that many applications will use combinations of these integration technologies. For instance, many Web services will be implemented as J2EE applications that are business logic tiers that use a Connector to access an existing ERP, CRM, etc. system.


Floyd: What plans does Sun have to integrate J2EE security and transaction with Web services?

Mark: For true interoperability, both security and transactions require full specification of descriptions that augment WSDL so that developers can express in an interoperable way what security and transaction functionality is needed to access a Web service. Once this model is in place, J2EE will support it. The goal is definitely to have the J2EE container do as much of this work for the developer/deployer as possible.

In the short term, J2EE vendors will likely provide vendor specific 'helper' APIs that allow developers to insert security and transaction headers into Soap messages and to support their use on the server side.


Floyd: The new JSP 2.0 spec now had three ways to implement custom tags. Can you describe these and explain in what scenario each option is most appropriate?

Mark: The full JSP tag extension facility is very powerful but is also fairly complicated. You need to have a fairly deep understanding of its facilities to implement a tag. A new Simple Tag Extension facility is provided in JSP 2.0 that supports a simpler subset of tag extension and provides a way to implement these with both Java classes and directly with JSP itself. This allows both JSP page developers and more casual Java developers to tap into the power of custom tags.

There is quite a bit of overlap between these two forms of tag extension facilities. The short answer to which a developer should use and when is that most tags that don't have bodies containing scriptlets should be implemented with simple tag extentions. Whether a simple tag should be implemented with Java or JSP depends on the developer's skills and the complexity of the tag's function.


Floyd: You mentioned the new "fragments" in JSP 2.0. How does this differ from doing a <jsp:include>?

Mark: Currently, Java developers can extend JSP with custom tag libraries while JSP developers were limited to using jsp:include to replicate some common lines of JSP. In 1.4, JSP fragments allow JSP developers to write their own JSP tags in JSP.


Floyd: I thought tag files allow JSP developers to write tags in JSP, not fragments. What exactly is a fragment?

Mark:Fragments allow a JSP developer to create a parameterized set of JSP actions and invoke these using a parameter list. Includes could only be reused for a fixed set of JSP actions.


Floyd: What effect do you see the deployment and management API's having on the tools market?

Mark: The deployment API makes it easier to integrate IDE tools with J2EE containers so it will generally help a broader range of tools and containers provide a better IDE experience for developers. It will also help reduce the work current tools vendors put into basic container integration so they can free up a bit of resources for more advanced J2EE support.

The Management API standardizes the way management consoles interact with J2EE containers. This minimizes the work needed to make a management console J2EE container-aware. This, in turn, minimizes the impact of adding a J2EE container to an existing computing environment because the environment already knows how to manage it.


Floyd: What are some of the things that developers will be able to do in managing a server?

Mark: Actually the question should be slightly different since developers don't manage app servers - operations staff manage app servers via management consoles. The J2EE 1.4 Management standard provides a CIM model of Managed Objects that describes the server itself and the J2EE apps that are running on the server. It leverages the JMX management standard. Its primary purpose is for integrating J2EE containers with management consoles; however, J2EE apps can access a container's managed objects via a set of standard Management EJBs (MEJBs) provided by all 1.4 containers.

What operations staff will be able to do is to see what apps are running; what transactions are active, what resources are configured, etc. They do this now via app server specific consoles. The benefit of the management API is that now commercial management consoles will be able to provide an extension for J2EE app servers that leverages this standard management model so that the impact of adding a J2EE server to the mix of servers in an enterprise is reduced.


Floyd: Is Java Server Faces included in 1.4?

Mark: Java Server Faces can be used with J2EE 1.4 but is not included in 1.4 because its schedule didn't line up with 1.4's schedule. . It may become part of J2EE in the future


Floyd: Are deployment descriptors(DDs) migrated into XML schema's from dtd's? What benefits has schema given you, in the world of deployment descriptors?

Mark: The new 1.4 DDs leverage XML Schema and Namespaces to provide better support for extensibility; more complete validation; better sharing of common elements; and capture richer semantics. These are just the normal benefits you would expect when converting any DTD schema to a thoughtfully designed XML Schema.


Floyd: JDO isn't in J2EE 1.4. Where do you see that specification fitting into Sun's platform? Will is appear in 1.5 or later?

Mark: JDO is a Java technology that is independent of J2EE. There are no current plans to include it as a required part of J2EE; however, there may be J2EE vendors that provide support for it.


Floyd: Has there been any movement for J2EE 1.4 or 1.5 on adding JavaDoc-style attributes to methods (ala BEA WebLogic Workshop's .JWS file paradigm, or XDoclet), thus eliminating the need for external deployment descriptors?

Mark: The job of the JCP-developed JSR 175 - A Metadata Facility for the Java Programming Language - is to standardize a Java attributes facility. J2EE will certainly leverage Java attributes to allow much of what is in J2EE deployment descriptors to be included in the Java source for a J2EE component. Since work on JSR 175 has just recently begun, the timing of J2EE's use of its work has not been determined.

It is likely that in simple cases, use of Java attributes will replace deployment descriptors; however, for advanced cases, they likely will still be needed. It is important, for instance, that deployers be allowed to customize a J2EE app's security without having to change its source code so keeping this security information in a deployment descriptor is an important benefit.


Floyd: What are some of the current thoughts on competing with the productivity of writing ASP.NET Web services? (which even without an IDE have significantly less code and don't require separate configuration compared to the current versions of JAX-RPC or JAXM -- both of which require their own deployment descriptors for each service)

Mark: JCP-developed JSR 181 - Web services Metadata for the Java Platform - is focused on providing a higher level model for developing Web services similar to what is now provided by BEA Workshop. There are also other J2EE tools vendors who are adding enhanced Web service support. Ease of development is important and the J2EE community will meet .Net's challenge.


Floyd: When will JMS and JAXM converge?

Mark: JMS is an API for integrating with MOM systems with J2EE. It is likely that MOM vendors will enhance their facilities to carry Soap messages in addition to their existing message types. There will likely be an enhanced version of JMS that includes more explicit support for Soap messages and XML to support this.

JAXM is an API for integrating Soap message brokers with J2EE. It does nothing but SOAP and requires no functionality beyond Soap. It allows products that only support reliable store-and-forward of Soap messages to be integrated with J2EE. The fact that MOM and Soap message broker products may overlap to some degree does cause some confusion; however, it would not be practical to force Soap message broker products to implement the full set of JMS functionality just so they could integrate with J2EE.


Floyd: Will JAX-RPC be extended to be able to call asynchronous Web services? It currently only allows a J2EE client/server to invoke a synchronous RPC.

Mark: JAX-RPC will likely be extended to support calling all forms of Web services defined by Soap and WSDL. Currently, neither of these define an 'asynchronous' form of Web service. When they do, it will.


Floyd: Can JAX-RPC be used to talk to non-SOAP based Web services? If not, are there any plans to support this?

Mark: If the question is 'Will JAX-RPC define some form of JAX-RPC specific protocol or will it define an RMI-IIOP binding?' then the answer is that it could but there are no specific plans to do so. Currently, it seems the Web service community is more focused on interoperability than it is on the efficiency of the protocol.


Floyd: How closely related is the J2EE Application Verification Program to server compatibility program? Will a 1.4 version of the AVK be coming soon?

Mark: The J2EE CTS and AVK test the two 'ends' of the platform. The CTS tests the J2EE 'socket' (appserver) to insure it delivers high quality power and the AVK tests the appliance (J2EE app) to insure it will run correctly on that power. Think of the AVK as the J2EE equivalent of UL certification. The 1.4 version of the AVK should be available soon after the J2EE 1.4 platform ships.


Floyd: I've heard that the Sun ONE AppServer is now sharing part of its codebase with the J2EE RI. Will this improve Sun's time-to-market for delivering Sun ONE over its competitors?

Mark: Since the J2EE RI code is available to all J2EE licensees, it doesn't necessarily give the Sun ONE App Server an advantage over their products.


Floyd: Now that we have XA transactions, nested transactions aren't that far out? Are there plans to support nested transactions?

Mark: Support for XA nested transactions is not currently planned; however, once it is actually supported by the major transactional systems it is likely that the JTA/JTS specs will be enhanced to support it.


Floyd: When can we see a series of security API rich enough to enable universal single sign-on (user identity defines security rights in the web web, ejb, database, etc)? Why not just borrow it from Corba instead of waiting for Web services to reinvent it?

Mark: J2EE is laying the groundwork for single sign-on by providing the J2EE Authorization API in J2EE 1.4 and the newly filed JSR for Authentication - JSR 196. Together, these provide a standard way for integrating the security provided by an app server with the existing security infrastructure of an organization.

The Liberty technology is another critical piece that insures an open technology for federating network identity.

These steps plus the work of the WS-Security WG, XKMS, SAML, DSIG etc to standardize the 'plumbing' of web security are likely the industries best chance of achieving true single sign-on.


Floyd: The new J2EE 1.4 sample application from the blueprints team is the Adventure Builder, not the J2EE Petstore. Further, the AE has chosen not to use EJBs in its implementation. What are your thoughts on the new application. Does this reflect a change in Sun's stance on the applicability of EJB?

Mark: The new app is one of several apps that the Blueprints uses to teach development techniques. Not all J2EE apps use EJBs. The Blueprints need to show examples of web sites developed with and without EJBs. The Blueprints will also include apps that highlight the use of EJBs.


Floyd: I've noticed a trend in JMS 1.1 and JSP 2.0 where API's have been re-factored or new API's have been introduced to make common development tasks simpler. This sets a precedent - changing a spec to make things simpler. Given all the recent complaints about EJB complexity, what do you think about applying a similar philosophy to EJB?

Mark: The J2EE community is continuing to look at how to simplify development and improve developer productivity. EJBs support for Web services via JAX-RPC has taken some steps in this direction. It is also likely that future versions of EJB will use the Java attribute facility provided by JSR 175 to simplify both EJB code and deployment descriptors.


Floyd: Why was the requirement to support standard deployment (JSR 88) dropped? This (along with management) seemed to be a key benefit of the 1.4.

Mark: There's a bit of a misunderstanding here.

JSR-88 specifies requirements for a tool that manages the deployment process and supports plugin components that handle the app server specific aspects of the deployment process. The tool is typically provided by a tool vendor and the plugin components are typically provided by the app server vendor.

What we removed recently in 1.4 is the requirement for the app server vendor to supply a tool that meets the JSR-88 requirements. The app server vendor is still required to supply the plugin components that work in a JSR-88 deployment tool.

App server vendors already had deployment tools that were customized to work with their app server. While they saw some advantage in providing plugin components that could work in tools supplied by others, they didn't see the strong need to supply such tools themselves. They certainly didn't expect someone to use their tools to deploy to other's app servers.

The major advantages of JSR-88 seemed to be in enabling independent tool vendors to supply tools that would deploy applications to any J2EE 1.4 app server, and to allow an enterprise to develop its own in-house tools that would support deployment to the app servers used in the enterprise.


Floyd: Any final thoughts you'd like to leave us with?

Mark: The scope of J2EE 1.4 was recently expanded to include support for WS-I Basic Profile 1.0. This is not just a press release: it is a solid commitment by J2EE vendors to deliver Web service interoperability. Developer's are demanding a Web service platform that doesn't lock them into a specific hardware, OS or app server vendor; and, that fully supports Web service standards. J2EE 1.4 delivers on all counts.

经典算法题目:Cracking the coding interview 问题与解答

Cracking the coding interview--问题与解答 March 14, 2013 作者:Hawstein 出处:http://hawstein.com/posts/ctci-...
  • wangbaochu
  • wangbaochu
  • 2016年10月31日 00:39
  • 1541

cracking the coding interview 中文版 (程序员面试金典)

转自:CTCI面试系列——谷歌面试官经典作品 | 快课网 谷歌面试官经典作品(CTCI)目录 1.1 判断一个字符串中的字符是否唯一 1.2 字符串翻转 1.3 去除字符串中重复字符 1.8 利用已知...
  • a327369238
  • a327369238
  • 2016年10月09日 20:16
  • 879

cracking the coding interview 中文版 (程序员面试金典)

 转自:CTCI面试系列——谷歌面试官经典作品 | 快课网 谷歌面试官经典作品(CTCI)目录 1.1 判断一个字符串中的字符是否唯一 1.2 字符串翻转 1.3 去除字符串中重复字符 ...
  • hnuzengchao
  • hnuzengchao
  • 2014年10月19日 11:32
  • 23569

think in java interview-高级开发人员面试宝典(二)

从现在开始,以样题的方式一一例出各种面试题以及点评,考虑到我在前文中说的,对于一些大型的外资型公司,你将会面临全程英语面试,因此我在文章中也会出现许多全英语样题。这些题目来自于各个真实的公司,公司名我...
  • lifetragedy
  • lifetragedy
  • 2013年08月05日 00:43
  • 39563

think in java interview-高级开发人员面试宝典(一)

无论你是在职,非在职,高级工程师,工程师,架构师,如果你正在面试阶段,请看完此文,相信这篇文章对你的职业生涯和阶值观会发生重大的改变。如果你是一名PM或者是管理者正在物色合适的开发人选,那么我相信这篇...
  • lifetragedy
  • lifetragedy
  • 2013年08月04日 22:44
  • 26199

think in java interview-高级开发人员面试宝典(六)

原文地址:http://blog.csdn.net/lifetragedy/article/details/9935699 写了这么多Java基础,来点SQL吧! 一般面试时考...
  • zheng0518
  • zheng0518
  • 2017年02月07日 14:32
  • 539

关于IPTABLES 各种MARK 功能的用法

1、 iptalbes 的有多个MARK 模块..用法各不相同..一直没有完全明白..希望高手解释一下各功能的使用及区别.... -m mark -m connmark -j MARK -j CONN...
  • bytxl
  • bytxl
  • 2015年04月03日 15:03
  • 5786

阿里巴巴面试题及答案汇总

本地(带图形环境):jvisualvm 线上(无图形环境):看总内存用top,看详细信息用jmap dump出来分析 Top nmon...
  • zheng0518
  • zheng0518
  • 2014年12月27日 22:51
  • 4577

c 语言的 mark-sweep 实现

原文地址: http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/ 每当我倍感压力以及有很多事情要...
  • yangzm
  • yangzm
  • 2017年04月07日 11:25
  • 316

菜鸟教程之工具使用(十二)——Eclipse突出显示选中的相同变量

大家都知道在Eclipse中,选中一个变量或者方法名(或者说是一个单词),当前文件中跟他一样的变量会被突出显示,这个功能很好用。能让我们很方便的找到该变量在哪被用到了。前段时间我的Eclipse的这个...
  • liushuijinger
  • liushuijinger
  • 2015年02月28日 19:24
  • 1945
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Interview with Mark Hapner
举报原因:
原因补充:

(最多只允许输入30个字)