Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Integrating an ASP.NET Application with J2EE PART 1

Platform interoperability

We all know that the .NET platform offers a great set of tools for building robust Web applications. There are times, however, when as .NET developers we need to understand how we can integrate the great features of .NET with other platforms and technologies. We often find our clients using both .NET and J2EE technologies successfully in their architectures.

I faced a situation such as this recently and I would like to share some of my experiences with you in this two-part article. Part 1 will discuss interoperability between ASP.NET and BEA WebLogic 8.1, and how to use XML Schemas to transfer data between the platforms. Part 2 will discuss how to properly process SOAP Exceptions, the uploading and viewing of binary data, and how we handled page navigation and application workflow. The source code for this article can be found at http://sys-con.com/weblogic/sourcec.cfm.

On a recent project, the client decided that they wanted to use J2EE technology (specifically BEA WebLogic 8.1) to support their core legacy applications. The new Web application would let vendors enter information that would be validated and transferred directly into the core application database. WebLogic would provide the business functionality via Web Services. The client had several applications developed in C# using Visual Studio.NET and wanted to take advantage of the productive features in ASP.NET to develop the presentation layer of the application.

There are various technologies we could use so .NET could communicate with J2EE. The most popular one is XML Web Services. The main benefits of Web Services are the industry support, tool support, and ease of development.

There are also several products such as Ja.NET (http://ja.net.intrinsyc.com/ja.net/info) or Janeva (www.borland.com/janeva) that bridge .NET and J2EE environments to allow binary communications and share native data types and stateful communication. These products bridge .NET and J2EE by configuring .NET Remoting to behave like a Java RMI/Corba client or server. Bridging .NET and J2EE provides more robust functionality and performs better than XML Web Services. The big drawbacks in using a bridging technology are the complexities of learning and configuring the bridging product and the cost of licensing it. We decided to use XML Web Services because the web application didn't need stateful communication and speed wasn't as high a priority as development time and cost.

The solution was to use ASP.NET Web Forms in the presentation layer communicating with Web Services hosted on WebLogic, which would provide the business services and data persistence. The presentation tier would display, capture, and perform simple domain validations on the data. The business tier would apply the business rules and the data tier would persist data to a SQL Server database. The ASP.NET Web Forms would communicate with the WebLogic business layer using WebLogic Web Services.

WebLogic Web Services are built using the WebLogic Web Services toolkit. It lets you expose a Java object as a Web Service without additional coding. WebLogic Web Services support the following components as the source of a Web Service:

  • A method of a stateless session Enterprise Java Bean (EJB)
  • A method of a Java class
  • A JMS message consumer or producer
BEA recommends that you implement your Web Service operation with only a stateless-session EJB or a Java class, and not with a JMS consumer or producer.

In our application, we used stateless session beans as a facade to the business logic and data persistence logic. The pattern we followed is the Session Facade pattern, which provides a single interface for application functionality and allows for course-grained access to business objects. You can find more information on the facade pattern at http://java.sun.com/blueprints/patterns/SessionFacade.html.

We also implemented an intermediate class to act as a business delegate that decouples business components from the code that uses them. Specifically, the business delegate class assisted in implementing exception handling by letting us throw application exceptions from Session EJBs and catch them in the business delegate class that then builds a custom SOAP exception. This is discussed in more detail in the section on SOAP exception handling and you can find more information on the business delegate pattern at http://java.sun.com/blueprints/patterns/BusinessDelegate.html.

Figure 1 shows the overall architecture of our application.

There were several challenges we faced. In this article I'll discuss some of these issues, how we decided to tackle them in our implementation, and our advice to anyone using a similar architecture.

We identified the following issues:

  • We needed to ensure that the Web Services we developed were interoperable between ASP.NET and BEA WebLogic 8.1.
  • We needed to determine the best method to transfer data via Web Services between the platforms.
  • We needed to determine how we were going to do exception handling between the two platforms.
  • We needed to upload and view images that would require the transfer and retrieval of binary information (images) via Web Services.
  • We wanted to devise a plan for handling page navigation and application workflow.
Interoperability between .NET & BEA WebLogic 8.1
The biggest appeal in using XML Web Services is the true interoperability offered between different platforms. To discuss true interoperability, we need to discuss some of the technologies behind Web Services.

The SOAP specification dictates that the contents of a message sent via a Web Service must be XML-formatted, but the specific format used is open to the vendor. The two predominant styles WebLogic supports are RPC-style and document-style. An RPC-style message is one in which the SOAP messages contain parameters and return values. A document-style message is one in which the SOAP messages contain XML documents.

The default style for .NET XML Web Services is document. The default style for the WebLogic Web Services toolkit is RPC (as it is for the Microsoft SOAP Toolkit v2). The preferred style is a source of debate. Many feel that document style is more flexible. Both styles are transparent to an ASP.NET developer since the proxy class generated by wsdl.exe supports both. Since interoperability was the key issue, we chose the RPC style, which has a longer history of support in most toolkits, and also makes the Web Service appear like a local API to the caller. RPC style also let us design Web Services interfaces similar to the standard interfaces we would use in Java or .NET.

There are two styles of encoding native data types in the XML sent as part of a SOAP message - SOAP encoding and literal encoding. SOAP encoding uses the SOAP specification to map native data types to XML. The SOAP specification defines native data types that are supported and you must use one of these data types. Literal encoding uses XML Schema to include a definition for all non-standard data types in the XML message itself. Literal encoding is more flexible in this instance.

RPC-style WebLogic Web Service operations must use SOAP encoding. Document-style WebLogic Web Service operations must use literal encoding. All operations in a single WebLogic Web Service (class) must be either RPC-style or document-style; WebLogic Server doesn't support mixing the two styles in the same implementation. Since we were using an RPC style of Web Service, all the Web Services in WebLogic would use SOAP encoding.

In the WebLogic application, we used built-in data types exclusively to minimize the development effort. Built-in data types are those specified by the JAX-RPC specification. When using built-in data types, WebLogic automatically handles the conversion of the data between its XML and Java representation. If the Web Service uses a non-built-in data type as a parameter or return value, you must create a serialization class to convert the data between Java and XML.

Table 1 lists the built-in data types WebLogic supports.

For the most part, we encountered few incompatibility issues consuming WebLogic 8.1 Web Services in an ASP.NET application. One issue of note is the use of SOAP encoding. While the WS-I Basic Profile 1.0 (BP) requires the RPC style and literal encoding, using RPC style in WebLogic requires SOAP encoding which violates the WS-I Basic Profile 1.0. For more information on the WS-I Basic Profile 1.0, see the sidebar, "WS-I Basic Profile 1.0." We should also note that using WebLogic Web Services, you can't expose static methods as a Web Service; they must be class-level methods.

Transferring Data via Web Services
Since the application needed to call non-.NET Web Services, the mechanism that we used to transfer data couldn't use data types or objects specific to .NET. In previous projects we had passed DataSets through Web Services and bound them to ASP.NET components in our Web applications. Since WebLogic has no concept of a DataSet, we couldn't use this approach. We considered a number of alternatives.

We considered building a mechanism to generate XML that would be identical to the XML generated from a DataSet. This would require generating an XML schema dynamically based on the data being passed and then the generation of XML data based on the dynamic schema. We decided against this solution because we felt it would take a great deal of effort to code and was susceptible to future changes in ADO.NET

Another option was to use value objects to pass the data. Value objects are based on the "Value Object" Pattern and represent simple classes with properties and accessor/mutator (get/set) methods. Value objects are often used in J2EE architectures to pass data between tiers. In this case, a value object or collection of value objects would be instantiated in a WebLogic Web Service and data would be stored in these classes. The data would be received in the ASP.NET application as a proxy object, which is a client representation of the Java classes. The classes must use primitive data types (or other collection objects such as ArrayLists that are recognized by both environments).

We decided against this solution because of the effort involved in parsing the data passed via the proxy objects. Under this approach a .NET developer would need to write code to parse the values from the proxy object and put them in a DataSet. This is relatively simple to code but it's a rather tedious and unnecessary step. The code would also need to change each time the data returned from the Web Service changed.

We wanted to find a solution that would involve minimal coding, use technologies available in both .NET and WebLogic, and would let ASP.NET developers bind objects such as DataGrids or DataLists directly to the data returned from the Web Service (as can be done when passing DataSets from a .NET Web Service).

The solution we decided on was to use XML schemas as the root of our solution. For each result set, we built an XML schema to define the data in the result set. To generate the XML data in the WebLogic environment, we used a product called XMLBeans. XMLBeans is a Java-XML binding tool that lets you to generate Java objects based on an XML schema easily. It generates an object representation of an XML schema in Java classes. BEA uses XMLBeans extensively in WebLogic itself. XMLBeans is an open source product originally developed by BEA and released to the open source community via Apache. You can learn more about XMLBeans at http://dev2dev.bea.com/technologies/xmlbeans/index.jsp and you can download the BEA version at http://workshop.bea.com/xmlbeans/XsdUpload.jsp.

Using XMLBeans, we generated a set of Java classes to contain our data and then used the XMLText method to get an XML document instance based on the object data. We could then pass this XML string via a Web Service to our ASP.NET application.

In the ASP.NET application, a developer could instantiate a DataSet, load in an XML schema to define the structure of the DataSet, and then load the XML document into the DataSet via the LoadXML method. In our example, which is based on the Northwind database, we build a schema to represent a set of client and order data. The ClientOrders.xsd schema is shown in Listing 1. To generate a set of Java objects based on the ClientOrders.xsd schema, you need to download and install the XMLBeans toolkit. As with all Java tools, you need to set the correct location of the Java SDK before running it. If you've installed a Java product (such a JBuilder or WebLogic), an SDK will likely be installed. Listing 2 shows a sample batch file that you can use - you will need to set the "JAVA_HOME" variable to point to your Java SDK location. The sample batch file expects to find the XMLBeans library (xbean.jar) in the default installation location (C:\xmlbeans).

Once you've run the XMLBeans tool, you'll have a .jar file that contains the classes that are the object representation of a ClientOrders.xsd XML schema.

The output should look like this:

C:\xmlbeans\output>scomp ClientOrders.xsd
Loading schema file ClientOrders.xsd
Time to build schema type system: 3.655 seconds
Time to generate code: 12.107 seconds
Compiled types to xmltypes.jar

Rename the xmltypes.jar file to ClientOrders.jar. The Java code sample simply instantiates the Java classes and uses the mutator methods to set sample values based on the Northwind database. In a real-life situation, you'd likely use a Java technology (such as JDBC or EJB) to access the database and get live data. After building the appropriate Java objects, the code calls the XMLText method to get an XML document instance representing the client and order data. The XML document instance can be validated using the ClientOrders.xsd XML schema. We then pass this XML string as the result of the Web Service generateTestData method.

Listing 3 shows the sample Java code to use the ClientOrders.jar to build an XML document instance.

The code for the ASP.NET client page first instantiates a Web Service proxy and makes the call to the WebLogic Web Service.

// Call J2EE web service and obtain xml document
weblogic.BusinessDelegate proxy = new weblogic.BusinessDelegate();

// Obtain XML document instance
string xmlDoc = proxy.generateTestData();

The ASP.NET client page then defines a DataSet, reads the XML into a string, uses the ClientOrders.xsd schema to define the DataSet structure, and loads the DataSet using the XML string passed.

DataSet dsClientOrder = new DataSet();
dsClientOrder.EnforceConstraints = false;
DataTable dataTable = new DataTable();

string schemaRelativePath = "~/Schemas/ClientOrders.xsd";
string schemaFullPath = HttpContext.Current.Server.MapPath(schemaRelativePath);

StringReader stringReader = new StringReader(xmlDoc);
XmlReader xmlReader = new XmlTextReader(stringReader);
dsClientOrder.ReadXml(xmlReader, XmlReadMode.IgnoreSchema);

The ASP.NET client page then binds the DataSet to the dgClients and dgOrders datagrids.

// now bind to DataGrids
dgClients.DataSource = dsClientOrder;
dgClients.DataMember = "ClientOrder";

dgOrders.DataSource = dsClientOrder;
dgOrders.DataMember = "Order";

Figure 2 shows the page after the code has completed.

We got the benefit of XML schema validation on our data, used an object representation of the data in WebLogic, and passed the data to the ASP.NET application in a way that made loading the data into a DataSet straightforward. We could then bind GUI objects such as a DataGrid or DataList directly to the DataSet table. This eliminates the need to parse the data passed by the Web Service. It also provides a flexible architecture in which the changes to the data passed to the ASP.NET application don't require changes to the interface. The data passed isn't validated by an interface, but it is validated via the XML schema.

More Stories By Blair Taylor

Blair Taylor is president of JustWebSolutions.com, a Canadian company specializing in the architecture and development of distributed systems. Blair has authored several publications covering client-server and distributed technologies and is certified in both Java and .NET technologies. Blair can be reached via e-mail at [email protected] or at www.justwebsolutions.com.

Comments (2)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

IoT & Smart Cities Stories
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...