Anti-Patterns

What are Anti-Patterns? Anti-Patterns are common pitfalls that increase complexity with no benefit, decrease flexibility, increase costs and cause project failures.

Learning from others' mistakes is less painful than learning from our own mistakes. Ways to apply anti-patterns inlcude the following:

1. Avoidance - Prevent the anti-pattern from happening.
2. Remediation - Undo or correct the anti-pattern.
3. Mitigation - Lessen the impact of the anti-pattern.
4. Containment - Prevent the damage of the anti-pattern from spreading.
   

WSDL Document Structure

WSDL — the Web Services Description Language — is yet another language that was built by using XML. It is used to define a Web service. Like a SOAP message, a WSDL document is divided into four parts:

1. Definition of ports: We don’t really like the use of the word port here, but we’re stuck with it. A port is a connection point. The WSDL port defines a Web service, the operations that can be requested, and the messages that can be used. In other words, the WSDL description defines what you can do and how you do it after you connect to the port. Another way of describing it is that it is an XML definition of a program function.

1. Definition of messages: Here you see the definitions of the data items for each of the operations that are defined under the specification of the port. These definitions act as templates for the requesting program to make requests and for it to understand the responses it receives. In reality, these definitions are what a programmer thinks of as function calls. And as you may expect, they relate to a name space.

1. Definition of types: This defines the data types that are used by the Web service. These relate to a name space as well.

1. Definition of binding: This is technical stuff for the programs involved. It defines exactly how the two programs can connect to each other.

Data Redaction

Data Redaction refers to the function of reducing or limiting the set of data returned to a user based on the entitlements of that user.

Separation of Concerns

The separation of business logic (what an application does) from computer logic (how the computer is directed to do it) is known as the separation of concerns and is a software engineering best practice that should be applied in the design of all technology systems intended for business users. Unfortunately, this best practice has been observed more in theory than in practice. If you discuss this issue with software engineers, you may hear many excuses. The separation of concerns is often ignored simply because it takes effort to abide by it, and the costs of ignoring it are all in the future — in other words, too often, “quick and dirty” wins out over “slow and sure.” Another pernicious factor thwarting the separation of concerns is the perennial desire of some IT vendors to lock your business logic into their proprietary technology. (Never underestimate the greed factor.)

Creating a reusable architecture takes discipline. And discipline inevitably takes more time than you’d ever expect to establish itself. Management may need to be educated. The upfront costs of establishing and requiring discipline pay manifold dividends over time.

Reliable Web Services

Web Service Reliable Messaging is a framework whereby an application running in one application server can reliably invoke a Web Service running on another application server, assuming that both servers implement the WS-ReliableMessaging specification. Reliability is defined as the ability to guarantee message delivery between the two Web Services.

BEA's implementation of WS-ReliableMessaging specification is heavily dependent on the SAF (Store and Forward) feature provided by JMS.

WSRM delivery assurances:

• AtMostOnce
• AtLeastOnce
• ExactlyOnce
• InOrder
  

Message Level Security for Web Services

Message Level encryption creates end-to-end confidentiality instead of point-to-point confidentiality.

Message Level Security lies above transport level security. Message level security allows specific parts of a SOAP message to be encrypted or digitally signed before it is put "on the wire".

Message Level Security addresses the same security requirements as traditional Web Security, that is, authentication, authorization, integrity, confidentiality and non-repudiation.

Message Level Security makes security possible by embedding the security information in a message's SOAP header. The SOAP message itself either contains the information needed to secure the message (by digitally signing or encryption) or it contains information about where to get that information to handle security needs.

Services Orchestration and Consumption

In WebLogic Integration, process automation is implemented through Java Process Definitions (JPDs). A JPD is an annotated Java class that is compiled into an EJB, using the annotations to generate code. WLI's sweet spot is in visually designing long-lived, asynchronous, multi-step processes that would otherwise be prohibitively complex to implement.

Service Orchestration is typically performed in:

• Java Process Definitions in WebLogic Integration.
• Process Models in AquaLogic BPM Suite.
• Proxy Services in AquaLogic Service Bus.

Simple service orchestration can be implemented in Apache Beehive Java Web Services in WebLogic Server.

If an asynchronous operation is invoked on the Web Service, the client may proceed with processing in parallel with the service processing. However, the client may require a response to the asynchronous call. One way to accomplish this is to leverage a callback whereby the service calls an interface on the client. However, callbacks cannot always be used to nitify the client of request completion. To handle this, a Web Service can provide a polling interface.

Polling and Callbacks are two mechanisms to achieve asynchrony. You might implement both approaches, to handle all situations.

Canonical Data Model

I am designing several applications to work together through Messaging. Each application has its own internal data format.

How can you minimize dependencies when integrating applications that use different data formats?

Therefore, design a Canonical Data Model that is independent from any specific application. Require each application to produce and consume messages in this common format.

The Canonical Data Model provides an additional level of indirection between application's individual data formats. If a new application is added to the integration solution only transformation between the Canonical Data Model has to created, independent from the number of applications that already participate.

Top Five Java Technologies to Learn in 2008

• #5 OSGI - Reality check, monolithic containers carry too much baggage and Java libraries are so richly cross dependent. The trend is there, a lot of frameworks are moving towards OSGI to bring some sanity in their deployment. Projects that have employed OSGI in anger are Eclipse via Equinox, Nuxeo and BEA Event Server,
• #4 JCR - Reality check, not all data fits well within a relational database. In most cases, users want to store their own documents and have those properly managed (i.e. versioned). JCR with it's Jackrabbit implementation is becoming the de-facto standard for maintaining data other than the structured kind. Some examples of projects that have used this in unexpected and innovative ways are Drools BRMS for managing business rules, Apache Sling for universal resource storage and Mule Galaxy for SOA governance management.
• #3 GWT - Reality check, AJAX is here to stay and Javascript is still a pain to work with. GWT is gaining traction like wildfire at the expense of other Java web technologies like JSF. A lot of projects have begun creating extremely cool products with it. Some impressive examples are Queplix a CRM, Compiere an ERP and GPokr a multiplayer Texas hold-em poker game.
• #2 Groovy - Reality check, sometimes you have to write quick and dirty scripts to get your tasks done quickly. There's a lot of traction these days for dynamic scripting languages like Ruby. However if you want to truly leverage your existing skill set, then it's more efficient to take a evolutionary step. Groovy has come a long way since it's rocky beginnings. I believe Groovy is finally mature enough (it finally has a debugger) that it's safe to dip your toes in it. Furthermore, there's are a of books, books about frameworks (i.e. Grails) and tools (i.e. IntelliJ) that help you from getting lost.
• #1 Cloud Computing - Reality check, sometimes it just isn't worth it to setup your own physical servers. Amazon's services are going to be an extreme boon to development productivity. One of the most time consuming efforts, and one that is too often taken for granted, is the deployment of a load and performance testing harness. In a lot of rigid organization, it is sometime problematic to acquire so much hardware for use only for short time periods. There aren't many tools out there yet for the Java developer (see: "Grid Gain Distributed JUnit"), however it's ramping up pretty quickly. So just as we create our builds from the cloud via Maven repositories, one shouldn't be surprised to find cloud based testing resources to be part of every developer's tool chain in the future.