Giovani Salvador's Blog

Giovani Salvador is one of the coordinators of the oldest JUG in Brazil, RSJUG, at the state of Rio Grande do Sul. He has worked as a university professor teaching Java and currently is a java architect at Dell in Porto Alegre, Brazil, where he is also doing his master's degree in computer science at Pontifical University Catholic. Giovani also owns SCJP and SCEA(I) as well as Certified Scrum Master (CSM).

Java Meets Agile

On September, 10th Daniel Wildt and I presented at JustJava event (the biggest Java event in Brazil) the "Java Meets Agile – A survival guide to adopt Agile inside Java teams" presentation. We presented some practices for Java teams to take that can help them to find problems early in the development process, focusing on business priorities and delivery of more reliable code and products.
The entire presentation is available here.

Here I summarize some of the practices we presented but it is important to remember first what is to be agile from development perspective.

- Focus on business needs: The business users want working software. They want you focusing on what is important for them. Documentation is important? Of course it is, but first make your software work, don’t spend weeks or even months producing documentation if software is what your customer wants. Focus on software first. Focus on business needs first.

- Open and honest communication between team members, between business users and the team that is making the software.
Everybody should feel part of the same team, having each one responsibility to build a product.

- Find problems early in the process. When you focus on the priorities set by the business team you can find potential problems
early in the development process.

- Faster responses to change: With short iterations you can adapt in an easier way to the business needs and nowadays business needs change all the time.

Having said that, here I summarize these practices.

Practices from an Architect Perspective

Generic Architectures (a silver bullet): When you spend time trying to design an architecture that tries to solve existing problems and also solve problems that don’t exist yet you spend valuable time that you should be using for the customer needs, for what the customer said it is top priority. I am not arguing architectures should not be well designed, I am just saying that you should do what is enough for the business needs you are working on.

Get your hands dirty – Prove your architecture: A good approach in this case is to develop a proof of concept for the architecture you are designing, especially if you are going to deal with technologies that you have not worked yet. A good architect practice what preaches.

Don’t make your project a laboratory for new technologies: I already saw projects failing because too much time was spent trying the best of the technologies. Don’t forget you need to solve your customer’s needs. That does not mean you can never try something new but try it without losing your focus on what your customer wants. And baseline your architecture at some time with a set of technologies and don’t fall in the temptation of trying the latest release of that wonderful framework.

Think of adopting an SOA approach with an ESB. You can gain agility when having functionalities exposed as services when building new products. You also have a chance to perform transformation inside the ESB to compose new services. For products, you can try Mule, Service Mix or Aqualogic Service Bus.

Practices from a Developer Perspective

Start coding the most priority tasks first. What would you code first? A complex business logic or the database access?
DAO layer is important, of course, but somehow you are going to connect to the database. But if you focus on that complex logic first than you have a chance to find problems early and discuss with the business team about them or even present to business team the results of your tests according to your view on that business rule. And if you really need the datasource to complete your business logic then you can mock it with easymock. The point is: Focus on what really matters for the business user.

Have in place a profiling tool to assess how you are dealing with objects. In this post I presented a situation where a profiling tool helped me to solve a problem. Unfortunately, I found that problem in production, but remember that being agile you find problems early in the process so having in place such tool you can avoid problems in the future. So try putting in place tools like OptmizeIt or Netbeans profiler to find out how JVM is dealing with the objects you are creating in your code.

Prove your tests with FIT. FIT allows you to focus on the acceptance criteria defined by the business team. With FIT you can assess your code is having the expected result according to what the business team defined.

Coverage tools like Cobertura and EMMA give you information about how good are your test scenarios. With such tools in place you avoid finding later that your test cases have not tested the entire logic.

I would like to discuss with anybody the aspects related to agile methodologies in Java teams, what practices are your team doing and what are the results. If you want, contact me at giovani . salvador at gmail . com

That’s it.

References

EasyMock
FIT
EMMA
Cobertura
Mark Richards podcast about FDD and Agile Architecture
Martin Fowler's refactoring books
Agile Manifesto
Agile Modeling from Scott Ambler

Java, SOA and XML

I have been involved in SOA (Service Oriented Architecture) projects and also studying a lot all the aspects of the SOA world. It is interesting that I thought that I knew SOA before working effectively with SOA. More specifically, I thought my knowledge on XML parsing (of course, using a JAXP implementation) would be sufficient to say that I really know XML.

For example, when we think of an XML document we usually think of something like this:

<customer>
        <address>
                <zipcode>123</zipcode>
                …
        </address>
        <address>
                <zipcode>321</zipcode>
                …
        </address>
</customer>

and not this:

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" 
        xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
        xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
        xmlns:tns="http://www.myservice.com/SyncBusiness/"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="SyncBusiness"
        targetNamespace="http://www.myservice.com/SyncBusiness/">
        <types>
                <xsd:schema targetNamespace="http://www.myservice.com/SyncBusiness/" 
                        xmlns:xs="http://www.w3.org/2001/XMLSchema"
                        xmlns:order="http://www.myservice.com/order">
                        <xs:import namespace="http://www.myservice.com/order" schemaLocation="./order.xsd" />
                        <xsd:element name="submitOrderResponse" type="order:Order" />
                        <xsd:element name="submitOrder" type="order:Order" />
                </xsd:schema>
        </types>
        <message name="submitOrderResponse">
        ...
        </message>
        <portType name="SyncBusiness">
        ...
        </portType>
        <binding name="SyncBusinessSOAP" type="tns:SyncBusiness">
                <soap:binding style="document"
                        transport="http://schemas.xmlsoap.org/soap/http" />
                <operation name="submitOrder">
                ...
                </operation>
        </binding>
        <service name="SyncBusiness">
                <port binding="tns:SyncBusinessSOAP"
                        name="SyncBusinessSOAP">
                        ....
                </port>
        </service>
</definitions>

But when you get involved with SOA using an ESB (Enterprise Service Bus) implementation you start to deal with a world you typically have not any involvement.
For example, when using web services as part of the technologies of a SOA solution, how many of us pay special attention to the namespace declaration of a WSDL document? Or the types definition? Or bindings?

One may argue that we don’t need to pay attention to such things as we have tools that make all this job for us, especially when we need to consume services published in a specific web service or when we need to expose a service.
But we should consider taking a deeper look into those things. Why? Here a couple of reasons.

Design By Contract
In the SOA world, when using the “design by contract” approach, we probably start our service by writing (maybe getting help from a tool) our WSDL document and think of the services we are going to provide. We also need to think of the XML Schema Documents and all the complex types we are expecting to deal with. The binding section also deserves a closer look to define the protocol to be used.
For example, the port portion of a WSDL document let us know the location of the service as we can see in the following snippet.

        <service name="MyService">
                <port binding="ms:MyServiceSoapBinding"
                        name="MyServiceSoapPort">
                        <soap:address
                                location="http://172.168.15.1:7101/esb/myservice" />
                </port>
        </service>

If you use a tool that generated that location pointing to a specific ip address you will probably have some problems with dynamic IP. But if you are responsible for taking care of the contract between the client of an ESB and the ESB itself then you know that you need to specify carefully all the services and their locations.

I am not saying here that the design by contract should always be used when designing a service. The bottom line here is that this
approach makes you think of some things in advance that you usually don’t pay special attention. It makes you first think of defining a good contract for the clients and when you think oriented to interfaces you start making yourself questions in advance and avoid problems in the future while designing your SOA solution.

Schema Transformation
Consider you have a service exposed in a specific ESB implementation that returns customer data. This service consolidates data from two other services but those 2 other services are not directly visible to the clients of the ESB. Let’s imagine one represent customer data from a legacy system and the other from a new system and your company wants to have a single view of the customer data to clients.
In this case, when there is a call to the published service in the ESB, the ESB is responsible for calling those 2 existing services, get the data and consolidate that data into one single format to the clients. What happens at this point? Transformation inside the ESB. You can use a specific language like Xquery and XSLT to perform this transformation but problems happen when you have the same set of names for the customer representation in both services, the old and the new one, as you see in the following XSD files.

CustInfo.xsd

<xs:element name="customer" >

    <xs:complexType>

        <xs:sequence>

             <xs:element name="customerId" type="xs:string"/>

             <xs:element name="customerName" type="xs:string"/>

             <xs:element name="customerAddress" type="xs:string"/>

        </xs:sequence>

    </xs:complexType>

  </xs:element>

CustInfoOld.xsd

<xs:element name="customer" >

    <xs:complexType>

        <xs:sequence>

             <xs:element name="customerIdentification" type="xs:string"/>

             <xs:element name="customerName" type="xs:string"/>

             <xs:element name="customerAddress2" type="xs:string"/>

        </xs:sequence>

    </xs:complexType>

</xs:element>

In other words, both legacy and new systems have XML Schema Documents and you may have name conflicts. You avoid problems using namespaces to represent both old and new schemas.

xmlns:custnew="http://www.custdata.org/CustInfo"
xmlns:custlegacy="http://www.custdataLegacy.org/CustInfoLegacy"

If we need to work with both schemas to perform transformation in a language like XQuery than all we need to do is to declare both schemas, each one being represented by one namespace, and use the namespace as an alias to each one of them and their elements.
That’s the reason we need to understand how namespaces are organized inside XML documents like WSDLs and XSDs. For the time I have played with ESB most of the problems I faced were related to invalid namespace references.

Note: Transformation inside an ESB implementation can be performed using Java callouts (if you are using an ESB written in Java) and you will probably deal with an object oriented view of your XML document and avoid problems you face when you are performing transformation using a a language like XQuery.
But you need to make an analysis of the benefits because if you need to perform a modification in the transformation than you will need to recompile the code and, depending on the ESB implementation, perform a restart. Some ESB implementations allow you to modify your XQuery code without performing restart. In the other hand, transformation using Java gives you more power.

Final Comments and Questions

What SOA has to do with Java? Nothing, because SOA is not dependent of a specific technology. And everything. SOA has everything to do with Java like Java has everything to do with XML. And in the Java world there is a number of ESB implementations like Aqualogic, Mule, JBoss, etc.

Which one do you guys use? And which approach to perform transformations are you guys using (XQuery or any other language or Java Calls)?
Also, using the design by contract approach?
I Appreciate any comment.

Thank you all.

September 2008

Search this blog:

Categories

Archives

September 2008
July 2008
May 2008
April 2008
March 2008
January 2008
December 2007

Recent Entries

Java Meets Agile

Java, SOA and XML

Java Architectural Knowledge for Job Interviews. Are we prepared?

This work is licensed under a Creative Commons License.