Welcome!

Java IoT Authors: Yeshim Deniz, Zakia Bouachraoui, Liz McMillan, Elizabeth White, Pat Romanski

Related Topics: Java IoT

Java IoT: Article

SOA Solutions with J2EE

Using different technical and functional requirements

Throughout this article I'll describe how an effective service-oriented architecture (SOA) can be achieved using J2EE technologies. In particular, I'll focus on which J2EE component types and communication channels to choose according to specific, real-world situations.

Description of the Example System
To illustrate an SOA system made of J2EE technologies, nothing is better than a good old example. Figure 1 depicts the main situations that can arise in a realistic SOA system. A component stereotype indicates the type of client or service; a dependency stereotype indicates the communication type, either as a technology (such as Web services) or as a protocol (such as CORBA IIOP); and a no dependency stereotype indicates RMI communication.

The system allows client systems to process an order (service OrderWorkflow), manage customers (service Customer), and produce reports (service Reporting). The OrderWorkflow service checks product availability and retrieves product details (service Product), creates a new customer if needed (service Customer), and orders the selected products (service Order). The Order service persists the order (service OrderData), manages the payment (service Payment), and triggers some process in a legacy system (service BackOfficeOrder).

Service Layers
Services differ according to multiple criteria. Whether the service is business oriented, public or private, or stateful or stateless dictates what layer the service is in and ultimately how it is implemented and what interfaces it exposes.

Top-layer services such as OrderWorkflow are coarse-grained business services, often stateful, that depend on one or more finer-grained stateless business services. Bottom-layer services are fine grained and data oriented, not business oriented.

Services are also separated into public and private services. Public services are services that are available outside of the system, and possibly outside of the organization. They are typically services that have a business meaning. Private services have no business meaning; they exist to support business services and there's no point in making them available to other systems. In Figure 1, public services are colored in blue and private services are not colored.

Although the number of layers of an SOA system is arbitrary, we can categorize them and associate usual J2EE component types to them as shown in Table 1.

Service Communication Interfaces
In SOA systems, service interfaces are even more important than service implementations, because interoperability essentially depends on the communication technologies supported by the service interfaces. Remember one of the founding principles of service architecture: the service implementation is separated from the service interface(s).

To continue this discussion, we'll distinguish between "internal" and "external" clients. A client is internal if the organization controls the network path between the client and the service. In all other cases the client is external. This distinction is driven by the fact that firewalls might be located between the external client and the service, and no assumption can be made on which ports the firewall keeps open and which protocols the firewall lets pass, except that it allows text over HTTP. In particular, this is true if the client component is located on the Internet.

The major condition to decide on in a service interface technology is whether the service clients are internal or not. In Figure 1, external clients are red and internal clients are green. ExternalMainClient uses the Internet. As mentioned earlier, this causes severe restrictions as to which ports and protocols are available for communication. For example, communicating in RMI or IIOP is not realistic, since most firewalls will not let these protocols go through. In such a situation, only text-based protocols over HTTP (or HTTPS) should be considered.

Web services, a standardized technology that leverages the convenience of XML as text over HTTP, is the best technology available, provided that the client platform supports Web services. The .NET client from our example understands Web services. If it were not the case, we would have had to downgrade the communication to, for example, plain XML text over HTTP, with custom XML generation and parsing on the client side.

Now let's have a look at internal clients. OrderClient is a J2EE application client using RMI to communicate with OrderWorkflow. Why RMI and not Web services? Isn't Web services the most cool technology that every supporting platform should use when possible? Well, no. Using Web services between "internal" J2EE components has a heavy performance toll. Performance, which is a critical factor for most systems, is much more favorable to RMI than to Web services. It must be noted that Web services still has opportunities for significant optimizations, but current Web services implementations are notoriously slower than RMI.

The golden rule is: if a J2EE service only has internal J2EE or Java clients, stick to RMI, but if you can't make this assumption, consider Web services.This rule can be understood with a bit of logic: the closer the interface technology is to the implementation technology, the less work that has to be done to translate between the two. For example, XML, which Web services messages are made of, is farther from Java than RMI is. The gap between XML types and Java types is wider than the gap between CORBA IIOP types and Java types, which in turn is wider than the gap between RMI types and Java types. To generalize this rule, we can say that the more interoperable a technology is, the slower it tends to be. Although technology implementations can provide exceptions to this rule, the rule remains true in the vast majority of cases.

Each situation requires a decision based on the trade-off between interoperability and performance.

Fortunately, interoperability and performance benefits can be combined thanks to the fact that a service can have more than one interface. OrderWorkflow is a good example. While its implementation of the application logic is developed only once, the service presents two different interfaces: one RMI and one Web services.

Moreover, with the right tools, service interfaces can be generated automatically from one another. For example, a tool such as Castor XML or a JAXB implementation can generate Java classes from the XML Schemas. The RMI interface is thus generated with minimal hand coding. Enabling Web services as EJB endpoints is also a good alternative.

Figure 2 focuses on the OrderWorkflow service to illustrate how a single service is accessed through two communication channels. ExternalMainClient accesses the service through its Web services interface, which in terms of J2EE component types is a Web application resource (WAR). Upon receiving a Web services request, the WAR makes an ordinary Java method call to the business delegate located in the JAR, which in turn makes an RMI call to the EJB.

In contrast, the local OrderClient J2EE client directly calls the delegate without going through the WAR. The service business logic is located in the EJB-JAR component, and the WAR implements a Web services interface layer above the ordinary business delegate. Both interfaces share exactly the same business logic. This design pattern ensures a multiple-communication-channel SOA as well as the scalability, distributability, and other capabilities provided by the EJB technology.

The marketing application is a C legacy application that calls the reporting component to present statistical data to the user. Marketing is an internal client, but does not support RMI. CORBA is an effective and mature distributed architecture available to both C and J2EE platforms. Again, the reason for choosing CORBA over Web services is the performance. As a general rule, internal components should not communicate through Web services unless some other capability of Web services, such as the UDDI publish-discover mechanism, for example, is a deciding factor.

More Stories By Bruno Collet

Bruno Collet is a seasoned J2EE architect with five years of experience. He recently founded Studio 184 (www.studio184.com), where he is developing the ApolloNews news aggregator. Bruno holds a masters in computer science from ULB (Belgium), as well as several industry certifications (www.brunocollet.com).

Comments (0)

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
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...
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...
IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
DXWorldEXPO | CloudEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
DXWorldEXPO LLC announced today that Telecom Reseller has been named "Media Sponsor" of CloudEXPO | DXWorldEXPO 2018 New York, which will take place on November 11-13, 2018 in New York City, NY. Telecom Reseller reports on Unified Communications, UCaaS, BPaaS for enterprise and SMBs. They report extensively on both customer premises based solutions such as IP-PBX as well as cloud based and hosted platforms.
In his keynote at 19th Cloud Expo, Sheng Liang, co-founder and CEO of Rancher Labs, discussed the technological advances and new business opportunities created by the rapid adoption of containers. With the success of Amazon Web Services (AWS) and various open source technologies used to build private clouds, cloud computing has become an essential component of IT strategy. However, users continue to face challenges in implementing clouds, as older technologies evolve and newer ones like Docker c...
The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
A valuable conference experience generates new contacts, sales leads, potential strategic partners and potential investors; helps gather competitive intelligence and even provides inspiration for new products and services. Conference Guru works with conference organizers to pass great deals to great conferences, helping you discover new conferences and increase your return on investment.