Composite MaterialsRon Ten-Hove's Weblog |
|
Monday Feb 05, 2007
WS-BPEL 2.0 (almost) out of the oven After over 3-1/2 years, the WS-BPEL technical committee (TC) at OASIS finally hit a milestone we have all been awaiting for a very long time: the TC has submitted WS-BPEL 2.0 to OASIS for approval as an OASIS specification. We will soon see some official announcements, webinars, etc., to properly introduce the completed specification. I'll just say that the new, soon-to-be standard is a huge improvement over the previous non-standard specification, BPEL4WS 1.1. Not only is the language more clearly and rigorously defined, but it also far more consistent, powerful, portable, and, in general, more useful. It has certainly been worth the wait! During this 3-1/2 year journey, I've come to better know and admire the TC members. I am also impressed with the willingness of the participating corporations to contribute time and talent (not to mention intellectual property) to the cause of creating a truly open web service-based business process language. I feel honored to work with such people, and know that we "done good." For me this hasn't been a mere intellectual exercise. Sun has "skin in the game", as a colleague of mine is fond of saying. WS-BPEL is supported in Open ESB, the Java EE 5 SDK (which includes a subset of Open ESB), and in the NetBeans 5.5 Enterprise Pack. I still am impressed with the Enterprise Pack; the interactive WS-BPEL debugger is, to me, still a Cool Thing. So take WS-BPEL 2.0 out for a spin; it is The Way to add stateful processes to your web services. Posted at 05:28PM Feb 05, 2007 by rtenhove in Service Oriented Architecture | Comments[2]
Friday Jun 30, 2006
What's right with SCA? My last posting expressed some of my misgivings about SCA, but also alluded to some features that I consider to be useful in SCA: the model-driven approach, the "smart wires" for connecting consumers to providers, and the fractal composition pattern.[Read More] Posted at 10:37AM Jun 30, 2006 by rtenhove in Service Oriented Architecture |
Thursday Jun 29, 2006
What's wrong with SCA? Service Component Architecture 0.9 is flawed in several ways. Its flawed definition of services makes building or using a service-oriented architecture problematic. Its aim to support multiple languages is laudable, but SCA is too complex and doesn't address key interoperability issues.[Read More] Posted at 02:01PM Jun 29, 2006 by rtenhove in Service Oriented Architecture | Comments[5]
Tuesday Jun 06, 2006
Implementing Service-Oriented Architectures (SOA) with the Java EE 5 SDK
There is a very good article on the Sun Developer Network, entitled Implementing Service-Oriented Architectures (SOA) with the Java EE 5 SDK. This is a nice walk-through, showing exactly how do develop a composite application using various Java EE 5 technologies, orchestrated by WS-BPEL 2.0. This really shows off the NetBeans 5.5 support for Java EE 5, and its built-in support for using Open ESB and GlassFish/Sun Java System AS 9. This article gives the complete tour of using the various technologies. I like the way the use of WS-BPEL 2.0 is folded into the tools; even debugging is integrated, allowing simultaneous debugging of the BPEL process logic and Java-based logic (such as EJBs). If you want to get your feet wet, in the new world of composite service applications, this article is a very good starting point. Posted at 02:41PM Jun 06, 2006 by rtenhove in Service Oriented Architecture |
Thursday May 11, 2006
JBI takes over Java EE 5!
The Java EE 5 SDK has been released, along with some NetBeans-based tooling. This is the first industrial-strength release of Java EE 5, so this will be of great interest to the EE crowd. What makes the SDK release really interesting (at least to me) is the integration of Open ESB (Sun's open-source JBI-based Enterprise Service Bus) into the SDK. This really points to the future of Java EE application servers: interoperation between the various EE technologies, using the web services model, enabled by the JBI infrastructure. Even more interesting is the NetBeans tooling that accompanies this release. This leverages a JBI service engine that executes composite applications using WS-BPEL 2.0, a SOAP-over-HTTP binding component, and the AS9 "Java EE Service Engine", which ties the various Java EE technologies to JBI transparently. Visual editors aid creation of BPEL, WSDL, and XSD documents; tight integration with Open ESB allows you to easily create JBI service assemblies and deploy them to the app server. Multi-language debugging is another great feature. This stuff is a pleasure to play with; check it out! Posted at 09:09PM May 11, 2006 by rtenhove in Java Business Integration |
Wednesday May 10, 2006
JavaOne JBI and Open ESB sessions It's back.... and a month early, this year. JavaOne in San Francisco starts next week. There are several sessions of note to the JBI and Open ESB communities:
Posted at 07:33PM May 10, 2006 by rtenhove in Java Business Integration |
Thursday May 04, 2006
Ask The Experts Session on JBI May 10th (10 - 11 AM PDT) I get to participate in a live web chat, along with other JBI experts and an audience loaded with good questions. Please join us! Sign up here. It will be held May 10th, 2006, from 10:00 AM - 11:00 AM Pacific daylight time. A transcript will be posted afterwards, for those of you who can't make it. As they say, good seats are going fast! :-) Posted at 02:57PM May 04, 2006 by rtenhove in Java Business Integration |
Tuesday Apr 25, 2006
Java EE 5 integrated into JBI (or is that the other way around?) Manisha Umbarje has recently blogged on Java.net about using SOAP over JMS. The really interesting part (to me) was how she did this: by using the built-in JBI service engine in the GlassFish app server. What's so cool about this? The Java EE technologies involved (from the web container in this case, but others can be used similarly) weren't altered at all (down to the binary level!) to make this happen. That's right: no changes! Manisha's article has a nice detailed picture of all the moving parts involved in this end-to-end demo (she implements both the consumer and provider sides), but the key takeaway is this: the servlet developer didn't have to do anything different to get SOAP over JMS to work properly. She uses standard web service technologies (JAX-WS et alia) in the normal fashion, without doing anything special to get JBI support. The real work of associating a logical service with a different binding type (in this case, the JMS binding) is accomplished at two levels, beneath the covers:
Posted at 08:23AM Apr 25, 2006 by rtenhove in Java Business Integration |
Friday Apr 21, 2006
Faults, Errors and WSDL Dave Orchard has recently blogged at length about error/fault abstractions from SOAP (over HTTP) "leaking" into abstract WSDL service descriptions. While I won't comment on the specific issues he raises (and he raises a lot of them -- check it out!), his comments raised, in my mind, a more general issue: how do we handle errors in a distributed SOA? The introduction of a network into any computing system raises the complexity enormously. The eight fallacies of distributed computing is a good summary of where the complexities come from. The average programmer is pretty used to composing an application out of reusable pieces of code from libraries, frameworks, etc. So when he writes
x = foo(y);
to call a library function foo, he isn't too concerned about errors occuring. However, if foo is implemented as a call to, say, a web service, we now have to consider a variety of issues. Number one on the list of eight fallacies is "the network is reliable." So now I have to ask, what happens when the call to foo fails? Obviously, the function needs to be able to convey the fact that it failed. For bonus points, it ought to tell us something about the failure. Also, is it possible that the service provider actually received the request to perform "foo", and it was the response that got dropped? Or was the request lost? These considerations introduce a lot of new application states, possible error recover paths, etc. Complexity.
How does this complexity fit into a WSDL description of foo? Should the abstract service description (portType or WSDL 2.0 interface) describe the possible faults that the underlying binding may (perhaps must) "leak"? If the answer is "yes", then the picture is pretty grim: the details of the binding must pollute the abstract service definition, and all our efforts to separate the two are pointless. If you are familiar with JBI, you know that the JBI expert group answered the above question with a firm "no". JBI separates service providers from communication bindings, such that a service can be bound to multiple endpoints simultaneously, and that the service remains completely decoupled from the bindings. So how does JBI handle the errors that arise from bindings? The answer lies in the JBI MessageExchange interface, and a couple of observations:
JBI's MessageExchange interface models this directly. In addition to all the normal, MEP-described states that an on-going exchange can enter, JBI adds an error state that abruptly ends the exchange. The cause of the error is detailed using a standard Java exception. Why did we do this? Because we know that a standard WSDL description of a service is not sufficient for describing all the possible states an interaction between consumer and provider will enter when conducted through a binding that uses a network. Implementations of consumers (and providers) must provide for these extra states. A good implementation will minimize the "leakage" of binding-driven error information. JBI's approach is, in a sense, the "worst-case scenario": from almost every state of the WSDL-described MEP an abrupt transition to the terminal error state can occur. This decouples the provider and consumer, but certainly doesn't eliminate the need to deal with failures. The eight fallacies have not been repealed!
Posted at 11:00AM Apr 21, 2006 by rtenhove in Service Oriented Architecture |
Tuesday Apr 18, 2006
Events as a first-class concept Event-based programs have been with us for a long time, and are getting more common. Things ranging from major business happenings to an XML element being parsed to a mouse movement are processed as events, delivered in various ways to code. Regardless of the use case, events are generated by a producer, and delivered to consumers (zero or more). Events can be delivered from producer to consumer synchronously (with the possibility of the consumer affecting the producer, by means of the event data), or asynchronously, where consumer is informed of an event separately from the producer "sending" it. Events are, in the Java world, usually represented by objects. The mechanism for the producer to send an event, and the mechanism used to receive an event, is generally by convention. JavaBean propertyChangeEvents and propertyChangeListners are a perfect example of a synchronous delivery mechanism. Code and convention, mixed with the safefy that a strongly type language gives us, are combined to make for a workable event handling system. What would it look like if we elevated the concept of events to the Java language itself? What if posting an event was a simple as:
post bean.Changed;
and registering for an event was as simple as:
Timer timer = new Timer(5000);
timer.start();
switch event {
case bean.Changed :
// ...
case okButton.Click :
// ...
break;
case timer.Expired :
// ...
break;
}
and an event processing loop looks something like:
do event {
case addButton.Click :
// ...
break;
case updateButton.Click :
// ...
break;
case entryField.MouseOverEvent :
// ...
break;
} until (done)
or even the ability to use events to convey the normal and abnormal termination of a thread:
Thread thread;
// Initialise the thread.
switch event {
case thread.Done :
break;
case thread.Aborted :
break;
postregister : // do this after this thread is registered for the events in this switch
thread.run();
}
You get the idea. Obviously this needs further thought, but the basic ideas are well-founded, since I have lifted them from the Forté language, TOOL.
Aside from the syntactic niceties, are there any other advantages to this? Decidedly yes! Firstly, it makes it very easy to wait for events from multiple sources. Next, the run-time is now "event" aware, so it can do some useful things, like find deadlocks, or provide management reports about the state of each thread that is blocked on events (very useful for debugging multi-threaded apps). This also avoids some of Java's low-level inter-thread communication mechanisms (Object.wait()/notify()), which are difficult for the average programmer to use, and make code fairly unreadable. This mechanism also makes the compiler more useful, since it adds some degree of type-safety to events. Just a thought... Posted at 08:19AM Apr 18, 2006 by rtenhove in Java | Comments[1]
Monday Apr 17, 2006
ESB and JBI I am often asked what the relationship is between Enterprise Service Bus (ESB) and Java™ Business Integration (JBI). There is often an assumption that JBI defines an ESB, but this isn't true. JBI defines a part of an ESB: the service container. The service container is the point where integration really happens: where IT assets (applications, protocols, databases, even data files) are turned into providers of services, consumers of services, or even both. Service containers have to deal with a wide variety of technologies, and "map" them to (and from) a standard services model. JBI is the perfect means for constructing such service containers. It provides a standardized, plug-in architecture for bringing the right technologies to bear on particular integration tasks. The WSDL services model built into JBI is perfectly aligned with the standard services model needed for the ESB. Pragmatically speaking, building service containers from standard components is far more economical than custom-building them, or using proprietary adapters. Service containers are not the whole ESB story. The ability to create a distributed set of service containers, linked by reliable messaging infrastructure, intelligent message routing, and administered centrally are all features outside the service container itself (and thus, outside of the scope of JBI 1.0). Several open-source projects have taken this basic idea, and are in the process of creating cool new ESBs. These include:
As you can see, JBI has found a place in the world of ESB! This is a great benefit to users of both the open-source ESBs and the commercial ones: JBI standardizes what is easily the most complex (and costly) pieces of an integration fabric. By avoiding having to reinvent application adapters for each new ESB implementation, the ESB architects can concentrate on innovating in what their ESB's do. This delivers more value to customers. Standardized integration components lower costs, and help avoid the hazards of vendor lock-in. So if you are looking for an ESB, look for JBI support. If you are exploring the ideas around ESB and SOA, check out the open-source projects listed above. Posted at 06:24PM Apr 17, 2006 by rtenhove in Service Oriented Architecture |
Friday Apr 14, 2006
JBI 2.0 It has been almost a year since we completed JBI 1.0. What do we do for an encore? Do JBI 2.0, of course! If you are attending JavaOne 2006 in San Francisco, please bring your JBI "wish list" to the following BoF (Birds of a Feather) session: Session Id: BOF-0089 Session Title: What's Next for Java™ Business Integration (JBI)? Track: Core Enterprise Room: Franciscan I Date: 17-MAY-06 Start Time: 21:30If you've been living with JBI 1.0 for the last year, as an implementor, component developer, or application developer, we want to hear from you. We want to make sure that we take JBI 2.0 in directions that are important to the current users of the technology. So bring that wish list, and the beverage of your choice (it will be 9:30 PM, after all!). Posted at 06:40PM Apr 14, 2006 by rtenhove in Java Business Integration | Comments[3]
Tuesday Apr 11, 2006
What Is Enterprise Service Bus? Enterprise Service Bus (ESB) is a way to create a service-oriented architecture. Leaving aside the marketing wars between various ESB vendors (and wanna-be vendors), the following are useful definitions of an ESB, and ones that we use in the Open ESB project. In a Sentence An Enterprise Service Bus (ESB) is a distributed middleware system for integrating enterprise IT assets using a service-oriented approach. In a Paragraph An Enterprise Service Bus (ESB) is a distributed infrastructure used for enterprise integration. It consists of a set of service containers, which integrate various types of IT assets. The containers are interconnected with a reliable messaging bus. Service containers adapt IT assets to a standard services model, based on XML message exchange using standardized message exchange patterns. The ESB provides services for transforming and routing messages, as well as the ability to centrally administer the distributed system. As a Bullet List An Enterprise Service Bus (ESB) is an infrastructure used for enterprise integration using a service-oriented approach. Its main features are:
Posted at 05:40PM Apr 11, 2006 by rtenhove in Service Oriented Architecture | Comments[4] Logical vs Physical Design Back in the bad old days life was pretty simple. Applications lived in a single computer process. Then came the idea that multiple processes could be used to attack certain problems. This rapidly evolved to encompass the use of multiple computers. Moore's law (and networking) made it seemingly inevitable. While hardware advances made horizontal and vertical scaling possible, software lagged. More recent high-level languages have included support for distributed computing (e.g., the Java Remote interface), but these required that the developer decide, during application development, how the application was to be distributed. Changing the physical distribution of the application was a huge pain, since it touched a lot of code. Even middleware technologies suffered from this shortcoming. The problem is the combination of writing a logical application (defining what is to be done), and physically partitioning it (defining where particular tasks are done). Ideally, these ought to be two separate steps, such that physical distribution of the application doesn't affect the logic of the application at all. In a really cool universe, the distribution can be changed on-the-fly, at run-time. The closest I've seen any language come to this ideal was the Forte O-O 4GL, TOOL. You developed the application using a repository full of the code artifacts you needed for you application. After designing and debugging the application logic, usually in a single "node" environment (a single address space), you went through a separate "partitioning workshop", where you decided where the pieces of the application would run in your particular environment. This didn't affect the application code at all; application logic and physical distribution were completely orthogonal. Those Forte Software guys were very clever. I joined Forte in 1997, when they were already working on R3 of this stuff. To me it was like magic. I'd spent years creating distributed C/C++ apps. If I'd had Forte, back then, I'd have been able to create those distributed applications in a fraction of the time, and I'd probably have less grey hair today! But time marches on. The creation of distributed applications is changing yet again. The olde way of creating large applications is from reusable code entities, frameworks, and even generated code (MDA, anyone?), and partitioning the result for execution in a distributed environment. The new way is termed "composition application development", and is founded on service-oriented architecture. Applications are now (largely) aggregations of (reusable) services, plus some connective glue. Services provide coarse-grained functions. Like the Forte 4GL, distribution of functions (services) within a SOA is orthogonal to the actual application logic. Calling a locally provided service is semantically identical to calling a remotely provided one. (This is one of the reasons JBI has only a single service invocation API, which hides locality from the consumer & provider.) Developing large applications is tough enough. Being able to disregard distribution issues during development and maintenance is truly a blessing to the developer, who has enough things on his plate. Forte Software managed to deliver such benefits to developers using the vehicle of a proprietary 4GL. Today we can realize the same advantages in application development using standards-based SOA. Posted at 03:35PM Apr 11, 2006 by rtenhove in Service Oriented Architecture | Why SOA?
Why bother with SOA? What benefits can it possibly generate for users? Isn't it just another instance of vendors hyping the latest acronym du jour? At its core, SOA is a good, sensible idea. It has existed in one form or another since the 1960's. The technical "perfect storm" of the Internet, TCP/IP, HTTP and XML have created the conditions for yet another incarnation of SOA to emerge. Due to the almost universal support for those technologies, this version of SOA has the potential to have a wider, longer lasting impact than any previous one. SOA is a software system structuring principle, based on the concept of services, which are offered (and described) by service providers. Service consumers read service descriptions, and using ONLY those descriptions, can interact with service provider, getting access to whatever functions it provides. That's a very general definition. Interaction between a consumer and provider requires some common computational infrastructure. In our shiny, new 21st century version of SOA, this means XML message exchange using web protocols, usually HTTP over TCP/IP. Service description is accomplished using WSDL. (This is my definition of SOA; others have much different (and usually more complex) ideas about modern SOA.) That's a very brief description of what SOA is. But why bother? In a word: decoupling. In the history of software engineering, coupling between "pieces" of a software system are like nails through pieces of wood: they make modification of the system design difficult, expensive, and time-consuming. Sofware systems are normally decomposed into some sort of modules (I'd use the term 'components', but that has become a loaded word!). Good decomposition leads to modules that have just a few, well-understood associations with other modules. Software architects talk about "connections" between such modules. Obviously the more connections there are, the more difficult it is to modify one of the modules without disturbing the others. Too much coupling between modules manifests itself in several ways:
z = foo.getW().getX().getY().getZ();
This is a long nail, hard-coding the association between five separate classes. (Karl Lieberherr has lot to say about this, by the way. Check of the Method of Demeter.) This is an example from O-O, but larger scale systems often exhibit the same close-coupling, but in ways that are not so obvious.
How to avoid those "nails"? Decoupling is the first step. You must minimize how much each module "knows" about the other modules in the system. At a very fine-grained scale, this is what OOP introduced: type abstraction helped hide class implementation details from "users" of a class. Similarly, SOA introduces mechanisms to help maximize decoupling at a course-grained scale. The service consumer (in SOA) bases all of its "knowledge" about a provider on the WSDL the provider has made available (typically through publication). This represents everything the consumer needs to know, so we have a small, well-defined interface between the two entities. Normally services a very coarse-grained (think "submit purchase order"); fine-grained services (like "find square root") don't make a lot of sense when I've got a perfectly good run-time library. The consumer, dealing with only XML messages, has no knowledge of how the provider implements the service. That's good: this avoids sneaky sorts of technical coupling. It also makes changes, such as switching to a different service provider, very easy: the declared interface to the provider is either compatible with the old one, or not. The provider is similarly decoupled from the consumer. In fact, the provider can make very few assumptions about the nature of the consumer, especially why the consumer is asking for a particular service. (There of course, can be higher-level application context information concerning this (a BPEL process instance, for example).) All of this adds up to a very good set of circumstances for reuse of the service in many different use cases. Indeed, when we talk about service composition, we are relying on this ability to reuse services in new ways without affecting the service implementation. Decoupling is the ticket to providing this capability. So what do I get from using a SOA?
Posted at 11:33AM Apr 11, 2006 by rtenhove in Service Oriented Architecture | |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||