WSDL Refresher

Powered by Qumana

<xsd:element> defines the elements, and can include complex types within it. One style/pattern of defining the elements is:

Style1

complex type 1

complex type2

element1 uses complex type1

element 2 uses complex type 2

then inside the wsdl:message the element is referenced using

wsdl:part name="anyname" element=element1

OR one can directly DEFINE the element inside the message as in style2

Style2

<wsdl:message>

element1 uses complex type1

</wsdl:message>

once the message is defined using the xsd types and user defined complex types, the message is used as part of an operation

<wsdl:operation>

<wsdl:input  message= messagename1 >

<wsdl:output  message= messagename2 >

One/group of operations form a porttype

<wsdl:porttype name=    operation=>

A porttype is thus a grop of technology independent interfaces.

However interfaces in the end need to be implemented using technology. A possible way of calling/using the interface is using SOAP (technology)

To take it to this next level, a binding is used.

<wsdl:binding type=portname>

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name=opName>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>

and same for o/p

but how will the binding be called? for SOAP its through a URI. This forms the service

<wsdl:service name="srvname">
<wsdl:port name="SOAPbindingname" binding="tns:TravelOneServiceSOAP">
<soap:address location="http://localhost:xxx/URL"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

<wsdl:message>

JNDI resource eferences and resource environment references

Powered by Qumana

The client/server app can have coded entries that are seperate from the FINAL environment JNDI entries. This helps in differentiating coding from application assembly.

So inside the code you may have ctx.lookup("java:env/jms/blah1") but using the concept of "Resource References" and "Resource Environment References" you can map it up to "java:env/jms/blah2". The blah2 should be valid in the actual production environment. This avoids the need to change code or deployment descriptors.

Take a situaiton without them: the coder puts in blah1, but the server has blah2 which is being used by other programs already! now either has to change!- thatz where this comes in.

The funny part is that ResourceReference supports DB, Qconnections etc but does not support Queues. The support for JMS Queues (and their reference mapping) is covered under Resource Environment References.

The resource reference covers AS administered only and hence queue is dropped out.

Websphere MQ and Broker path, classpath settings

Powered by Qumana

MQ and Broker have IBM java underpinnings while I was focussing on Sun JVM's for sometime. Realized that they were causing some confusion and breaks. I am noting down the settings, so that they can be put back as required later.

Note:setx command from XP SP2 can help do what 'export' does for Unix/Linux

PATH=H:\websphere\IBM\WebSphere MQ\Java\lib;H:\websphere\IBM\WebSphere MQ\bin;H:\websphere\IBM\WebSphere MQ\tools\c\samples\bin;H:\websphere\IBM\WebSphere;

CLASSPATH

H:\websphere\IBM\WebSphere MQ\lib\com.ibm.mqetclient.jar;H:\websphere\IBM\WebSphere MQ\Java\lib\providerutil.jar;H:\websphere\IBM\WebSphere MQ\Java\lib\com.ibm.mqjms.jar;H:\websphere\IBM\WebSphere MQ\Java\lib\ldap.jar;H:\websphere\IBM\WebSphere MQ\Java\lib\jta.jar;H:\websphere\IBM\WebSphere MQ\Java\lib\jndi.jar;H:\websphere\IBM\WebSphere MQ\Java\lib\jms.jar;H:\websphere\IBM\WebSphere MQ\Java\lib\connector.jar;H:\websphere\IBM\WebSphere MQ\Java\lib\fscontext.jar;H:\websphere\IBM\WebSphere MQ\Java\lib\com.ibm.mq.jar;

TN5250j: Term Emulator for AS/400 OS/400

Powered by Qumana

Neat stuff: Applet'able, with advanced GUI features

Reason why it was built was there was not good java implementation of 5250 emulation.

this can also be hosted on the iSeries HTTP server. Also allows for file transfers.

Therz also a C based one http://tn5250.sourceforge.net/

eXtremeProgramming-XP: Key Takes

Powered by Qumana

User Stories: help estimate for release planning and are like usecases.

They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.

Make frequent small releases, iteratively, have an iteration plan in each iteration

Move ppl around: rotate code segments among ppl

CRC Cards: Use ClaUse Class, Responsibilities, and Collaboration (CRC) Cards to design the system as a team. The biggest value of CRC cards is to allow people to break away from the procedural mode of thought and more fully appreciate object technologyss, Responsibilities, and Collaboration (CRC) Cards to design the system as a team. The biggest value of CRC cards is to allow people to break away from the procedural mode of thought and more fully appreciate object technology

Never add functionality early: Keep the system uncluttered with extra stuff you guess will be used later. My add: Only create placeholders if required.

Refactor:

We continue to use and reuse code that is no longer maintainable because it still works in some way and we are afraid to modify it. But is it really cost effective to do so? Extreme Programming (XP) takes the stance that it is not.

There is a certain amount of Zen to refactoring. It is hard at first because you must be

able to let go of that perfect design you have envisioned and accept the design that was serendipitously discovered for you by refactoring. You must realize that the design you envisioned was a good guide post, but is now obsolete.

Pair Programming

All code to be included in a production release is created by two people working together at a single computer. Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project.

OVERALL

Planning User stories are written. Release planning creates the schedule. Make frequent small releases. The Project Velocity is measured. The project is divided into iterations. Iteration planning starts each iteration. Move people around. A stand-up meeting starts each day. Fix XP when it breaks. Designing Simplicity. Choose a system metaphor. Use CRC cards for design sessions. Create spike solutions to reduce risk. No functionality is added early. Refactor whenever and wherever possible.

Coding The customer is always available. Code must be written to agreed standards. Code the unit test first. All production code is pair programmed. Only one pair integrates code at a time. Integrate often. Use collective code ownership. Leave optimization till last. No overtime. Testing All code must have unit tests. All code must pass all unit tests before it can be released. When a bug is found tests are created. Acceptance tests are run often and the score is published.

J2EE Dangers - - Excerpts

Powered by Qumana

From: http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html?page=2

Vendor Sel: 1,5

Desgin: 2,3,7,10   -  1,5

Dev: 6,8,9   -  1,2,3,5,7

Stabilization/Load Testing :   -1,2,3,5,6,7,9

Live: 4 - almost everything

1. Not understanding Java, not understanding EJB, not understanding J2EE

Not knowing what any or all of the following are and what they do (this list represents just a sample of topics):

• Garbage collector (train, generational, incremental, synchronous, asynchronous)


• When objects can be garbage collected -- dangling references


• Inheritance mechanisms used (and their tradeoffs) in Java


• Method over-riding and over-loading


• Why java.lang.String (substitute your favorite class here!) proves bad for performance


• Pass-by reference semantics of Java (versus pass-by value semantics in EJB)


• Using == versus implementing the equals() method for nonprimitives


• How Java schedules threads on different platforms (for example, pre-emptive or not)


• Green threads versus native threads


• Hotspot (and why old performance tuning techniques negate Hotspot optimizations)


• The JIT and when good JITs go bad (unset JAVA_COMPILER and your code runs just fine, etc.)


• The Collections API


• RMI

.Not understanding J2EE

Symptoms:

• The "Everything is an EJB" design


• Manual transaction management instead of using the container-provided mechanisms


• Custom security implementations -- the J2EE platform has probably the most complete and integrated security architecture in enterprise computing, from presentation right through to the back end; it is rarely used to its full capabilities

2. Over-engineering (to EJB or not to EJB)

Symptoms:

• Oversized EJBs


• Developers who can't explain what their EJBs do and the relationships among them


• Nonreusable EJBs, components, or services when they should be


• EJBs starting new transactions when an existing transaction will do


• Data isolation levels set too high (in an attempt to be safe)

3.Not separating presentation logic from business logic

4.Not deploying where you develop

Also, get a snapshot of data from the production database and use it for testing, don't rely on artificially created data. If production data is sensitive, desensitize it and load it up.

5. Choosing the wrong vendors

Poor or zero integration between different tools (application servers and IDEs, IDEs and debuggers, source control and build tools, the list goes on)

For IDEs, debuggers, etc., developers simply forsaking them in favor of their own favorite tools

6. Not knowing your vendors

To avoid the dangers resulting from not knowing your vendors, subscribe to all the vendor-supplied support resources you can find such as email lists, news groups, and release notes (especially those with a list of bug fixes); you will get invaluable information.

Create a BUILD process well in advance

How transferable are vendor-specific skills in the J2EE world? Let's look at a concrete example of how two vendors -- IBM and BEA Systems Inc. -- that support EJB 1.1 produce dissimilar application servers. Indeed, how alike are BEA WebLogic 5.1 and IBM WebSphere 3.5?

1. BEA WebLogic is configured and administered in a completely different manner than IBM WebSphere.


2. IBM adopted an all-GUI environment philosophy with WebSphere. In contrast, BEA provided a whole host of command line utilities with WebLogic.


3. IBM WebSphere uses IIOP to communicate and throws CORBA exceptions that are visible to the programmer; WebLogic has no CORBA infrastructure at all, and uses the t3 protocol by default.


4. WebSphere is joined at the hip with Visual Age, while WebLogic is more IDE-agnostic. Indeed, you can develop for WebLogic using almost any IDE.

Being an expert on one application server does not mean you are an expert on all. The arguments above apply to anything: IDEs, debuggers, build tools, configuration management, and so on. . As such, allow yourself the time required to be skilled with your tools.

7.Not designing for scalability or performance

With Danger 7, close in on your performance and scalability requirements in the scoping phase -- know what numbers you need to hit before you move into development. If you know you need 50 transactions per second and your all-entity bean design will provide only 40, then you need to look at alternative solutions such as stored procedures, batch processes, or reworked OLTP aspects of your system.

Involve your vendor as much as possible in the scaling requirements -- they should know the strong and weak characteristics of their product and help you accordingly.

8.Antiquated development processes

use a well defined methodology. ensure build process is in place.

Good unit testing in placeTags: J2EE java pitfalls dangers

9.Failure to employ frameworks

+ no logging standards, bad exception handling framework

The following tasks are handled in a myriad of ways by developers and should be among the first targets of any framework:

• Logging


• Exception handling


• Getting a connection to a resource (database, naming service, and so on)


• Building JSP pages


• Data validation

Basing project plans and designs on marketing blurb, not on technical fact