1 / 19

Concrete Services

Concrete Services. Making SOA real. Service Orientation. What is Service-Orientation? …. Service Orientation. What is Service Orientation? A buzzword Hype Empty promises A chance for consultants to make more money with vague and undefined technology. Service Orientation.

harmon
Download Presentation

Concrete Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Concrete Services Making SOA real

  2. Service Orientation • What is Service-Orientation? • …

  3. Service Orientation • What is Service Orientation? • A buzzword • Hype • Empty promises • A chance for consultants to make more money with vague and undefined technology

  4. Service Orientation • Services are about creating loosely-coupled systems for maximum flexibility and evolution • No “objects” • No RPC • No assumption of platform • No code-generated remote proxy dependencies • No implicit assumption of network availability • Services are real, if you cut through the bull

  5. Pragmatic Services • Problem: Performance • Too many remote method calls creates latency • Remote events • Remote collections (“n+1 query problem”) • Object-orientation works great in-memory, but … • Solution: Avoid round trips; batch calls instead • No remote events • No remote methods • No remote properties • In short, no remote objects • Remote objects create too many remote calls • Look to collate multiple calls into one (e.g., DAOs)

  6. Pragmatic Services • Problem: Evolution • Interface-based remoting creates tightly coupled proxies • Implies that if the interface changes, so must the proxies • But not all clients want to recompile just to support your changes • Works great when both clients and servers are controlled by one entity, but not across entities • Solution: Avoid interfaces • Prefer to exchange loosely-bound data • Untyped collections (Lists, Sets, Maps, etc) • Database result types (DataSets, RowSets) • In short, “messages”: JMS, MQSeries, TIBCO, MSMQ • But this requires greater documentation discipline

  7. Pragmatic Services • Problem: Exponential message defintions • Developers start creating a new message type for every possible operation/message • NewUserRequestMessage, NewUserResponseMessage, … • Creates confusion and duplication of effort • Solution: Create “action” vocabulary • HTTP uses 7 “verbs” to indicate message intent • Create a similar scheme for your message types • So only one “User” type is needed, plus “Create”, “Update”, “Retrieve” and “Delete” actions for each • Allows for easy extension and intermediary manipulation

  8. Pragmatic Services • Problem: Online/offline support • Network infrastructure is not reliable • All ORPC toolkits assume 24x7 network support • So if the network disappears, client proxies are toast • Clients aren’t always online, anyway • Email clients, for example, work just as well off- as online • Networks are many places, but not everywhere • Solution: Use reliable messaging infrastructure • Let messaging plumbing hold the message for delivery • Retries, transactional delivery, intermediaries • Can use other tools, too—filesystem, database, …

  9. Pragmatic Services • Problem: Interoperability • The world is not flat, nor is it homogeneous • J2EE, .NET not going away, Ruby/Rails making a surge • It’s a fact: You’ll have to talk to the Other Guys • But objects don’t serialize well across platforms • Binary formats are close, but not identical • Typesystems don’t match • Objects don’t serialize well to XML, either • Witness the object/hierarchical impedance mismatch • Solution: Don’t send objects, send XML • Messages are two parts: headers + payload • In other words, SOAP 1.2 messages • XML Schema is helpful… but not required!

  10. Pragmatic Services • Problem: Transport • Everybody’s got their favorite transport: HTTP, TCP, SMTP/POP3, MSMQ, JMS, … • Standardizing on one doesn’t fit all situations or needs • Asynchronicity, fire-and-forget, pub-sub, broadcast, security • No one transport offers all options • Solution: Transport agnosticity • Don’t rely on just one transport • Build messages that can flow across any transport • Implies addressing and routing information are in message • WS-Addressing

  11. Pragmatic Services • Problem: Scalability • When object systems try to scale, difficulties arise • Object identity creates contention • Simple caching fails on 2+ machines • Cache update propagation is difficult to achieve with objects • Object-based scaling systems (EJB, MTS/COM+) are complex • Solution: Assume for scalability • Don’t hold request context across requests • Make messages context-complete • Don’t cache writeable data in memory • Only read-only or read-mostly data is safe to cache • Be location-neutral • You know it’s remote, you just don’t care where

  12. Pragmatic Services • Problem: Legacy code • How does legacy COM/COM+/Java/CORBA/C++/C# fit in? • Much less CICS, Tuxedo, … • Orchestration implies big buy in (BizTalk, BPEL) • Solution: Legacy code is just another transport • Place a service adapter in front of the legacy code • Messages in, messages out

  13. Pragmatic Services • Problem: Security • When adopting transport agnosticity, can’t rely on the transport (HTTP/S) for confidentiality • Many transports aren’t secure by default • Mustn’t assume the firewall provides perfect security • Solution: CIA at the message level • Provide Confidentiality/Integrity/Authenticity at the message level, not at the transport level • XML Encryption, XML Digital Signature, and other specifications provide confidentiality and integrity to XML messages • WS-Security discusses authentication forms • Java Crypto API provides same for Java messages • JAAS provides authentication & authorization for Java

  14. Pragmatic Services • Problem: Reliable delivery • Some messages cannot be lost (legal, medical, financial) • Not all transports provide best-effort delivery • No transport can provide absolute guaranteed delivery • Message loss not highly visible in small LAN environments • Despite this, messages must still get through • Solution: Reliable messaging • Elevate Quality-of-Service considerations into the message itself • At-Most-Once, At-Least-Once, Once-And-Only-Once • Transacted delivery • Transport-agnostic, though transports may help guarantees

  15. Pragmatic Services • Problem: Firewalls and perimeter security • Integration means crossing trust boundaries • Firewalls are often not under development control • VPN doesn’t solve the problem • often grants “too much” access • infrastructure support grows exponentially with new partners • Recent legislation only heightens security paranoia • Solution: Use transport agnosticity to respect it • Put an intermediary in solely to bridge the firewall • May require moving across a different transport (HTTP) • May do application-level firewalling of messages, as well

  16. Pragmatic Services • Problem: Multiple identity domains • Credentials aren’t scoped to the system • Users won’t span all parts of the system • Authorization often varies per system/user tuple • Some users won’t even be users, but silicon-based lifeforms • IT uses a variety of credential/authorization systems • Kerberos, Passport, LDAP, home-grown, … • Solution: Identity and authorization federation • WS-Trust creates a “web of trust” and brokered auth • Messages can carry multiple credentials if necessary

  17. Pragmatic Services • Problem: How do I get started? • Solution: Depends • All: SOAP 1.2, WS-Addressing, XML Schema • These are simple enough that you can hand-roll your system • WS-Transfer, WS-Enumeration aren’t far from REST • Then consider WSDL 2.0, WS-RM/WS-Reliability, WS-Eventing, WS-Notification-and-friends, WS-Security-and-friends • Java: JAX-WS, JAXB, XMLBeans, JMS/EJB MDBs, … • Look for tools that give you direct access to the SOAP message when you want it but only when you want it • Look for tools that aren’t tied to a particular transport • Don’t use tools that generate WSDL and proxies for you (at first) • Don’t treat XML services as a “black box”; it’s grey, at least

  18. Conclusion • Services do hold promise for integration • … but it’s not going to be the easy “flip-of-the-switch” story that your vendors will try to sell you on • Services seek to minimize coupling across units • … but remember that some coupling is necessary; the trick is to choose when and where • Services can be deployed incrementally • … starting with your object-based systems and slowly evolving them into message-based components

  19. Credentials • Who is this guy? • Independent consultant (Contact ted@tedneward.com) • Speaker • No Fluff Just Stuff, TechEd, JavaOne, VSLive!, and others • Java Community Process EG member (JSR 175, 277, …) • Author • Pragmatic XML Services (Pragmatic Press, forthcoming) • Effective Enterprise Java (Addison-Wesley, 2004) • Server-Based Java Programming (Manning, 2000) • C# in a Nutshell (with Drayton, Albahari; OReilly, 2001) • SSCLI Essentials (with Stutz, Shilling; OReilly, 2003) • Papers at http://www.neward.net/ted/Papers • Weblog at http://blogs.tedneward.com

More Related