ThinkMiddleware.

com

Search

ThoughtsandreflectionsonJ2EE,Java,andMiddleware
EJBvs.WebServices
By01
Sunday,October05,2008

ThisarticleisbynomeansanexhaustivediscussiononthesubjectofWebServicesandEJBs.But,IhaveoftenfoundmanyofthepointsIbringuphere
missingfrommeaningfuldebate.ResearchingthisarticlealsogavemeanopportunitytogoovermaterialI'vebeenwantingtoreadforawhilenow.
Introduction
Onnumerousoccasions,recently,thesubjectofbackendarchitecturehascomeupinmydaytodaywanderings.Inparticular,thedebateofEJBsvs.Web
Services.EJBsaretenyearsoldnow.WebServicescameontothesceneearlierthisdecade.Byhistoricalstandards,bothareyoungtechnologies.But,EJBs
dohaveacoupleofyearsandlegacyversionsonWebServices.Noonetechnologyistheendallbeallofeverysituation.Bothtechnologieshavetheiruses,
strengths,andweaknesses.But,whichoneshouldbeused?And,when?
WebServicesstillhavethenewandcool,buzzwordcomplianceauroa.ThatworeoffEJBsacoupleofyearsagoalthough,theEJBv3.0spec's
JPA(standardized,HibernateORMtechnology)thatreplacesEntityBeans,useofJava1.5AnnotationsinplaceofXMLconfigurationdocuments,and
simplificationoftheprogrammingparadigmhasbreathednewlifeintothetechnology.I'vereadarticlesandbooksthatsuggestthesemuchneededfeatures
cametoolittle,toolateithasbeensuggestedthattheEJBcultureisdying.Although,IwouldsuggestthatitismoreaccuratelystatedthattheEntityBean
cultureisdying.Albeit,theEJB2.xdeploymentdescriptorsarenotamajorsellingpointofthetechnologythesedays.
Likewise,thisarticlefocusesonJAXRPCWebServicesthatareimplementedasSOAPoverHTTPcalls.Although,someofthediscussionisrelevantoutside
ofthiscontext.IbelievethisisthemostcommonimplementationofWebServicesatthistime.Although,thereareplentyofalternatives.Youcoulduse
SOAPoverJMS.Or,youcouldbeusingRESTWebServices(see[15],[17],&[18]formoreinformation).YoucouldalsobeusingJAXWStobemaking
WebServicecalls.I'mnotsurehowmuchthatchangestheargumentsImakeherethatisoutsidethescopeofthisconversation.
EJBsandWebServicesarebothclientservertechnologies.Throughoutthisarticle,Iwilluse"theserverside"torepresentananabstract,businesslogicor
dataaccesstierthathostsEJBsorWebServices.Likewise,Iwilluse"theclientside"torefertoanytierthathostsWebServicesclientsorEJBclients.A
clientinthiscaseisanythingthatcallsbusinessordataaccesslogicontheserverside.

DecisionPoints

So,whichtechnologyshouldbeused?And,when?Beforeansweringthatquestion,letusreviewthedecisionpoints.WheneverIdiscussthissubject,Ifind
myselfbringingupthesamepoints:

IseverythingJavabased?
IsaJ2EEContainerpresentontheservertier?
Insidethefirewallvs.outsidethefirewall
Passingthroughfirewalls.
Baggage
Useofhardwareloadbalancertechnologies
SerializingJavaobjectsvs.XMLdocumentparsing.
JTATransactionManagervs.WSTransaction
WSSecurityvs.J2EESecurity&CSIv2
J2EEContainerfeatures/support
WebServicesArchitecture(EJBsunderthecovers)
Thisisbynomeansanexhaustivelist.But,itisalistofmyfavoritepoints.
ImuststressthatIdonotconsider"becauseitiscool"asareasontouseanynewtechnology.Idon'tbelieveatechnologyshouldbepursuedforitsownsake
thetechnologymustsolveaproblemthateitherdoesn'tcurrentlyhaveasolutionorthathasalessersolution.Ordinarily,thebusinessworldissolvingthesame
problemoverandoveragain.Everynowandthen,abettersolutioncomesalong.Civilizationmarchesbravelyforwardinsomeculturesthisiscalled
progress.Ihavemydoubts,butthatiswelloutsidethescopeofthisdiscussion.
IsEverythingJavaBased?
IfboththeclientandserverareJavabased,thedecisiontouseEJBsshouldbestraightforward.WhytaketheoverheadofaWebService,ifyoudon'tneed
too?Again,"becauseitiscool"isnotadefensiblepositionforanytechnology.
Iftheclient(orserverforthatmatter)arenotwritteninJava,itwillbedifficulttouseEJBs.Inthiscase,aWebServiceisthebestoptioninmyopinion.Of
course,itispossibletoconverttheEJBinterfacestoIDLusingjava2idlandfromtheregenerateCORBAbindingsforwhateverlanguageyourclientis
implementedin.But,thiswillbecomeverycomplex,quicklydependingonthelanguage,therecouldbeadditionalrequiredsteps.
Pleasenote,thisisanarticle(andawebsite)aboutJava&J2EEMiddlewareso,wetendtofocusonthatsegmentoftheindustry.
IsaJ2EEContainerpresentontheServerTier?
Likewise,ifyoudon'thaveaJ2EEcontainer,itwillbedifficulttouseEJBs.Although,JBossdoesofferafullyfunctional,OpenSourceJ2EEcontainer.But,
thatmaynotbeanoptioninsomeshops.Inthesecases,WebServiceswouldbetheonlyviableoption.

Again,wearefocusonJavaandJ2EEMiddlewarehere.So,willremainfocusedonthosetopics.
InternalClientsvs.ExternalClients:
Insidethefirewalloroutsidethefirewall?Inotherwords,istheclientonyourcorporatenetwork?Or,isitontheInternet?Putanotherway,isthe
architectureoftheclientandserversomethingthatyoucontrol?Aretheythesameplatforms?Or,isone.NetandtheotherJ2EE?
Ifboththeclientandservertiersexistwithinyoursphereofinfluence(aplacethatyoucontrol),thenusingEJBisprobablyaviableoption.Inthiscase,Web
Servicesareprobablyanoverkill.Sofar,inmyexperience,WebServicesareasolutionforusewithremoteclientsthatexistoutsideyoursphereofcontrol.
WebServicesareaubiquitousstandardontheInternetforexchangingcomplexdataandcallingbusinessanddataaccesslogic.
EJBsintheorycouldbeusedovertheInternethowever,youwouldbetyingallremoteclients(thatyoudon'tcontrolover)toJavaandJ2EEtechnologythat
willprobablybetoorestrictivetosomeofyourclients.
Likewise,providingredundancyontheEJBservertierwillbetrickyinthiscase.UsingahardwareloadbalancerwithEJBcalls(RMIoverIIOP)istricky
probablycounterproductive,ifyoucouldevengetittowork.Although,notrequiredbythespec,mostJ2EEEJBcontainers(andassociatedclient
implementations)providebasicredundancywithinaclusterconceptbyhavingclientstubs(HomeObjects)referenceaprimarycontainerandasecondary.Ifa
loadbalancerissittingbetweentheseitspossiblethesystemcouldbecomeconfused.Likewise,youcouldbemaintainingpersistentconnectionsthrougha
networkdevicethatistunedforshortlivedconnectionsthisaddsoverheadtothedeviceandwillleadtosocketerrorsinyourapplication.Furthermore,there
isnoguaranteethatyourInitialContext(throughtheloadbalancer)andtheconnectionyourEJBmethodcallsmakewillgotothesameserverthishurtsthe
primary/secondaryserverconceptmostEJBcontainersimplement.ItalsointroducesthepossibilitythatyourEJBcallcouldenduponanEJBserverthat
knowsnothingaboutyourEJBoryoursessionwiththecontainer(s).Thus,youarelimitedtoexposingeachindividualhost:portforyourORBListenertothe
outsideworld.
Inmyexperience,usingaclientsideServiceLocatorpatterninconjunctionwithHomeObjectcachingisthemosteffectivesolution.Thispatternhidesthe
detailsoffindingtheremoteservertier,providesaccesstothesameserviceonmultiplehost:portendpoints,cachesconnections(viaHomeObjects),andisa
standardJ2EEapproach.ThiscommentappliestoEJBv2.xhowever,objectcachingontheclientsidewouldstillprovideforpersistentconnections,low
overheadinreusingconnections,andagoodwaytomanagetheconnectionstotheservertier.Thatbeingthecase,aclientside,softwarebased,loadbalancing
solutionismyrecommendedapproachtoredundancyforEJBshardwareloadbalancersarebestavoidedinthissituation.
ConfiguringRMIoverIIOPforusethroughafirewallcanalsobedifficult,butnotimpossible.RunningRMI/IIOPthroughafirewallhastwobasic
challenges[1]:
"LocationtransparencyandthedynamicallocationofaddressesasdonebyCORBAmiddlewaremakeitdifficulttoknowinadvancethehostandport
addressesusedfortransactions"[1].
"AddressinginformationcontainedinanobjectreferenceisinvalidatedwhencrossingNetworkAddressTranslatingrouter.[1]

So,EJBsweren'treallydesignedtoworkbetweenaclientandserverbelongingtodifferentgroups.ItalsolooksallclientsintoJavathisisprobablynota
viable,realworldconstraint.Conversely,WebServicesweredesignedforexactlythiskindofthing.So,ifyourbusinessanddataaccesstier'sclientscanexist
outsideyoursphereofcontrol,WebServicesareprobablythebestoption.
By"sphereofcontrol",IgenerallyrefertoremoteclientscomingintoyourapplicationfromovertheInternet.But,itcouldalsobealeasedline.Thereare
probablymanyothercrazysituationsthatIhaven'tconsidered.But,thecommonthemewillbenocontrolovertheclienttier.
PassingThroughFirewalls
Ibroughtthistopicupinthelastsection.But,IexplicitlymentionitheretocontrastSOAPoverHTTPandRMIoverIIOP.ASOAPrequestbeingmadeover
anHTTPrequestisrunningoverastatelessprotocol.Thismeansasocketconnectionisestablished,arequestismade,aresponseisgiven,theconnectionis
closed.It'spossiblethesocketwouldbekeptopen(keepalives)andreusedforperformancereasons,buteachindividualrequestresponseisperformedin
isolationfrompreviouscommunicationbetweentheclientandserver.So,WebServices,SOAPoverHTTP,arefairlyeasytousewithafirewallconfiguration.
Incontrast,EJBs,RMIoverIIOP,hasmultiplehost:portcombinationsthatthefirewallwouldneedtoallow:JNDIport,ORBlistenerport,andportsinvolvedin
CSIv2.Worst,someoftheseportsaredynamicallyassignedatruntime.However,mostvendorsdoprovideamechanismtostaticallyassigntheseports.
So,itwouldbeeasiertoconfigureafirewallforusewithWebServicescommunicationthanforEJBcommunication.But,itispossibletodothelatterit'sjust
alittlemorecomplicated.
Baggage
AnEJBclientrequiresgenerated/compiledstubstobedistributedtoallclients.WebServicesdonotrequiresuchmechanismsWSDLscanbeusedtodescribe
theWebService'sformatandlocation.Although,manyWebServicesimplementationswilluseasimilarclientstubunderthecoversforaperformance
improvementthisstubwouldbegeneratedbythedevelopmenttoolsbasedupontheWSDL(IBMRADdoesthis,forexample).
Intheirpurestimplementation,WebServicesareeasiertouseandmanagefromaclientstandpointbecausetherearenoclientstubsused.
HardwareLoadBalancers
Ipreviouslybroughtupthistopicaswell.Usingthesameargumentoutlinedinthelastsection,WebServicesareabetterfitforloadbalancersthanEJBs.In
fact,IwouldrecommendnotattemptingtousealoadbalancerwithEJBs.
SerializingJavaObjectsVersusXMLDocumentParsing
Datamarshallingisanextremelyexpensivetask.Anytypeofnetworkbasedcommunicationbetweentwosystems(especiallydisparatesystems)willinvolve
sometypeofdatamarshalling.Thisisunavoidable.InaWebServicecall,datamarshallingisrepresentedastheconstructionofanXMLrequestdocumenton
theclientside,parsingtheXMLrequestdocumentontheserverside,constructinganXMLresponsedocumentontheserverside,andparsinganXML

responsedocumentontheclientside.ForanEJBcall,datamarshallingwillinvolveserializingtheJavaobject(s)thatarepassedtothemethodcallas
argumentsontheclientside,deserializingthoseJavaobjectsontheserverside,serializingaresponseobjectontheserverside,anddeserializingaresponse
objectontheclientside.
Regardlessofthetechnology,thereismuchhappening.Ingenerally,(de)serializingJavaobjectsismuchmoreefficientthanbuildingandparsingXML
documents.I'veseenthisnotjustinEJBsandWebServices,butincustombuiltsystemswereServletscouldbuilddynamicimagesbaseduponinformation
passedinviaaservletcallthatacceptedXMLdocumentsorserializedJavaobjectsasinputparameters.Ingenerally,theserializedobjectcallsweremore
efficient.
Itwouldbeirresponsibletorecommendatechnologybaseduponperformancealone.But,myexperiencehasshowntheretobeafairamountofoverheadin
parsingXMLdocuments(incomparisontoserializingJavaobjects).But,aswesawinthelastsection,iftheclientswillbeexternal,WebServicesarethe
betterchoiceregardlessofanyperformancehit.
JTATransactionManagerVersusWSTransaction
Anynontrivialapplicationwilleventuallyhavetoaccountforupdatingmultipledatabasesoraccessingmultipledatabaseconnectionsinthesameunitof
work.ThisiswheretheXAprotocolcomesintoplay.TheXAProtocolspecificationwaswrittenbytheX/Opengroup(presentlycalledTheOpenGroup).
DistributedTransactionsisacomplexsubject.Attemptingtodothetopicjusticehereiswelloutsidethescopeofthisdiscussion.Iwanttointroducethemajor
conceptsthatprovideforDistributedTransactionsinbothEJBsandWebServices.Mygoalistointroduceenoughinformationtomakeaninformeddecision.
TheJTSTransactionManager(orJTATransactionManagerasIhavebeenreferringtoit)isaJavaimplementationoftheXAProtocol'sTransactionManager.
TheJTSSpecificationdefinesthe"implementationofatransactionmanagerthatsupportstheJavaTransactionAPI(JTA)specification(seeJSR907)atthe
highlevelandimplementstheJavamappingoftheOMGObjectTransactionService(OTS)specificationatthelowlevel"[5].TheOMG"isaninternational,
openmembership,notforprofitcomputerindustryconsortium.OMGTaskForcesdevelopenterpriseintegrationstandardsforawiderangeoftechnologies,
andanevenwiderrangeofindustries."[6]TheOpenManagementGroupdefinesthespecificationsunderlyingCORBAtechnology.Thedefinitionjustgiven
forJTSdemonstratesthatunderthecovers,anEJBcontainerisaCORBAORB.TheJTASpecificationdefines"standardJavainterfacesbetweenatransaction
managerandthepartiesinvolvedinadistributedtransactionsystem:theresourcemanager,theapplicationserver,andthetransactionalapplications."[5]It
handlesallthemachineryimplementingXAtwophasecommit,distributedtransactioninaJ2EEapplication.
InanEJBbasedapplication,usingcontainermanagedtransactions(i.e.,declarativelydefinedtransactionsatthebeanormethodlevel,whicharehandled
behindthescenesbytheEJBcontainer)isprobablythemoststraightforwardwayofprovidingXAtransactionstoanapplication.
"WSTransactiondefinescoordinationtypes,suchasAtomicTransaction,whichusetheWSCoordinationframeworktodefineruleswhichboththe
Coordinatorandparticipantsmustadheretoduringtheircommunications."[21]TheWSCoordinationframework"describesanextensibleframeworkfor
providingprotocolsthatcoordinatetheactionsofdistributedapplications."[20]Inotherwords,theWSCoordinationframeworkdefineshowWebServices
(runningindifferentcontainers)shouldcoordinateactivities(suchastransactions).Itprovidesforthelowlevelcommunicationfacilitiesthatwouldbeneeded.
ForWebServicesrunninginthesamecontainer,iftheWebServicesaredefinedasEJBsinaJ2EEContainer,thentheJTATransactionManagercanbeusedto
coordinatedistributedtransactionbetweenWebServiceswithinthatsamecontainer.

WSTransactionalsodefineshowdistributedtransactionsinitiatedfromwithinWebServiceswouldinteractwiththeJTATransactionManager.WS
Transactioncouldalsocoordinatedistributedtransactionswith.Netandanyothertransactionservice,whichsupportWSAtomicTransaction.
TheWSTransactionspecsoundspromising,butitiscomplexandyoung.IhavenotseenWSTransactionbeingusedinaproductionenvironmentyet.But,
thatdoesn'tmeanitwon'tbeaviableofferinginthefuture.
Inthemeantime,thedeclarativetransactioninsideanEJBContainerdescribedaboveareprobablythebestoptioninmyopinion.
WSSecurityVersusJ2EESecurity&CSIv2
LikeDistributedTransactions,Securityisabigsubjectthatgoeswellbeyondthescopeofthisarticle.But,again,mygoalistopaintacoherent,highlevel
picturethatcanbeusedtomakedecisionregardingwhichtechnologytouse.
ThetopicofSecurityforWebServicesisdefinedbytheWSSecurityspecification.TheWSSecurityspecificationispublishedbytheOASISstandardsbody
asareallWebServicesspecifications.WSSecurityprovidesthreehighlevelconceptsforsecuringWebServices:
SecurityTokens
Integrity
Confidentiality
Thesethreeconceptsprovideforenduseridentity,messagesigning,andfieldencryption,respectively.Thereareotherconceptsintroducedinthespecification,
butthesearetheimportantones.Forexample,timestampstopreventreplayattacksarealsodefined.Ofcourse,thisconceptsuffersfromadependancyon
NTP(asdoallsecuritytimestamps)thatinevitablyleadstoproblemsregardlessofthetechnology.Ihaven'tseenatrulyrobustNTPsetupyet.But,itmaybe
outtheresomewhere.
SecurityTokenspasstheidentityofacallingappliationorendusertotheservertier.Thereareacoupleoftokensthataredefinedbythespeceachvendorcan
alsoimplementtheirownproprietarysecuritytokensdoingsotiesyoutoaparticularvendor'simplementation.TheSecurityTokenisinjectedintotheSOAP
headersofthemessage.Ordinarily,aSecurityTokenwouldonlybeapartofanrequestmessage.Itdoesn'tbuymuchtosendaSecurityTokenfromaserverto
theclientinaresponsedocument.IliketocallSecurityTokensWSSecurityIdentity,butthatisn'titsrealname.
Integrityprovidesmessagesigning.Thisisaglorified,trustedchecksumoftheXMLdocument.Thisprovidesamechanismthatoffersaguaranteethatthe
messagethatwasreceivedistheunalteredmessagethatsentbythesender.
ConfidentialityprovidesfieldencryptionforpotentiallyeveryfieldinanXMLdocument.ThisallowsaWebServicerequestandresponsetotraveloveran
unencryptedHTTPconnection,butstillallowtheinformationtobepassedwithassurancethatnounauthorizedpartiesreadthemessageintransit.
EJBSecurityisprovidedbyJ2EESecurityapartoftheJ2EESpecification.Thereisn'ta12mappingbetweenwhatWSSecurityprovidesandwhatJ2EE

Securityprovides.J2EESecurityaddressesauthenticationandauthorizationofWebResourcesandEJBs.
J2EESecurityattheWebtierisbeyondthescopeofthisdiscussion.J2EESecurityattheEJBtierprotectsEJBsbydeclaringmethodpermissionsandmapping
UsersandGroupstoJ2EESecurityRoles[12].ThisprovidesbasicauthorizationtoEJBs.
TohandlesecuritybetweenanEJBclientandtheEJBcontainer(assumingtheseareseparatecontainers)itisnecessarytoprovidesecuritytoken,integrity,and
confidentialityjustasWSSecurityprovides.CommonSecureInteroperabilityversion2(CSIv2),aCORBA/IIOPbasedstandardinteroperabilityprotocol,
addressesthissituationbyprovidingauthentication,protectionofintegrityandconfidentiality,andprincipalpropagationforinvocationsonenterprisebeans,
wheretheinvocationstakeplaceoveranenterprise'sintranet.[12]Themoststraightforwardwayofaccomplishingtheintegrityandconfidentialitypiecesare
touseSSL.StraightSSL(nonMASSLhandlestheconfidentialitypartatrustedclientcertificaterequiredinaMASSLconnectionwouldprovideforthe
integritypiece.I'msurethereareplentyinthesecuritycommunitywhowouldargueotherwise.IbelievethisishowWebspherev6.1addressesthese
requirements.
Passingasecuritytoken(i.e.,usercredentials)fromaclienttoaserverandhavingtheservertiertrustthosecredentialsplacestheonusofauthenticatingtheuser
ontheclienttier.ThissituationispresentwithEJBsorWebServicesso,thisdoesn'thelpuswiththeEJBorWebServicesdecision.
Inmyopinion,J2EEcontainershavebetteroutoftheboxsupportforEJBsecuritythroughJ2EESecurityandCSIv2thantheydoforWebServicesSecurity
throughWSSecurity.Inmostcontainers,enablingafewparameterswouldallowyoutouseCSIv2.Incontrast,WSSecurityisacomplexspecification
whoseimplementationsaredifficulttoconfigureandtroubleshoot.Allthingsbeingequal,securingEJBswouldprobablybeeasierthansecuringWebServices
primarilybecausecurrentlyJ2EEcontainershasbetteroutoftheboxsupportforJ2EESecurity&CSIv2.However,ifsecuritybetweentheclientandserver
tiersisnotaconcern,thenthispartprobablywon'tweighonthedecision.
MyownexperienceswithWSSecuritywouldsuggestthatthereisahappy,middlegroundthatlevelstheplayingfield.IfWSSecuritySecurityTokensare
usedwithWebServicesprovidedoveraMASSLtransportlayer,youhaveprovidedabasiclevelofuseridentitypropagatio,messageintegrity,and
confidentiality.Thisapproachalsoentailsencryptingeverybyteofthemessageatthetransportlayerinsteadofencryptingeachmessagefield.Whichoneis
moreeffecient?Idonothaveanyconcretedata.But,thelatterseemslikealotofworkforthecontainertobedoing.Ofcourse,theSOAcrowdisabigfanof
theirapproach.
J2EEContainerFeatures/Support
AnyonewhohasworkedwithaJ2EEContainer(WeborEJBContainer)knowstherearemanyconfigurationoptionsavailable.Somearedefinedwithinthe
spec.Others,arecommonproblemsthespecdoesn'taddresstowhicheachvendorgivesauniquesolution.Although,mostofthosesolutiontendtolookvery
similar.ThereisagreatdealofcrosspollinationbetweenWebsphere,WebSEAL,andJBoss,butthedetailsdotendtodiffergreatly.
TheseconfigurationandtuningfeaturesallowMiddlewareAdministratorstofinetuneJ2EEapplications.Theyalsorequiremasteryofasignificantbodyof
knowledgetobeeffective.But,thatisthemarkofagoodMiddlewareAdministrator.
Incontrast,WebServicesareafeaturethatwasbuiltontopoftheWeb&EJBcontainers(intheJava/J2EEuniverse)whetherthroughspecdefined
mechanismsorproprietaryimplementations.Asaresult,therearen'tnearlyasmanytuningorconfigurationoptionsforWebServicesinWebsphere,Weblogic,

orJBoss.Thismaychangeinthefutureitprobablywill.But,inthemeantime,aMiddlewareAdministratordoesn'thavemuchdirectcontrolovertheWeb
ServicessubsystemoftheJ2EEContainer.Although,thereisindirectcontrolthroughwhatisofferedupbytheWebandEJBcontainers.
Idon'tknowthatthisweighsinfavorofEJBorWebServicesliketheotherpointsdo,butitisinterestingtoconsiderthematurityofEJBimplementations
versusWebServiceswhenmeasuredfromthisstandpoint.MaybeIamincorrectwhenIsuggestthisisaWebServicesmaturitygauge.Perhaps,thatbodyof
tunableparameterswillnevermaterialize?I'dbescaredifthatwerethecase.
Architecture
ThisentirediscussionhasfocusedaroundWebServicesorEJBs.
TheWebServicesspecificationfamilydoesn'tgointomuchdetailabouthowWebServicesshouldbeimplemented.Inthisdiscussionwe'veevenbeen
focusingonJAXRPCWebServiceswithSOAPoverHTTPandEJBv3.0.TheEJB/J2EEspecdefinesmanyinternaldetailsofanEJBengine(namely
CORBA).Likewise,EJBexistsentirelywithintheJavauniverse.WebServicesareagnostictotheunderlyingplatformandlanguage.Furthermore,withWeb
Services,thespecsdonotlayoutnearlyasmanydetailsfromwhatIhaveseen.
AsIeludedtointhe"J2EEContainerFeatures/Support"section,thiscreatesasituationwhere,theimplementationofaWebServicesruntimeenvironmentcan
varydramaticallyfromoneimplementationtothenext.Thisstatementdoesn'teventakeintocomparisonallthealternativestoSOAPoverHTTP.So,an
architecturalcompromisemaybetowriteallbusinessanddataaccesslogicusingEJBv3.0(inconjunctionwithHibernateorJPA)andpertheJ2EESpecwrap
theEJBsasWebServices.Thissolvesmanyoftheproblems,butnotall.
Forexample,thiswouldstillleaveyouwiththeneedforWSSecurity(asdescribedearlier)insteadofCSIv2andJ2EESecurityforclientserver
communicationsecurity.
Fromastrictlyarchitecturalperspective,IthinkanEJBcontainerprovidesamorerobustenvironment.Thisopinionisanamalgamationofalltheprevious
pointsthathavebeenmade.
Conclusions
SeveraldiscussionpointshavebeenpresentedtohelpdeterminewhetherEJBsorWebServicesshouldbeused.Theconclusionofeachpointissummarized
below:
DiscussionPoint

Conclusion

Insidethefirewallvs.outsidethefirewall

Ifinsidethefirewall,useEJBs.Ifoutsidethefirewall,useWebServices.

IsJavaavailable?

IfYes,EJB.IfNo,WebServices.

IsaJ2EEcontaineravailableontheservertier?

IfYes,EJB.IfNo,WebServices.

Passingthroughfirewalls.

WebServicesareeasier.EJBsaremoredifficult.

Baggage(clientsidestubs)

WebServices

Baggage(clientsidestubs)

WebServices

Useofhardwareloadbalancertechnologies

WorkgreatwithWebServices.NotrecommendedwithEJBs

SerializingJavaobjectsvs.XMLdocumentparsing.

EJB

JTATransactionManagervs.WSTransaction

EJB

WSSecurityvs.J2EESecurity&CSIv2

EJB

J2EEContainerfeatures/support

EJB

WebServicesArchitecture(EJBsunderthecovers)

Neutral

Ifyourclientandservertiersareinsidethefirewall,Javaisbeingusedonbothtiers,andaJ2EEcontainerisavailableontheservertier,EJBsareprobablythe
bestapproach.Ifyouareoutsidethefirewall,don'thaveaJ2EEcontainer,ortherearenonJavaclients,WebServicesshouldbeused.
Therearealmostcertainlyothercriteriaformakingthisdecision.Whatdoyourdevelopershaveexperiencewith,forexample?Everysituationisunique.
Everyprojecthasitsownrequirements.Acompleteunderstandingofaproject'srequirementsisthemostimportantpieceofmakinganytechnologydecision.
Hopefully,thisarticlecanhelpintheprocessoftranslatingprojectrequirementsintoatechnologydecision.
References
[1]FirewallSecurityforCorbaandJ2EE/EJBwiththeIIOPDomainBoundaryController
[2]http://www.opengroup.org/bookstore/catalog/c193.htm
[3]http://www.opengroup.org
[4]http://java.sun.com/javaee/technologies/jts/index.jsp
[5]http://java.sun.com/javaee/technologies/jta/index.jsp
[6]http://www.omg.org
[7]http://www.omg.org/cgibin/doc?formal/20030902
[8]http://www.oasisopen.org
[9]http://www.oasisopen.org/specs/index.php#wssv1.1
[10]http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security.html
[11]http://java.sun.com/j2ee/j2ee1_4frspec.pdf
[12]http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security8.html
[13]https://juxtaposition.axley.net/2006/11/ontheperforma1.html
[14]http://soa.syscon.com/node/204424
[15]http://en.wikipedia.org/wiki/Representational_State_Transfer
[16]http://www.xfront.com/RESTWebServices.html
[17]http://www.petefreitag.com/item/431.cfm
[18]http://home.ccil.org/~cowan/restws.pdf
[19]http://www.jboss.org

[20]http://en.wikipedia.org/wiki/WSCoordination
[21]https://www.ibm.com/developerworks/webservices/library/wstransjta/
[22]http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wstx#technical
[23]http://www.hibernate.org
[24]http://en.wikipedia.org/wiki/Objectrelational_mapping
[25]http://java.sun.com/products/jndi/1.2/javadoc/javax/naming/InitialContext.html
[26]http://www.javatips.org/javaeetips/enterprisejavabeans/persistingahomeobjectreference.html
[27]http://en.wikipedia.org/wiki/Web_service
[28]http://java.sun.com/webservices/jaxrpc/overview.html
[29]http://en.wikipedia.org/wiki/JAXWS

Home
RelevantLinks
Conventions
QuickReference

2008www.thinkmiddleware.com
Allcopyrights&trademarksbelongtotheirrespectiveowners.
Thecommentsandopinionshereinarethatoftheauthor.
Pleasedirectallcommentsto01.
Whiletheinformationpresentedonthiswebsiteisbelievedtobecorrect,theauthorisnotresponsibleforanydamage,lossofdata,orother
issuesthatmayarisefromusingtheinformationpostedhere.

LastModified:Sunday,09Nov200810:48:35MST