Building a Stronger Team that YOU work in

Anyone who has worked in a team knows that there is no simple answer for team success. Each employee/team-member offers a unique perspective and comes from a unique background (typically). This is even true in homogeneous teams, or centers of excellence. Building and sustaining team morale can be difficult especially in homogenous teams because direct comparisons can be drawn very quickly.

I recently read a general article, http://www.inc.com/jeff-haden/the-5-qualities-of-remarkable-bosses.html , this outlines a list of things bosses should do to build and sustain remarkable teams. I could not find myself agreeing more.

 

Develop every employee.

Deal with problems immediately.

Rescue your worst employee.

Serve others, not yourself.

Always remember where you came from.

The list above outlines how to be a good boss. However if you are team member these rules apply as well.

In order to help continue to build a stronger team, there may be a few more that need to be added to the list.

Build Trust: this is the nucleus of the team. Without a core sense of trust in one another, the team can breakdown into clusters and tuples.

Enable & even enforce team transparency: In order to build trust, establishing a level playing field of opportunities within the team. “The right person on the right seat in the bus” – Collins.

Ensure consistent and equal visibility: In an idea economy  it is very important to ensure that the right contributors are cited and given the opportunity to present. 

Enable and enforce core value from the ground-up: developing a core values set –a set of team values/principles and operational rules is very critical.

Be a follower: over time every team member must learn and demonstrate behaviors of a good follower.

As a leadership team member, each member must play a dual role sometimes – leader and follower. There is so much spotlight on being a good leader today, that people don’t have the skills anymore of being a good follower. Oftentimes a good leader is also a good follower.

Rolling Back Transactions

While doing a spot check on code and configuration – I noticed that the developer wasn’t throwing a runtime exception nor was he setting rollbackOnly in a CMT EJB.

I was told that any exception will rollback a transaction and it is not possible to setRollbackOnly, and there are only 4 types of transaction attributes on CMT. Wrong, wrong and wrong.

1. If your code throws an application exception – the container expects the bean to handle it. However, if your bean throws a runtime exception (or subclass), like javax.ejb.Exception – the container will rollback the transaction.

2. If you don’t want to throw RTEs all around your code – and/or you have massive catch all exception code blocks, you should context.setRollbackOnly – to rollback transactions.

3. There are various transaction attributes – 6 to be exact: Requires, Requires New, Supports, Not Supported, Never & Mandatory. Never and Mandatory are opposite to one another. Requires starts a transaction if not called with one, Mandatory will throw an exception if called without a transaction, Supports will use one if there is one, but won’t complain….rest are self explanatory.

What’s most important about Transactions are how the transaction propagates in both directions (commit and more importantly rollback)

Java EE 5–No Entity Beans!

I’ve always done ORM with HIbernate –and it helped a lot with cardinality (besides ORM general features).

1:1::Married Couple (there are cultural and religious exceptions)

1:n:: Order: Line Item

n:1:: Line Item: Order

n:n:: Course: Student

Regardless of cardinality, entities should never be non-singular from a naming convention stand point.

In Bidirectional relationships – the inverse side must refer to its owning side via the mappedBy element.

In n:1, the many side always owns the relationship. In n:n – it doesn’t matter.

All in all the beauty of Java Persistence API is that it has all the features that Hibernate had – and then makes things a lot simpler with Annotations. I never was a fan of annotations when they first surfaced, but I have slowly come to like it. I like the encapsulation it provides.

You can mix non-entity super classes with entity super classes, use polymorphic associations, queries etc. It is surprisingly flexible.

Three basic strategies remained consistent in ORM land – 1 table per class (or class per table) – usually you will have a database structure before you have the object structure.

GoF: Polymorphism, Encapsulation, Inheritance and Delegation

Polymorphism is when your client has a reference to an interface, and it’s concreate class can be one of many implementations. A different different behavior or value in a subclass can be utilized without a switch or an if. Parent class class defaults can be inherited and overridden where necessary. A method can be declared in a parent class, but each subclass can have a specialized implementation/logic of that method e.g. calculateArea();

Encapsulation is a core principal, it refers to the bundling of data with the methods that operate on that data. Basically, logic and data go together. If you have a class, with properties and logic together – it is encapsulated. Helps separation of concerns and reduces surface areas – also supports immutability – since only the object can control the data.

 
Inheritance is the ability of objects in an Object-Oriented language to inherit properties and methods of other objects e.g. in Java, use extends or implements keywords.

Delegation is when at runtime you can invoke a different object to complete a task dynamically. A useful OO pattern that has seen several implementations in Java EE.

The ability to frequently modify or add functionality, or quickly fix defects (Extensibility & Maintainability) comes from early design decisions.

All in all – these are core design principles – any object oriented analysis and design must respect, consider and apply these principles.

Java SE Security APIs and Frameworks

 

Java SE has a deep foundation for security – there are a variety of APIs and frameworks that plug on top of various security impls.

1. JAAS: Java Authentication and Authorization Services
2. GSS: Generic Security Services. Think Tokens.
3. JCE: Java Cryptography Extension. Keys and Ciphers.
4. JSSE: Java Secure Sockets Extensions. SSL and TLS.
5. SASL: Simple Authentication and Security Layer. Layer between Client and Server – describes the how. RFC 2222

 

TLS (SSL) is a point-to-point, transient only solution which provides no context, discrimination to content. Authentication, confidentiality and integrity is provided.
MLS (Message Layer Security) is an end-to-end security because it stays encrypted at rest and in motion. It is encrypted by the sender and can only be decrypted by the intended recipient. It does not depend on the transport layer.

Realm is the complete database of users and group, a user is an individual, a group is a collection of individuals, each group or individual can be assigned a key to the locks (aka role). In Java EE you can specify whether to propagate a client identity to the bean container or specify a run as. There is no choice either way but to trust the identify – as there is not authentication data propagated just the identity.

The EJB interoperability protocol is based on IIOP/GIOP 1.2 and CSIv2 (Common Secure Interoperability protocol).

Gang of Four Patterns for Java EE developers : Cheat Sheet

Here is the list of Gang of Four patterns related with an actual implementation in Java EE. Read on – it will make sense (hopefully).

Strategy: EJB interface.

Defines a family of algorithms, encapsulates each one and makes them interchangeable. Strategy lets the algorithm vary independently from clients who use it.

Decorator: Dependency Injection.

Attach additional responsibilities to an object dynamically. Provide a flexible alternative to sub-classing for extending functionality.

Factory: EJBs .

Define an interface for creating an object, but let the subclasses decide which class to instantiate.

Chain: Filters.

Decoupled requester and handler. Chain the handlers, one of them must handle it.

Singleton: JNDI

Ensure a class only has one instance, and provide a global point of access

Flyweight: JDBC Connection Pooling.

JDN

Adapter : Use the same interface, but adapt to other classes.

Façade: Single point of entry for a sub-system.

Template: Defer implementation to subclass.

Builder: For complex varying structures.

Iterator: Access items in any collection implementation.

Java EE 5 idiosyncrasies

In the Java Persistence API, you don’t need to provide an XML descriptor to specify the primary key, while you do need to provide a back pointer reference in a bidirectional relationship, unlike the Entity Bean specification version 2.1.

Java Server Faces can act as a front controller (i.e. no GUI) and unlike Custom Tag Libraries and much like a Servlet.

JSF does save view state, but cannot be previewed outside the container.

JCA = Java Cryptography Architecture as well as Java Connector Architecture. Having overloaded acronyms in the same domain is confusing. Java Cryptography Extension is packaged with JCA – guess which JCA? JAAS is the Java Authentication and Authorization Service. While the former supports RSA, DSA, AES etc, the latter abstracts authentication APIs as well as permissions API. JSSE is Java Secure Socket Extension – it is primarily used for TLS, SSL, Kerberos, SASL.
Weirdly enough JNLP applications that are running without their jars signed can interact with System properties and the clipboard. Well, in a way that’s understandable if you know what Web Start is supposed to be used for.

A single Sign-On delegator pattern is great for improving availability of remote security services, but doesn’t protect against weak session identifiers. Filtering for HTML tags is a good idea when accepting input reviews  - especially look for applet, script or frames and possibly div tags too. You don’t want folks entering scripts that get rendered somehow to grab other users data when viewed.

JSF in Java EE 5

Java Server Faces seems to have a lot to offer in Java EE 5, one would really question the existing Web Frameworks – traditional Struts or Web Works – seem antiquated immediately.

Backing Beans – deferred evaluation, bound listeners, validators and convertors provide powerful flexibility.

JSF has a powerful lifecycle, with events, renderers, components orchestrated prior to the response going out.

Renderer Kit provides output in any format, if none is provided you get HTML rendering by default.

JSF must be compliant with at least Servlet Specifications 1.3 or later. JSP 1.2 or later, and packaged in a standard war file.

XML Processing in Java EE 5

All of the new Web Services API requires XML processing. Thankfully there have been changes to how Java EE will handle that as well with a fresh batch of updates.

JAXB 2.0: Improves vastly over JAXB 1.0

W3C XML Schema features (fixes missing bindings)

Adds javax.xml.bind.annotation and supports Java-to-XML binding.

Reduction in generated schema-derived classes.

Validation via JAXP 1.3 validation APIs

Smaller runtime binaries.

Schema compiler, Schema generator and Binding runtime framework.

JAXB 1.0 allowed validation: at unmarshall time, and on-demand validation on the content tree. JAXB 2.0 allows validation at marshall time and unmarshall time.

Streaming API for XML (StAX)

StAX is the all new efficient API for XML, it has a lot of great features:

• Stream-oriented
• Event-Driven
• Pull-design
• Read/WriteYou can create fast, light-weight, bi-directional parsers that is easy on the heap.

JAXP (Java API for XML Processing) family includes StAX, TrAX, SAX, and DOM. StAX is good for low memory and limited extensibility applications.

Pull Parser – simpler than SAX, more memory efficient than DOM.

SAX can’t write – and isn’t bidirectional. DOM is way more powerful and flexible. One would dump SAX for StAX. An iterative pull parser – stax, an event driven push parser – then go for SAX.

I can’t see anyone using SAX anymore. Why would you? Unless you don’t want a cursor and iterator concept in your code – or you simply hate procedural and believe everything should be read-only events for XML processing. XMLStreamReader or XMLEventReader are the Cursor and Iterator APIs – well, Iterator APIs can do things a Cursor cannot do: Iterator is more extensible and flexible. Cursor is efficient, performant and memory friendly – ideal for small JVMs and JME

JAX-WS in Java EE 5

JAX-WS: Java API for XML Web Services. Does message oriented as well as RPC oriented services. Hides complexities of SOAP. No need to generate or parse SOAP messages (or understand the structure or format).

The JAX-WS endpoints must be annotated with @WebService or @WebServiceProvider. The business method must be annotated @WebMethod – a Service Endpoint Implementation (SEI) will be generated for this. JAXB compatible parameters are required.

Um, if you think Web Services or Clouds are NOT important, I hope the following stat will convince you.

 

The Client needs @WebServiceRef – the reference to the service (or wsdlLocation). Get the port from the service and then invoke the exposed method on the service. Yes you need the interface to the service.

JAX-WS 2.0 Support WS-I Basic Profile Version 1.1, SOAP 1.1 and WSDL 1.1.

There is support for doc/lit, rpc/lit, static ports, dynamic proxies, and DII.

All in all JAX-WS seems like a winner!

Well, can you still use SAAJ? Yes – it gives you direct access to the SOAP protocol and the SAAJ 1.3 API supports SOAP 1.1 and SOAP 1.2 specifications.

<Message>

<Part>

<Envelope>

<Header>

</Header>

<Body>

</Body>

</Envelope>

</Part>

</Message>

You can have Attachment Parts as peers to the Part. all Under the soap message but outside the envelope.

The attachment part will contain MIME headers and the content (any).

Um – BTW – you can use JAX-B to send SOAP Attachments too – so why would you want to bother with the SAAJ APIs is going to remain a mystery. But it’s there.