12 Web Services Best Practices
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View 12 Web Services Best Practices as PDF for free.
More details
- Words: 4,542
- Pages: 44
IBM Software Services for WebSphere
Web Services Best Practices
© 2003 IBM Corporation
12_WebServices_BestPractices.ppt
Page 1 of 44
IBM Software Services for WebSphere
Agenda What are WebServices? How do they help? What’s this “Service Oriented Architecture” Thing? Architectural Best Practices Design Best Practices Interoperability Best Practices Performance Best Practices
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 2 of 44
IBM Software Services for WebSphere
The IT-related problems facing business today Drive down cost ƒEliminate duplicate systems ƒRe-use, don't re-build ƒSimplify skills base
Reduce cycle time and costs for external business processes ƒMove from manual transactions with suppliers towards automated transactions ƒFacilitate flexible dealings with partners with minimal process or IT impact
Support an on-demand business model ƒThe marketplace is changing - businesses need to change too ƒMany existing IT systems are inhibitors to change: complex and inflexible ƒExisting integrations can be inhibitors to change: multiple technologies, point-topoint integration, inflexible models
Integrate across the enterprise ƒIntegrate historically separate systems ƒCompletion of mergers and acquisitions ƒAcross physical and technology barriers
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 3 of 44
IBM Software Services for WebSphere
So, what has stopped us solving them? A multitude of technologies and platforms support your business systems Business process models are a mixture of people practises, application code and interactions between people and systems or between systems and systems Changes to one system tend to imply ripples of change at many levels to many other systems No single, fully functional, integration solution will talk to them all Deployment of any single, proprietary integration solution across the enterprise is complex, costly and time consuming Will any one integration solution talk to your partners'? Your future partners'? No single data / business / process model across (or beyond) the enterprise Not all integration technologies work as well across a wide area network or the internet as they do across a local area network ƒExotic protocols ƒDifficulties with firewalls ƒNetwork bandwidth
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 4 of 44
IBM Software Services for WebSphere
Integration on a vast scale Industry Solutions
Finance
Manufacturing
Customer Relationship Management
Distribution
Enterprise Resource Planning
Retail
Telecom
Project Lifecycle Management
Gov't.
...
Value Chain Management Suppliers & Distributors
Customers
Infrastructure
Business Integration
Web Services Best Practices
12_WebServices_BestPractices.ppt
Employees
(inter- & intra-enterprise)
© 2003 IBM Corporation
Page 5 of 44
IBM Software Services for WebSphere
Is Web Services the answer? Sort of ... Web Services are part of the answer ... but mostly we'll get to that later Service Oriented Architecture (SOA) is another part The two are not the same thing: ƒMost of today's production Web Services systems aren't service oriented architectures - they're simple remote procedure calls or point-to-point messaging via SOAP ƒMost of today's production service oriented architectures don't primarily use Web Services - many use existing mature technologies, such as XML, asynchronous messaging etc.
To really achieve the promoted benefits of Web Services, you need both
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 6 of 44
IBM Software Services for WebSphere
And just what is a Service Oriented Architecture? Service oriented architectures are intended to promote flexibility via clear definition and loose coupling All functions (that need to be used by more than one system) are defined as "services" Service providers agree a defined, implementation-independent interface with service clients There is only one instance of each service implementation, either at: Runtime ƒEach service, e.g. exchange rate calculation, is deployed in one place and one place only, and is remotely invoked by anything that needs to use it Deployment time ƒEach service is built once, but re-deployed to be invoked semi-locally wherever it is needed These concepts are intended to take "re-use" beyond the more usually achieved "design-time" re-use, i.e. where function is built once, then deeply embedded, e.g. as a shared code library, in whatever systems need it.
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 7 of 44
IBM Software Services for WebSphere
But, what is a service? Any function ... but perhaps at several levels of granularity, e.g.: Business Process Services: ƒcreateStockOrder ƒreconcileAccount
Business Transaction Services: ƒcheckOrderAvailability ƒcreateBillingRecord
Business Function Services: ƒcalculateDollarValueFromYen ƒgetStockPrice
Technical Function Services: ƒauditEvent ƒcheckUserPassword
There's value in thinking of all of these as "Services", i.e. with defined interfaces and runtime, deploy-time (or perhaps design-time) re-use
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 8 of 44
IBM Software Services for WebSphere
Services – Some ground rules A service encapsulates a well-defined invokable unit of business function, and exists either to provide information or to facilitate a change of business data from one valid and consistent state to another. Services neither remembers the last thing they were asked to do nor care what the next is, and are not dependent on the context or state of other services. Any dependencies between services should be defined in terms of common business process, function and data models. Services are defined using explicit interfaces that are independent of service implementations, and that both service requestors and service providers agree to. Services should be invokable through defined communication protocols that stress interoperability and location transparency.
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 9 of 44
IBM Software Services for WebSphere
From what SOA “is” to “what” it does for you: Encapsulation enables re-use: each element of your business is captured and implemented in only one place, so changing it is straightforward. ƒThere are benefits in development and maintenance costs, but flexibility is the primary goal in Service Oriented Architecture.
The use of implementation independent interfaces to describe this encapsulation means that heterogenous systems can be integrated, and changes to one lead to fewer knock-on effects. ƒObject programming via interfaces has been common for years; now we're moving up to integration via interfaces to realise the same benefits at the enterprise level.
With clearly defined interfaces between all business systems, you can start modelling (and changing) the business process captured by them at a level above individual systems. ƒService Oriented Architectures are an enabler for process modelling and automation at a truly enterprise scale.
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 10 of 44
IBM Software Services for WebSphere
What's so special about these interfaces? There are two important characteristics of interfaces within a service oriented architecture:
SYSTEM 1 Internal code and processs
Interface by contract ƒAn explicit interface definition or contract is used to bind a service requestor and a service provider ƒSpecifies explicitly only the mutual behaviour - specifies nothing about the implementation of the requestor or the provider ƒAllows either to change implementation or identity freely
Interface granularity ƒLarger grained ƒLoosely coupled
Interface Code CONTRACT Shared process and interface definitions
Interface Code Internal code and processs SYSTEM 2
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 11 of 44
IBM Software Services for WebSphere
"Service" Interfaces vs. "Component" Interfaces ... Think of the difference between applying for a mortgage over the phone or by post ... By post:
By phone:
•Client requests application form •Provider sends it •Client fills it in and returns it •Provider says "yes" or "no"
Service-like - the interaction is not dependent on the *identify* of the service provider - i.e. the completed application form can be returned to a different branch than the one that provided it.
Component-like - the interaction is dependent on the specific representative of the estate agent i.e. the *identity* of the service provider
Web Services Best Practices
12_WebServices_BestPractices.ppt
•Client calls provider •Provider says "Hello, how can we help" •"I'd like a mortgage please" •"What's your name" •"John Smith" •"What's the property address" •"27 ..." •etc. •etc. •etc. •etc. •etc. •"... OK, your mortgage agreement number is 12345, I'll post the rest of the details"
© 2003 IBM Corporation
Page 12 of 44
IBM Software Services for WebSphere
Recap: Rules for Service Oriented Architectures Any function is implemented once and once only as a Service Services can be runtime or deployment-time re-used Service providers and requesters are loosely bound: ƒEach service is defined by an implementation independent interface. ƒServices are defined in terms of common business function and data models. ƒCommunication protocols that emphasise interoperability and location transparency are used to mediate service interactions.
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 13 of 44
IBM Software Services for WebSphere
Value of Service Oriented Architectures Build once, use often ƒOne place to make one change - brings encapsulation from the Object world to the Enterprise world ƒLower development, operations and maintenance costs
Interface by contract ƒLoosely couples requestor and provider so each can vary independently ƒIntegration is explicitly defined and so better understood, at the application and Enterprise level
Few, large-grained interactions, each commonly agreed ƒAgain promotes looser coupling as small-grained state and process models are independent ƒSimplified, agreed, defined data and process flows - again, at the application and Enterprise level ƒLess variation and complexity to manage ƒEasier to change large-grained processes if individual steps are well defined and contain less complexity
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 14 of 44
IBM Software Services for WebSphere
Implications of Service Oriented Architectures Note that there's nothing to do with specific technologies here ƒSome technologies may help (e.g. CORBA provides interface definitions) ƒBut providing you implement these principles, anything will do particularly technologies that emphasise location independence and interoperability, e.g. asynchronous messaging
And note the implication for business processes: ƒThere is a strong synergy between Service Oriented Architecture and consistency of business processes across the enterprise ƒFull scale implementation will involve process re-engineering ƒIt is important that this simplifies and streamlines business practises, rather than removing any unique value or discriminator
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 15 of 44
IBM Software Services for WebSphere
Which problems do Service Oriented Architectures solve? You have a multitude of technologies and platforms supporting your business systems Business process models are a mixture of people practises, application code and interactions between people and systems or systems and systems Changes to one system tend to imply ripples of change at many levels to many other systems No single, fully functional integration solution will talk to them all Deployment of any single, proprietary integration solution across the enterprise is complex, costly and time consuming Assuming you get past that, will your integration solution talk to your partners'? Your future partners'? No single data / business / process model across (or beyond) the enterprise Not all integration technologies work as well across a wide area network or the internet as they do across a local area network ƒExotic protocols ƒDifficulties with firewalls ƒNetwork bandwidth
We've answered some important and difficult points, but much remains Let's see what Web Services brings to the party Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 16 of 44
IBM Software Services for WebSphere
The basics of Web Services – not that diagram again! Directory / Namespace Service Provider
Service Directory
ƒprovides e-business services ƒpublishes availability of these services through a registry
Service Directory ƒprovides support for publishing and locating services ƒlike telephone yellow pages
Service Requestor ƒlocates required services via the Service Broker ƒbinds to services via Service Provider
Service Requesto r
Client
But so what? Why isn't this just client/server?
Web Services Best Practices
12_WebServices_BestPractices.ppt
1. WSDL Publish
2. Find UDDI 3. Use SOAP
Service Provider
Server
http://mygateway.com/services/createOrder 1234 <customer id>AB35 - <part no>127.87A
2 © 2003 IBM Corporation ...
Page 17 of 44
IBM Software Services for WebSphere
Why Web Services is a revolution for integration inside and outside the enterprise The Web revolutionized the way people talk to systems: ƒCustomers: new business models, extension of opportunity ƒEmployees: new transparency, improved collaboration ƒOperators: dramatic reduction in infrastructure costs and complexity The key was a universal server-to-client model based on simple open standards and industry support
Web Services promises to do the same thing for the way systems talk to systems: ƒIntegrate one business directly with another - don't wait for the people ƒGet your own business talking to itself - joined up IT ƒDramatic reduction in infrastructure costs and complexity The key will be a universal program-to-program communication model based on simple open standards and industry support
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 18 of 44
IBM Software Services for WebSphere
The core Web Services technologies WSDL - Web Services Description Language ƒXML-based interface definition language ƒSeparate function from implementation - design by contract SOAP - Simple Object Access Protocol / Service Oriented Architecture Protocol ƒAn XML messaging protocol that works over any transport protocol - HTTP, SNMP, JMS / MQ, FTP etc. UDDI - Universal Description, Discovery, Integration ƒUDDI servers act as a directory of available services and service providers ƒSOAP can be used to query UDDI for WSDL definitions of services Unified namespace based on URL technology ƒNot dependent on proprietary routing and naming services
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 19 of 44
IBM Software Services for WebSphere
What's new? - We have got it right this time A namespace, communication protocol and interface definition language based on simple, existing, open standards ƒTCP/IP, HTTP, XML, ... ƒAvailable everywhere - don't need a monolithic integration solution - work with the Internet, routers, load balancing, firewalls, web servers, ... ƒAvailable already - most systems support basic TCP/IP, HTML, XML already, and many support Web Services already
Broad industry support ƒWeb Services Interoperability Group Founders: Accenture, BEA Systems Inc., Fujitsu Ltd., Hewlett-Packard Co., IBM Corp., Intel Corp., Microsoft Corp., Oracle Corp. and SAP AG ƒMany members
We have learnt from the past ƒLoose coupling - from EAI technologies ƒIntegration by contract, implementation by whatever - from CORBA, OO ƒKeep it simple, stupid - from the Web ƒWork together on it - from J2EE, HTTP, HTML etc.
e-business is driving the merging of Web, IT & Object technologies to form the foundation for Web Services Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 20 of 44
IBM Software Services for WebSphere
Web Services isn't just XML over HTTP ... SOAP allows XML over any protocol Different protocols have different qualities of service Examples ƒWS-ReliableMessaging - standard in development, preview of IBM's related HTTPR available now ƒSOAP over asynchronous messaging (MQSeries, JMS) available now
Gartner: ƒBy 2004, more than 25 percent of all standard Web services traffic will be asynchronous, using SMTP, FTP or message-oriented middleware for the transport (0.7 probability). ƒBy 2006, more than 40 percent of the standard Web services traffic will be asynchronous (0.7 probability).
The reality of "loosely coupled" - we don't need connectivity to all the systems in a transaction, all of the time
WS-ReliableMessaging Send
HTTP Client Message Tracking
Web Services Best Practices
12_WebServices_BestPractices.ppt
HTTP
Receive
HTTP Server Message Tracking
© 2003 IBM Corporation
Page 21 of 44
IBM Software Services for WebSphere
Which of our problems do Web Services solve? You have a multitude of technologies and platforms supporting your business systems Business process models are a mixture of people practises, application code and interactions between people and systems or systems and systems Changes to one system tend to imply ripples of change at many levels to many other systems No single, fully functional integration solution will talk to them all Deployment of any single, proprietary integration solution across the enterprise is complex, costly and time consuming Assuming you get past that, will your integration solution talk to your partners'? Your future partners'? No single data / business / process model across (or beyond) the enterprise Not all integration technologies work as well across a wide area network or the internet as they do across a local area network ƒExotic protocols ƒDifficulties with firewalls ƒNetwork bandwidth
Again, we've answered some important and difficult points, but much remains Let's take a look at Web Services and Service Oriented Architectures combined ... Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 22 of 44
IBM Software Services for WebSphere
Web Service Oriented Architectures (WS) You have a multitude of technologies and platforms supporting your business systems (SOA) Business process models are a mixture of people practises, application code and interactions between people and systems or systems and systems (SOA) Changes to one system tend to imply ripples of change at many levels to many other systems (WS) No single, fully functional integration solution will talk to them all (WS) Deployment of any single, proprietary integration solution across the enterprise is complex, costly and time consuming (WS) Assuming you get past that, will your integration solution talk to your partners'? Your future partners'? (SOA) No single data / business / process model across (or beyond) the enterprise (WS) Not all integration technologies work as well across a wide area network or the internet as they do across a local area network ƒExotic protocols ƒDifficulties with firewalls ƒNetwork bandwidth
Bingo! But ... Web Services are an immature technology. Are they up to this? Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 23 of 44
IBM Software Services for WebSphere
IBM's View of Web Services A Web Services is described by WSDL
New!
ƒnot limited to SOAP ƒmultiple protocols ƒboth synchronous and asynchronous ƒboth RPC and document oriented
New!
New!
Evolutionary ƒadd web service to your existing designs ƒdoes not require a radical redesign ƒWeb Services will not supplant other distributed technologies, it will supplement them
You have to start with a good, standard J2EE design ƒProper layer design and layer placement is critical to success ƒIf you are already doing XML, then Web Services provide a lot of benefit for little cost ƒIf not doing XML currently, then you must plan for the overhead it introduces
Standards, Standards, Standards ƒInteroperability is key ƒUse open source and commercial tools wisely and adhere to standards
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 24 of 44
IBM Software Services for WebSphere
WebSphere Studio makes this easy…
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 25 of 44
IBM Software Services for WebSphere
So maybe everything is a Web Service… And XML is the cargo between layers
Can you get too much of a good thing?
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 26 of 44
IBM Software Services for WebSphere
Scenario: Do NOT use XML/SOAP over HTTP between Layers Presentation Tier
Backend Systems
Business Logic Tier
DB
WebSphere Application Server Data Components
Model Managers ASP
SOAP over HTTP
IIS
Apache SOAP WS Interface
Session EJB (app control logic)
Data XML Java objects
KBML
Xalan XSLT Xerces parser KBML Open Source
Good: WS for Interoperability
Web Services Best Practices
12_WebServices_BestPractices.ppt
Xerces parser
Domain Object Model
Bad: XML/WS between application layers with J2EE server completely unnecessary
© 2003 IBM Corporation
Page 27 of 44
IBM Software Services for WebSphere
Lessons: Do NOT use XML/Web Services where they are not needed ƒno external interfaces being exposed ƒXML not being flowed through the system
XML/Web Services parsing takes time and generates garbage - it is not free Good place for Web Services is on the 'edge' of the application server ƒpreferred strategy for interoperability situations
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 28 of 44
IBM Software Services for WebSphere
Do NOT use WS for Fine-Grained Interactions
Bad: Finegrained WS calls.
Presentation Layer
Business Layer
Java Application
WebSphere Application Server
Swing (view/controller)
Web Service Generated SOAP stub Apache SOAP
Web Services Best Practices
12_WebServices_BestPractices.ppt
Apache SOAP
SOAP over HTTP
EJB (controller/model)
© 2003 IBM Corporation
Page 29 of 44
IBM Software Services for WebSphere
Do NOT use SOAP over HTTP between Java Application Servers Presentation Layer
Browser
Bad: Using WS between WAS application servers (no firewall issues)
12_WebServices_BestPractices.ppt
WebSphere Application Server
WebSphere Application Server
SOAP Engine
JSPs
Web Service Generated SOAP stub SOAP Engine
Web Services Best Practices
Business Layer
SOAP over HTTP
EJB
© 2003 IBM Corporation
Page 30 of 44
IBM Software Services for WebSphere
Where to Use Web Services Interoperability between heterogeneous systems Defer the choice of Transport ƒAsynchronous messaging (MQ, SMTP) ƒSynchronous (HTTP, RMI/IIOP, local)
Get through firewalls To expose a common, language neutral interface and hide implementation details Minimize impact of changes in one system effecting other systems Service Oriented Architectures
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 31 of 44
IBM Software Services for WebSphere
Balancing J2EE protocols If the application server may have Java as a service requester, have that Java application make an RMI/IIOP call to an EJB instead of using SOAP over HTTP. Support both RMI/IIOP and web services interfaces ƒSupport SOAP over MQ for asynchronous requests
Non-Java clients
Java clients, Servlets/EJBs in other JVMs
SOAP/HTTP
RMI-IIOP
JAX-RPC Service IF
Remote EJB IF
EJB Impl
Web Services Best Practices
12_WebServices_BestPractices.ppt
JMS-enabled clients XML/JMS
MDB
Local EJB IF
Java
Servlets, EJBs in the same JVM
© 2003 IBM Corporation
Page 32 of 44
IBM Software Services for WebSphere
Choose the Protocol based on the Requirements Sync Message Queue HTTP
Queued (Latency)
Reliable Delivery
Open Standard
X
X
X
* (JMS – Jav only)
X
X
SMTP RMI-IIOP
Async Broadcast
X X
X
Web Services Best Practices
12_WebServices_BestPractices.ppt
X
X
X X
X*
© 2003 IBM Corporation
Page 33 of 44
IBM Software Services for WebSphere
Architecture for Firewall Challenges Requirement was for a 'rich' client experience over the Internet and Intranet ƒMost outside the firewall (using Network Address Translation) ƒFirst attempt was to engineer a fully HTML-based solution ƒDecided on an Applet client ƒHowever the presence of multiple firewalls between client and server made the use of RMI/IIOP impossible ƒSo, the client introduced a Web Services interface for their existing EJBs to allow client communication over HTTP and SOAP
WebSphere Application Server
Applet Generated SOAP stub SOAP Engine
Application Client EJB Client
SOAP-HTTP
SOAP Engine RMI/IIOP
EJB
Firewall Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 34 of 44
IBM Software Services for WebSphere
When to use Web Services for Firewall Challenges Client had to overcome skepticism about the maturity of the technology from both outside consultants and internal I/T management Web Services was the right choice even though Java ran on both ends of the conversation ƒOvercame limitations of RMI/IIOP with NAT firewalls ƒSimple and easy to implement over existing EJBs
Large requests/data being sent Although the Application client was 'snappier' than SOAP over HTTP, the Applet had acceptable performance The same architecture has been put in place in other customers as well ƒWebSphere's EJB clients have a strong JDK dependency; using Web Services as a communication mechanism allows more flexibility on the client end
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 35 of 44
IBM Software Services for WebSphere
Interoperability .NET Requestor
SOAP HTTP
Apache SOAP Requestor
WebSphere Requestor
SOAP lite Requestor
Web Services Best Practices
12_WebServices_BestPractices.ppt
SOAP HTTP
.NET SOAP Service (provider)
SOAP JMS
WebSphere SOAP Service (provider)
WebSphere SOAP Service (provider to incoming requests requestor sending requests)
SOAP HTTP
SOAP lite SOAP Service (provider)
© 2003 IBM Corporation
Page 36 of 44
IBM Software Services for WebSphere
Choosing the Granularity in SOA Unified Logical View ƒAn extension of the Facade pattern -- encapsulation of technology-specific details
Replaceable Component ƒisolating requestors from change in the implementation
Composable component ƒSo that you can create business process with the elements (BPEL4WS)
WSDL WSDL
WSDL
Coordinator Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 37 of 44
IBM Software Services for WebSphere
Unified Logical View WebSphere Application Server (WAS)
Facade
SOAP Engine
JAXRPC Empl Svc. IF
Employee Service Implementation
Empl. Service Session EJB
Business logic (decides which backends to call and merges data)
CICS and
CICS Adapter
JCA
JDBC Adapter
JDBC
custom code
Web Services Best Practices
12_WebServices_BestPractices.ppt
Mainframe
CICS Java Gateway
DB2
3rd party system
© 2003 IBM Corporation
Page 38 of 44
IBM Software Services for WebSphere
Replaceable Component In one insurance application, the broker obtains policy quotes from several different systems Think of this as a large-scale application of the Strategy pattern
Broker
getQuote
Insurer A Adapter Insurer B Adapter
Internal UDDI Registry
Insurer A
Insurer B
Insurer C Adapter Insurer C Insurer X Adapter
Adapter WSDL
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 39 of 44
IBM Software Services for WebSphere
Design Best Practices Web Services should be coarse-grained interfaces Web Services should be stateless ƒEven though it's possible to use transport state mechanisms they should be avoided
The fastest web service call is NO web service call ƒCache Data on the requestor when reasonable ƒMinimize the number of requests for the same information ƒlogically group information into larger-grain requests when possible
Consider asynchronous messaging instead of synchronous RPC-style interaction ƒasynchronous is a more loosely coupled interaction model
Business Delegate
Web Services Proxy
Client cache
Web Services Best Practices
12_WebServices_BestPractices.ppt
Load Balancer
Stateless Stateless Stateless Web Web Web Service Service Service
© 2003 IBM Corporation
Page 40 of 44
IBM Software Services for WebSphere
Use Session EJBs for multiple protocols In nearly all synchronous request/response cases, a stateless Session EJB should be the preferred vehicle ƒThe only way to have fine-grained security ƒWhen a client can use RMI-IIOP the performance gains are significant but local calls are the fastest ƒConsider the Business Delegate Pattern
Client
RemoteEJBDelegate
LocalEJBDelegate
RMI -IIOP
Java call
RemoteEJBInt erface
LocalEJBInterface
SessionEJBImpl
SOAP/HTTP WebServiceDelegate
ServiceEndpointInterface
DelegateFactory Delegate <>
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 41 of 44
IBM Software Services for WebSphere
Performance - Approach Do not get hung up on performance concerns until you know the 'cost' of the web service ƒoften the business processing takes more time than the Web Service processing
Be smart about designing your application ƒcache data ƒsend references ƒsend the amount of data needed ƒsupport multiple protocols (don't only use SOAP over HTTP)
Create a prototype and test it under load Use the fastest SOAP Engine you are comfortable with Use the fastest XML Parser available ƒKeep your eye on the latest Apache releases
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 42 of 44
IBM Software Services for WebSphere
Specific Performance Results Smaller messages are better Fewer elements are better (less of an impact significant) simple is better than complex messages ƒavoid complex business objects ƒVector of 256 Complex Objects –256 * 4 * 100 = 100K – 13600 Elements or Tags
As messages get larger and more complex, the parsing time becomes a larger % of the processing time Use SAX instead of DOM for de-serializing XML into objects when you write custom deserializers. Code Practices ƒFor transferred objects being created from XML –Don’t initialize variables –Don’t set values in the Default Constructor –The values will be reset from XML
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 43 of 44
IBM Software Services for WebSphere
Resources Tutorials, articles, technologies WebSphere Developer Domain http://www7b.software.ibm.com/wsdd ƒDeveloper Works Web Services http://www.ibm.com/developerworks/webservices
Web Services Interoperability organisation ƒhttp://www.ws-i.org/
OASIS open standards organisation (ebXML etc.) ƒhttp://www.oasis-open.org/
Specifications: ƒBusiness Process http://www-106.ibm.com/developerworks/library/ws-bpel/ ƒTransactions http://www-106.ibm.com/developerworks/library/ws-transpec/ ƒSecurity http://www-106.ibm.com/developerworks/webservices/library/ws-secure/ ƒSOAP http://www.w3.org/TR/SOAP/ ƒWSDL http://www.w3.org/TR/wsdl ƒUDDI http://www.uddi.org/specification.html (public directory at https://uddi.ibm.com/ubr/registry.html)
ƒPreview Technology ƒhttp://www.alphaworks.ibm.com/webservices
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 44 of 44
Web Services Best Practices
© 2003 IBM Corporation
12_WebServices_BestPractices.ppt
Page 1 of 44
IBM Software Services for WebSphere
Agenda What are WebServices? How do they help? What’s this “Service Oriented Architecture” Thing? Architectural Best Practices Design Best Practices Interoperability Best Practices Performance Best Practices
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 2 of 44
IBM Software Services for WebSphere
The IT-related problems facing business today Drive down cost ƒEliminate duplicate systems ƒRe-use, don't re-build ƒSimplify skills base
Reduce cycle time and costs for external business processes ƒMove from manual transactions with suppliers towards automated transactions ƒFacilitate flexible dealings with partners with minimal process or IT impact
Support an on-demand business model ƒThe marketplace is changing - businesses need to change too ƒMany existing IT systems are inhibitors to change: complex and inflexible ƒExisting integrations can be inhibitors to change: multiple technologies, point-topoint integration, inflexible models
Integrate across the enterprise ƒIntegrate historically separate systems ƒCompletion of mergers and acquisitions ƒAcross physical and technology barriers
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 3 of 44
IBM Software Services for WebSphere
So, what has stopped us solving them? A multitude of technologies and platforms support your business systems Business process models are a mixture of people practises, application code and interactions between people and systems or between systems and systems Changes to one system tend to imply ripples of change at many levels to many other systems No single, fully functional, integration solution will talk to them all Deployment of any single, proprietary integration solution across the enterprise is complex, costly and time consuming Will any one integration solution talk to your partners'? Your future partners'? No single data / business / process model across (or beyond) the enterprise Not all integration technologies work as well across a wide area network or the internet as they do across a local area network ƒExotic protocols ƒDifficulties with firewalls ƒNetwork bandwidth
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 4 of 44
IBM Software Services for WebSphere
Integration on a vast scale Industry Solutions
Finance
Manufacturing
Customer Relationship Management
Distribution
Enterprise Resource Planning
Retail
Telecom
Project Lifecycle Management
Gov't.
...
Value Chain Management Suppliers & Distributors
Customers
Infrastructure
Business Integration
Web Services Best Practices
12_WebServices_BestPractices.ppt
Employees
(inter- & intra-enterprise)
© 2003 IBM Corporation
Page 5 of 44
IBM Software Services for WebSphere
Is Web Services the answer? Sort of ... Web Services are part of the answer ... but mostly we'll get to that later Service Oriented Architecture (SOA) is another part The two are not the same thing: ƒMost of today's production Web Services systems aren't service oriented architectures - they're simple remote procedure calls or point-to-point messaging via SOAP ƒMost of today's production service oriented architectures don't primarily use Web Services - many use existing mature technologies, such as XML, asynchronous messaging etc.
To really achieve the promoted benefits of Web Services, you need both
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 6 of 44
IBM Software Services for WebSphere
And just what is a Service Oriented Architecture? Service oriented architectures are intended to promote flexibility via clear definition and loose coupling All functions (that need to be used by more than one system) are defined as "services" Service providers agree a defined, implementation-independent interface with service clients There is only one instance of each service implementation, either at: Runtime ƒEach service, e.g. exchange rate calculation, is deployed in one place and one place only, and is remotely invoked by anything that needs to use it Deployment time ƒEach service is built once, but re-deployed to be invoked semi-locally wherever it is needed These concepts are intended to take "re-use" beyond the more usually achieved "design-time" re-use, i.e. where function is built once, then deeply embedded, e.g. as a shared code library, in whatever systems need it.
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 7 of 44
IBM Software Services for WebSphere
But, what is a service? Any function ... but perhaps at several levels of granularity, e.g.: Business Process Services: ƒcreateStockOrder ƒreconcileAccount
Business Transaction Services: ƒcheckOrderAvailability ƒcreateBillingRecord
Business Function Services: ƒcalculateDollarValueFromYen ƒgetStockPrice
Technical Function Services: ƒauditEvent ƒcheckUserPassword
There's value in thinking of all of these as "Services", i.e. with defined interfaces and runtime, deploy-time (or perhaps design-time) re-use
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 8 of 44
IBM Software Services for WebSphere
Services – Some ground rules A service encapsulates a well-defined invokable unit of business function, and exists either to provide information or to facilitate a change of business data from one valid and consistent state to another. Services neither remembers the last thing they were asked to do nor care what the next is, and are not dependent on the context or state of other services. Any dependencies between services should be defined in terms of common business process, function and data models. Services are defined using explicit interfaces that are independent of service implementations, and that both service requestors and service providers agree to. Services should be invokable through defined communication protocols that stress interoperability and location transparency.
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 9 of 44
IBM Software Services for WebSphere
From what SOA “is” to “what” it does for you: Encapsulation enables re-use: each element of your business is captured and implemented in only one place, so changing it is straightforward. ƒThere are benefits in development and maintenance costs, but flexibility is the primary goal in Service Oriented Architecture.
The use of implementation independent interfaces to describe this encapsulation means that heterogenous systems can be integrated, and changes to one lead to fewer knock-on effects. ƒObject programming via interfaces has been common for years; now we're moving up to integration via interfaces to realise the same benefits at the enterprise level.
With clearly defined interfaces between all business systems, you can start modelling (and changing) the business process captured by them at a level above individual systems. ƒService Oriented Architectures are an enabler for process modelling and automation at a truly enterprise scale.
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 10 of 44
IBM Software Services for WebSphere
What's so special about these interfaces? There are two important characteristics of interfaces within a service oriented architecture:
SYSTEM 1 Internal code and processs
Interface by contract ƒAn explicit interface definition or contract is used to bind a service requestor and a service provider ƒSpecifies explicitly only the mutual behaviour - specifies nothing about the implementation of the requestor or the provider ƒAllows either to change implementation or identity freely
Interface granularity ƒLarger grained ƒLoosely coupled
Interface Code CONTRACT Shared process and interface definitions
Interface Code Internal code and processs SYSTEM 2
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 11 of 44
IBM Software Services for WebSphere
"Service" Interfaces vs. "Component" Interfaces ... Think of the difference between applying for a mortgage over the phone or by post ... By post:
By phone:
•Client requests application form •Provider sends it •Client fills it in and returns it •Provider says "yes" or "no"
Service-like - the interaction is not dependent on the *identify* of the service provider - i.e. the completed application form can be returned to a different branch than the one that provided it.
Component-like - the interaction is dependent on the specific representative of the estate agent i.e. the *identity* of the service provider
Web Services Best Practices
12_WebServices_BestPractices.ppt
•Client calls provider •Provider says "Hello, how can we help" •"I'd like a mortgage please" •"What's your name" •"John Smith" •"What's the property address" •"27 ..." •etc. •etc. •etc. •etc. •etc. •"... OK, your mortgage agreement number is 12345, I'll post the rest of the details"
© 2003 IBM Corporation
Page 12 of 44
IBM Software Services for WebSphere
Recap: Rules for Service Oriented Architectures Any function is implemented once and once only as a Service Services can be runtime or deployment-time re-used Service providers and requesters are loosely bound: ƒEach service is defined by an implementation independent interface. ƒServices are defined in terms of common business function and data models. ƒCommunication protocols that emphasise interoperability and location transparency are used to mediate service interactions.
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 13 of 44
IBM Software Services for WebSphere
Value of Service Oriented Architectures Build once, use often ƒOne place to make one change - brings encapsulation from the Object world to the Enterprise world ƒLower development, operations and maintenance costs
Interface by contract ƒLoosely couples requestor and provider so each can vary independently ƒIntegration is explicitly defined and so better understood, at the application and Enterprise level
Few, large-grained interactions, each commonly agreed ƒAgain promotes looser coupling as small-grained state and process models are independent ƒSimplified, agreed, defined data and process flows - again, at the application and Enterprise level ƒLess variation and complexity to manage ƒEasier to change large-grained processes if individual steps are well defined and contain less complexity
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 14 of 44
IBM Software Services for WebSphere
Implications of Service Oriented Architectures Note that there's nothing to do with specific technologies here ƒSome technologies may help (e.g. CORBA provides interface definitions) ƒBut providing you implement these principles, anything will do particularly technologies that emphasise location independence and interoperability, e.g. asynchronous messaging
And note the implication for business processes: ƒThere is a strong synergy between Service Oriented Architecture and consistency of business processes across the enterprise ƒFull scale implementation will involve process re-engineering ƒIt is important that this simplifies and streamlines business practises, rather than removing any unique value or discriminator
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 15 of 44
IBM Software Services for WebSphere
Which problems do Service Oriented Architectures solve? You have a multitude of technologies and platforms supporting your business systems Business process models are a mixture of people practises, application code and interactions between people and systems or systems and systems Changes to one system tend to imply ripples of change at many levels to many other systems No single, fully functional integration solution will talk to them all Deployment of any single, proprietary integration solution across the enterprise is complex, costly and time consuming Assuming you get past that, will your integration solution talk to your partners'? Your future partners'? No single data / business / process model across (or beyond) the enterprise Not all integration technologies work as well across a wide area network or the internet as they do across a local area network ƒExotic protocols ƒDifficulties with firewalls ƒNetwork bandwidth
We've answered some important and difficult points, but much remains Let's see what Web Services brings to the party Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 16 of 44
IBM Software Services for WebSphere
The basics of Web Services – not that diagram again! Directory / Namespace Service Provider
Service Directory
ƒprovides e-business services ƒpublishes availability of these services through a registry
Service Directory ƒprovides support for publishing and locating services ƒlike telephone yellow pages
Service Requestor ƒlocates required services via the Service Broker ƒbinds to services via Service Provider
Service Requesto r
Client
But so what? Why isn't this just client/server?
Web Services Best Practices
12_WebServices_BestPractices.ppt
1. WSDL Publish
2. Find UDDI 3. Use SOAP
Service Provider
Server
http://mygateway.com/services/createOrder
Page 17 of 44
IBM Software Services for WebSphere
Why Web Services is a revolution for integration inside and outside the enterprise The Web revolutionized the way people talk to systems: ƒCustomers: new business models, extension of opportunity ƒEmployees: new transparency, improved collaboration ƒOperators: dramatic reduction in infrastructure costs and complexity The key was a universal server-to-client model based on simple open standards and industry support
Web Services promises to do the same thing for the way systems talk to systems: ƒIntegrate one business directly with another - don't wait for the people ƒGet your own business talking to itself - joined up IT ƒDramatic reduction in infrastructure costs and complexity The key will be a universal program-to-program communication model based on simple open standards and industry support
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 18 of 44
IBM Software Services for WebSphere
The core Web Services technologies WSDL - Web Services Description Language ƒXML-based interface definition language ƒSeparate function from implementation - design by contract SOAP - Simple Object Access Protocol / Service Oriented Architecture Protocol ƒAn XML messaging protocol that works over any transport protocol - HTTP, SNMP, JMS / MQ, FTP etc. UDDI - Universal Description, Discovery, Integration ƒUDDI servers act as a directory of available services and service providers ƒSOAP can be used to query UDDI for WSDL definitions of services Unified namespace based on URL technology ƒNot dependent on proprietary routing and naming services
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 19 of 44
IBM Software Services for WebSphere
What's new? - We have got it right this time A namespace, communication protocol and interface definition language based on simple, existing, open standards ƒTCP/IP, HTTP, XML, ... ƒAvailable everywhere - don't need a monolithic integration solution - work with the Internet, routers, load balancing, firewalls, web servers, ... ƒAvailable already - most systems support basic TCP/IP, HTML, XML already, and many support Web Services already
Broad industry support ƒWeb Services Interoperability Group Founders: Accenture, BEA Systems Inc., Fujitsu Ltd., Hewlett-Packard Co., IBM Corp., Intel Corp., Microsoft Corp., Oracle Corp. and SAP AG ƒMany members
We have learnt from the past ƒLoose coupling - from EAI technologies ƒIntegration by contract, implementation by whatever - from CORBA, OO ƒKeep it simple, stupid - from the Web ƒWork together on it - from J2EE, HTTP, HTML etc.
e-business is driving the merging of Web, IT & Object technologies to form the foundation for Web Services Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 20 of 44
IBM Software Services for WebSphere
Web Services isn't just XML over HTTP ... SOAP allows XML over any protocol Different protocols have different qualities of service Examples ƒWS-ReliableMessaging - standard in development, preview of IBM's related HTTPR available now ƒSOAP over asynchronous messaging (MQSeries, JMS) available now
Gartner: ƒBy 2004, more than 25 percent of all standard Web services traffic will be asynchronous, using SMTP, FTP or message-oriented middleware for the transport (0.7 probability). ƒBy 2006, more than 40 percent of the standard Web services traffic will be asynchronous (0.7 probability).
The reality of "loosely coupled" - we don't need connectivity to all the systems in a transaction, all of the time
WS-ReliableMessaging Send
HTTP Client Message Tracking
Web Services Best Practices
12_WebServices_BestPractices.ppt
HTTP
Receive
HTTP Server Message Tracking
© 2003 IBM Corporation
Page 21 of 44
IBM Software Services for WebSphere
Which of our problems do Web Services solve? You have a multitude of technologies and platforms supporting your business systems Business process models are a mixture of people practises, application code and interactions between people and systems or systems and systems Changes to one system tend to imply ripples of change at many levels to many other systems No single, fully functional integration solution will talk to them all Deployment of any single, proprietary integration solution across the enterprise is complex, costly and time consuming Assuming you get past that, will your integration solution talk to your partners'? Your future partners'? No single data / business / process model across (or beyond) the enterprise Not all integration technologies work as well across a wide area network or the internet as they do across a local area network ƒExotic protocols ƒDifficulties with firewalls ƒNetwork bandwidth
Again, we've answered some important and difficult points, but much remains Let's take a look at Web Services and Service Oriented Architectures combined ... Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 22 of 44
IBM Software Services for WebSphere
Web Service Oriented Architectures (WS) You have a multitude of technologies and platforms supporting your business systems (SOA) Business process models are a mixture of people practises, application code and interactions between people and systems or systems and systems (SOA) Changes to one system tend to imply ripples of change at many levels to many other systems (WS) No single, fully functional integration solution will talk to them all (WS) Deployment of any single, proprietary integration solution across the enterprise is complex, costly and time consuming (WS) Assuming you get past that, will your integration solution talk to your partners'? Your future partners'? (SOA) No single data / business / process model across (or beyond) the enterprise (WS) Not all integration technologies work as well across a wide area network or the internet as they do across a local area network ƒExotic protocols ƒDifficulties with firewalls ƒNetwork bandwidth
Bingo! But ... Web Services are an immature technology. Are they up to this? Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 23 of 44
IBM Software Services for WebSphere
IBM's View of Web Services A Web Services is described by WSDL
New!
ƒnot limited to SOAP ƒmultiple protocols ƒboth synchronous and asynchronous ƒboth RPC and document oriented
New!
New!
Evolutionary ƒadd web service to your existing designs ƒdoes not require a radical redesign ƒWeb Services will not supplant other distributed technologies, it will supplement them
You have to start with a good, standard J2EE design ƒProper layer design and layer placement is critical to success ƒIf you are already doing XML, then Web Services provide a lot of benefit for little cost ƒIf not doing XML currently, then you must plan for the overhead it introduces
Standards, Standards, Standards ƒInteroperability is key ƒUse open source and commercial tools wisely and adhere to standards
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 24 of 44
IBM Software Services for WebSphere
WebSphere Studio makes this easy…
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 25 of 44
IBM Software Services for WebSphere
So maybe everything is a Web Service… And XML is the cargo between layers
Can you get too much of a good thing?
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 26 of 44
IBM Software Services for WebSphere
Scenario: Do NOT use XML/SOAP over HTTP between Layers Presentation Tier
Backend Systems
Business Logic Tier
DB
WebSphere Application Server Data Components
Model Managers ASP
SOAP over HTTP
IIS
Apache SOAP WS Interface
Session EJB (app control logic)
Data XML Java objects
KBML
Xalan XSLT Xerces parser KBML Open Source
Good: WS for Interoperability
Web Services Best Practices
12_WebServices_BestPractices.ppt
Xerces parser
Domain Object Model
Bad: XML/WS between application layers with J2EE server completely unnecessary
© 2003 IBM Corporation
Page 27 of 44
IBM Software Services for WebSphere
Lessons: Do NOT use XML/Web Services where they are not needed ƒno external interfaces being exposed ƒXML not being flowed through the system
XML/Web Services parsing takes time and generates garbage - it is not free Good place for Web Services is on the 'edge' of the application server ƒpreferred strategy for interoperability situations
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 28 of 44
IBM Software Services for WebSphere
Do NOT use WS for Fine-Grained Interactions
Bad: Finegrained WS calls.
Presentation Layer
Business Layer
Java Application
WebSphere Application Server
Swing (view/controller)
Web Service Generated SOAP stub Apache SOAP
Web Services Best Practices
12_WebServices_BestPractices.ppt
Apache SOAP
SOAP over HTTP
EJB (controller/model)
© 2003 IBM Corporation
Page 29 of 44
IBM Software Services for WebSphere
Do NOT use SOAP over HTTP between Java Application Servers Presentation Layer
Browser
Bad: Using WS between WAS application servers (no firewall issues)
12_WebServices_BestPractices.ppt
WebSphere Application Server
WebSphere Application Server
SOAP Engine
JSPs
Web Service Generated SOAP stub SOAP Engine
Web Services Best Practices
Business Layer
SOAP over HTTP
EJB
© 2003 IBM Corporation
Page 30 of 44
IBM Software Services for WebSphere
Where to Use Web Services Interoperability between heterogeneous systems Defer the choice of Transport ƒAsynchronous messaging (MQ, SMTP) ƒSynchronous (HTTP, RMI/IIOP, local)
Get through firewalls To expose a common, language neutral interface and hide implementation details Minimize impact of changes in one system effecting other systems Service Oriented Architectures
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 31 of 44
IBM Software Services for WebSphere
Balancing J2EE protocols If the application server may have Java as a service requester, have that Java application make an RMI/IIOP call to an EJB instead of using SOAP over HTTP. Support both RMI/IIOP and web services interfaces ƒSupport SOAP over MQ for asynchronous requests
Non-Java clients
Java clients, Servlets/EJBs in other JVMs
SOAP/HTTP
RMI-IIOP
JAX-RPC Service IF
Remote EJB IF
EJB Impl
Web Services Best Practices
12_WebServices_BestPractices.ppt
JMS-enabled clients XML/JMS
MDB
Local EJB IF
Java
Servlets, EJBs in the same JVM
© 2003 IBM Corporation
Page 32 of 44
IBM Software Services for WebSphere
Choose the Protocol based on the Requirements Sync Message Queue HTTP
Queued (Latency)
Reliable Delivery
Open Standard
X
X
X
* (JMS – Jav only)
X
X
SMTP RMI-IIOP
Async Broadcast
X X
X
Web Services Best Practices
12_WebServices_BestPractices.ppt
X
X
X X
X*
© 2003 IBM Corporation
Page 33 of 44
IBM Software Services for WebSphere
Architecture for Firewall Challenges Requirement was for a 'rich' client experience over the Internet and Intranet ƒMost outside the firewall (using Network Address Translation) ƒFirst attempt was to engineer a fully HTML-based solution ƒDecided on an Applet client ƒHowever the presence of multiple firewalls between client and server made the use of RMI/IIOP impossible ƒSo, the client introduced a Web Services interface for their existing EJBs to allow client communication over HTTP and SOAP
WebSphere Application Server
Applet Generated SOAP stub SOAP Engine
Application Client EJB Client
SOAP-HTTP
SOAP Engine RMI/IIOP
EJB
Firewall Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 34 of 44
IBM Software Services for WebSphere
When to use Web Services for Firewall Challenges Client had to overcome skepticism about the maturity of the technology from both outside consultants and internal I/T management Web Services was the right choice even though Java ran on both ends of the conversation ƒOvercame limitations of RMI/IIOP with NAT firewalls ƒSimple and easy to implement over existing EJBs
Large requests/data being sent Although the Application client was 'snappier' than SOAP over HTTP, the Applet had acceptable performance The same architecture has been put in place in other customers as well ƒWebSphere's EJB clients have a strong JDK dependency; using Web Services as a communication mechanism allows more flexibility on the client end
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 35 of 44
IBM Software Services for WebSphere
Interoperability .NET Requestor
SOAP HTTP
Apache SOAP Requestor
WebSphere Requestor
SOAP lite Requestor
Web Services Best Practices
12_WebServices_BestPractices.ppt
SOAP HTTP
.NET SOAP Service (provider)
SOAP JMS
WebSphere SOAP Service (provider)
WebSphere SOAP Service (provider to incoming requests requestor sending requests)
SOAP HTTP
SOAP lite SOAP Service (provider)
© 2003 IBM Corporation
Page 36 of 44
IBM Software Services for WebSphere
Choosing the Granularity in SOA Unified Logical View ƒAn extension of the Facade pattern -- encapsulation of technology-specific details
Replaceable Component ƒisolating requestors from change in the implementation
Composable component ƒSo that you can create business process with the elements (BPEL4WS)
WSDL WSDL
WSDL
Coordinator Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 37 of 44
IBM Software Services for WebSphere
Unified Logical View WebSphere Application Server (WAS)
Facade
SOAP Engine
JAXRPC Empl Svc. IF
Employee Service Implementation
Empl. Service Session EJB
Business logic (decides which backends to call and merges data)
CICS and
CICS Adapter
JCA
JDBC Adapter
JDBC
custom code
Web Services Best Practices
12_WebServices_BestPractices.ppt
Mainframe
CICS Java Gateway
DB2
3rd party system
© 2003 IBM Corporation
Page 38 of 44
IBM Software Services for WebSphere
Replaceable Component In one insurance application, the broker obtains policy quotes from several different systems Think of this as a large-scale application of the Strategy pattern
Broker
getQuote
Insurer A Adapter Insurer B Adapter
Internal UDDI Registry
Insurer A
Insurer B
Insurer C Adapter Insurer C Insurer X Adapter
Adapter WSDL
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 39 of 44
IBM Software Services for WebSphere
Design Best Practices Web Services should be coarse-grained interfaces Web Services should be stateless ƒEven though it's possible to use transport state mechanisms they should be avoided
The fastest web service call is NO web service call ƒCache Data on the requestor when reasonable ƒMinimize the number of requests for the same information ƒlogically group information into larger-grain requests when possible
Consider asynchronous messaging instead of synchronous RPC-style interaction ƒasynchronous is a more loosely coupled interaction model
Business Delegate
Web Services Proxy
Client cache
Web Services Best Practices
12_WebServices_BestPractices.ppt
Load Balancer
Stateless Stateless Stateless Web Web Web Service Service Service
© 2003 IBM Corporation
Page 40 of 44
IBM Software Services for WebSphere
Use Session EJBs for multiple protocols In nearly all synchronous request/response cases, a stateless Session EJB should be the preferred vehicle ƒThe only way to have fine-grained security ƒWhen a client can use RMI-IIOP the performance gains are significant but local calls are the fastest ƒConsider the Business Delegate Pattern
Client
RemoteEJBDelegate
LocalEJBDelegate
RMI -IIOP
Java call
RemoteEJBInt erface
LocalEJBInterface
SessionEJBImpl
SOAP/HTTP WebServiceDelegate
ServiceEndpointInterface
DelegateFactory Delegate <
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 41 of 44
IBM Software Services for WebSphere
Performance - Approach Do not get hung up on performance concerns until you know the 'cost' of the web service ƒoften the business processing takes more time than the Web Service processing
Be smart about designing your application ƒcache data ƒsend references ƒsend the amount of data needed ƒsupport multiple protocols (don't only use SOAP over HTTP)
Create a prototype and test it under load Use the fastest SOAP Engine you are comfortable with Use the fastest XML Parser available ƒKeep your eye on the latest Apache releases
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 42 of 44
IBM Software Services for WebSphere
Specific Performance Results Smaller messages are better Fewer elements are better (less of an impact significant) simple is better than complex messages ƒavoid complex business objects ƒVector of 256 Complex Objects –256 * 4 * 100 = 100K – 13600 Elements or Tags
As messages get larger and more complex, the parsing time becomes a larger % of the processing time Use SAX instead of DOM for de-serializing XML into objects when you write custom deserializers. Code Practices ƒFor transferred objects being created from XML –Don’t initialize variables –Don’t set values in the Default Constructor –The values will be reset from XML
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 43 of 44
IBM Software Services for WebSphere
Resources Tutorials, articles, technologies WebSphere Developer Domain http://www7b.software.ibm.com/wsdd ƒDeveloper Works Web Services http://www.ibm.com/developerworks/webservices
Web Services Interoperability organisation ƒhttp://www.ws-i.org/
OASIS open standards organisation (ebXML etc.) ƒhttp://www.oasis-open.org/
Specifications: ƒBusiness Process http://www-106.ibm.com/developerworks/library/ws-bpel/ ƒTransactions http://www-106.ibm.com/developerworks/library/ws-transpec/ ƒSecurity http://www-106.ibm.com/developerworks/webservices/library/ws-secure/ ƒSOAP http://www.w3.org/TR/SOAP/ ƒWSDL http://www.w3.org/TR/wsdl ƒUDDI http://www.uddi.org/specification.html (public directory at https://uddi.ibm.com/ubr/registry.html)
ƒPreview Technology ƒhttp://www.alphaworks.ibm.com/webservices
Web Services Best Practices
12_WebServices_BestPractices.ppt
© 2003 IBM Corporation
Page 44 of 44
Related Documents
12 Web Services Best Practices
November 2019 5
Web Globalization Best Practices
May 2020 8
Best Practices For Web-design
November 2019 14
Best-practices
July 2020 22
