Bobby Woolf: WebSphere SOA and JEE in Practice
From archive: January 2008 X
The Feature Pack for Web 2.0 for WebSphere Application Server V6.1 has reached general availability status.
This means that WebSphere Application Server Feature Pack for Web 2.0, the feature pack for adding Web 2.0 to WAS 6.1, is now production quality. You can read more about it on the support page. There's also now an InfoCenter.
This feature pack was one of the WebSphere Software Early Programs that makes new features available in WAS 6.1 so that you don't have to wait for the next version of WAS and upgrade to it. One that is still in beta is the WAS 6.1 Feature Pack for SOA. Graduates of the program include the WebSphere EJB 3.0 Feature Pack and the WebSphere Web Services Feature Pack.
You may also be interested in New IBM Web 2.0 Resources and The New Language of Business.
Lately I'm thinking more about "What is a service?" and deciding that one of the most important aspects is what I'll call "service behavior."
When we talk about services (as in the parts of an SOA), we tend to talk about interfaces a lot. But it doesn't take long to decide that a service is a lot more than an interface. We care more about what a service does than its interface for interacting with it.
So why the focus on interface? Because, I think, an interface is more quantifiable; you can make it machine readable, describing it with a programming construct such as WSDL or a Java or .NET interface. A code compiler can then check code against that declaration for correctness. Inheritance creates rules for how one interface is allowed to extend another. Like I talked about in declared interfaces, interfaces are definite--either they match or they don't. That's easier for us technology types to deal with.
Behavior--what a service does--is more fleeting, which I think explains why us technology types deal with it less. But it's what the users care about most; the business people in an enterprise probably don't care much about the interfaces that services have, but they certainly care about what the services do and whether they do it correctly.
As I discussed in What Is Behavior?, behavior is a bit like dark matter--it can't be measured directly, only indirectly. We measure behavior indirectly through testing--providing known inputs and measuring the outputs to confirm that they meet expectations. There's been some efforts to describe behavior directly the way we do interfaces--declared behavior--but that doesn't really seem to have taken hold thus far. For the time being, behavior can't be described and measured directly like interfaces, only indirectly via testing. (And it doesn't help that testing tends to be treated as computer science backwater.)
So a service is both interface and behavior (and probably more). The technical people focus on the interface while the business people focus on the behavior. To do a good job with services and SOA, we technical people are going to need to focus on behavior as well.
I've started to capture some of these thoughts in service behavior.
Continuing with the theme of "What is a service?", I'm thinking it's best to think of it in terms of a "service contract."
The notion of a service is kind of squishy. It's a repeatable business task, hopefully well encapsulated so that it can be requested in a simple interaction and performed in a unit of work. That makes sense to business people and can be gathered as requirements, but is rather vague for us technical people (especially when trying to achieve business/it alignment). So we tend to fall back on a service interface as being the technical definition of a service. But as I discussed in service behavior, a service is a lot more than just its interface.
So how can we describe a service with some rigor? I'm coming to think of that as a service contract (which I discuss more on my wiki). In short, a service contract captures a service's behavior, interface, policies, and service level agreement (SLA). It's everything that a requestor and provider of a service must agree on so that the requestor knows what it can depend on and a provider knows what it must do.
For us technical people, I think that thinking of a service (a task) as a contract (an agreement that describes the task) will help us be a lot more specific and make good use of the ideals of SOA.
New and updated wiki pages:
Microsoft has produced a funny, star-studded video depicting Bill Gates' last day at Microsoft.
Bill Gates has announced that he's stepping down from his day-to-day roll as CTO at Microsoft so that he can focus full time on this philanthropic foundation. Last week at his keynote at the Consumer Electronics Show (CES) 2008, he showed a video of what that day will be like. It's pretty funny.
YouTube has a recording from the audience.
There's a better recording at Bill Gates Last Day At Microsoft: The Movie.
The official recording of the entire keynote, including the video, is on Microsoft's site under "Live Webcast: 2008 Microsoft CES Keynote".
There's a new set of fix packs available for WebSphere Application Server.
Check out the Latest Fix Packs for WebSphere Application Server support doc. The fixes apply to the Base, Express, and Network Deployment editions. The latest releases are now 22.214.171.124, 126.96.36.199, and 188.8.131.52.
For more info in general, see Keeping WAS Up-To-Date. Also check out IBM Update Installer for WebSphere Software and Update Installer for WebSphere Application Server V184.108.40.206 (onward) and V6.1.
I've posted a review of the book "SOA Approach to Integration" on Amazon.
My Amazon review:
This is a mediocre book that provides basic information but little of the insight that creates knowledge. As the title implies, it doesn't teach SOA in general, just how to approach application integration using SOA. Even in that, its treatment of the topic is reasonably accurate but superficial.
The book's six chapters are a reasonably logical overview of basic SOA and integration topics that finally culminates in the discussion promised by the book title.
Chapter 1 explains why integration is important, a topic that goes back at least as far as David Linthicum's Enterprise Application Integration. It lists numerous aspects of application integration without giving particular insight into any of them nor comparing them--a theme with this book's material.
Chapter 2 explains what SOA is. Its treatment of SOA is very superficial, little more than a technology that can be used for integration, and so should not be read as a thorough overview of why SOA is important. To understand SOA's importance, see Service Oriented Architecture For Dummies (yes, a Dummies book, but helpful!). One of the main advantages of SOA is its improved ability (as compared to other architectural approaches) to align IT and business, that is to make a company's applications and its business work in a more similar fashion. For a good discussion of business/IT alignment, see The New Language of Business: SOA & Web 2.0.
Chapter 3 is an XML primer, which seems pretty low-level for an architectural book. It explains a lot through XML and schema code examples, and even gets into an explaining and comparing SAX, DOM, and StAX. This chapter would better serve the book if it had focused more on the architectural decisions for XML and the implications of those decisions.
Chapter 4 is a primer on Web services and again gets fairly low-level for an architectural book. It explains the need to integrate heterogeneous systems, often connected via Internet technologies, and eventually discusses WSDL (but not SOAP!), WS-I profiles, and interoperability between Java EE and .NET. In between, however, it discusses patterns for integration by lifting material wholesale from IBM's Patterns for e-business and subsequent Redbooks on the topic. The diagrams in this book are straight out of the IBM materials, to the point of (what seems like) copyright violation.
Chapter 5 focuses on BPEL and what the book calls "process-oriented architecture." This is an interesting turn, since business process is not so much integration using services as it is a useful abstraction for implementing services--especially long-running ones--using other services. So whether this is integration of business functionality or composability of business functionality is debatable. In any event, the book then dives deep on BPEL features and code examples. Other books on BPEL may be more helpful.
Chapter 6, the last chapter, finally gets to the book's topic, application integration using SOA, POA, and Web services. Here, the book finally starts to explore the enterprise service bus (ESB), although for some reason considers the ESB to be not just a means for connecting to service providers, but a hosting environment for service providers as well! A lot of the material here is a rehash of Enterprise Integration Patterns; although this book's authors don't seem to have read that book, they discuss a lot of the same topics in terms of implementing Web services. Curiously, one section covers Java Business Integration (JBI), which only applies to Java, and yet the book never discusses a similar and more interoperable programming model, service component architecture (SCA).
In conclusion, what material this book covers, other books cover better. The advantage of this book is providing brief overviews of the material and tying it together better than separate books can. Yet this book's coverage of these topics is too low-level for architects, too brief for developers, and too superficial to teach the topics to readers who don't already know them. Other books on SOA and on application integration are better.
Disclaimer/qualifications: I am a coauthor of Enterprise Integration Patterns and work for IBM. The publisher (Packt) sent me a copy of this book and asked me to review it.
IBM has started a blog about the Impact 2008 conference.
I've talked about IBM Impact 2008, our big SOA conference that will be in Las Vegas, Nevada, USA on April 6-11, 2008. Mary Hall, one of IBM's marketing managers, has now started a blog on what's coming up: IBM Impact SOA.
The blog so far only has one posting, but it's a good one: If you attend Impact, you can also receive "20% off the public price of selected eligible IBM WebSphere education courses." So if you want to learn about SOA, the combination of the Impact conference and the education classes should be a pretty good way to go.