SOA.WRK.
Web 2.0 vs. SOA, Part II of the SOA debate
In Part 1 of this series , we discussed REST vs. SOA. REST is a concept derived from Web version 1.0. Will a new and improved Web 2.0 change anything?
What is Web 2.0?
Many people simply define "Web 2.0" as blogs, wikis, RSS feeds and social networking applications. But all of these web applications also exist in Web 1.0 time. So, what exactly is Web 2.0? Web 2.0 is not a new version of the Web, but started as the name of an internet business conference held October 5-7, 2004 at the Hotel Nikko in San Francisco to discuss the theme "The Web as Platform." This was an invitation only conference for current and former CEOs, executives, VCs, and analysts to network and exchange ideas on how to make money again through the Web after the crash several years ago.
The Web 2.0 conference was successful and widely-reported. The term "Web 2.0" became popular, but its definition remains hotly debated. Everyone had their own view of what Web 2.0 was all about. A year later, Tim O'Reilly, who organized the Web 2.0 conference with John Battelle, provided both a short definition and a more detailed explanation of the term. However, there are still many who believe "Web 2.0" is nothing more than a marketing hype.
The proponents of Web 2.0 generally accepted O'Reilly's definition which defines Web 2.0 as the networked platform where Web 2.0 applications exhibit some of the following attributers:
- The Web as Platform
- Harnessing Collective Intelligence
- Data is the Next Intel Inside
- End of the Software Release Cycle
- Lightweight Programming Models
- Software Above the Level of a Single Device
- Rich User Experiences
Core vs. Edge vs. Convergence
"The Web as Platform" is not a new idea. Netscape promoted this concept in the 90s while trying to compete against Microsoft. So are the other Web 2.0 attributes identified by O'Reilly. What really differentiates Web 2.0 from Web 1.0? O'Reilly believes that Web 1.0 companies failed because their business model and/or applications targeted only the head or core of the web such as clients from large Fortune 500 companies. Web 2.0 applications address the tail or edge of the web which includes average users like us. However, the head vs. tail (or core vs. edge) argument can not explain why similar web applications failed in Web 1.0, but later succeeded in 2.0 (e.g., Nupedia vs. Wikipedia).
Personally, I think the key difference between Web 1.0 and Web 2.0 applications is the convergence of the content publishers and consumers. In Web 1.0 applications, consumers generally have no impact on the content published. But consumers of a Web 2.0 application can make changes directly to the content served by the application. The symmetrical relationship between publishers and consumers enables the convergence of alternative views that fosters collaboration on content development and forms communities of like minds as seen in blogs, wikis, tagging, and social networking sites. The resulting convergent web applications agree with the intuitive definition of Web 2.0 that most people have.
Round 2: Web 2.0 vs. SOA
We have made many advances in web technologies since the crash. Web applications from five years ago may seem dated now, but from a functional point of view, there is no significant difference between them and today's Web 2.0 applications. For example, a wiki, like Nupedia, with selected content editors is normally considered a Web 1.0 application. It can become a Web 2.0 application by allowing everyone to register as an editor. Yes, there will be new obstacles, like scalability, spam, and vandalism, to be addressed in the 2.0 version. But both versions provide basically the same distributed content publishing and management services. The architecture of web application is great for such problems. For other problem domains, this architecture may not be a good fit.
SOA, on the other hand, is an architectural style applicable to general problems. SOA may not be optimized for problems solved by web applications, but it is a good architectural style for solving many other types of problems. In fact, many Web applications incorporate SOA as the solution for accessing services provided by other components or exposing its service interface definitions to others. Web applications are great for specific problem domains, but not as the replacement for SOA in other types of problem domains.
BTW, this year's Web 2.0 party, now called the Web 2.0 Summit, is being held this week in San Francisco. The new theme is "Facebook/Myspace... as a Platform," which is simply the 2.0 version of "eBay/Amazon... as a Platform" of a generation ago.
Posted at 10:46PM Oct 16, 2007 by tientienli in Sun |
The SOA philosophy --- a new perspective of Unix principles
This year's JavaOne was great. I met new and old friends, went to the Startup camp, attended interesting sessions and BOFs, and had some wonderful discussions with others. The most interesting discussion I had was over a breakfast at the Moscone Center. I had a chance to explain my work to a Unix programmer who had not been exposed to the concept of SOA. After a few unsuccessful attempts to explain the concept of composite applications to him in a way he could understand, I suddenly realized that the service composition principle used in SOA is very much a modern application of old Unix techniques like co-routine and pipe. Using several Unix examples, I successfully explained to him that building a composite application using service components is much like building a pipelined shell command:
cat `find ~/bin/ -name "*.sh"` | sed -e '/^ *#/d' | wc -l
After our discussion, he was happy to learn that many of his familiar Unix principles have modern application in the SOA world. I was excited too and wanted to study more of the parallels between SOA and Unix principles.
The compositional approach of building solutions made popular by the Unix operating system is very similar to the core concept of our design-time tools. However, when designing a set of tools for building SOA-based composite applications, our objective was to apply modern software concepts such as aspect oriented programming and enterprise integration patterns, not Unix principles.
Mapping Unix design principles to SOA was very interesting. Like seeing features on images of Mars developed over time, Unix principles can be interpreted using modern software concepts. For example, the famous "Unix philosophy" characterized by Dr. Doug McIlroy:
Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface.
can be translated into SOA terms, First, programs are replaced by services. The one thing that a service should do well is the WSDL interface it implements. Then, how to make services work together has become a much more complex problem in the modern computing environment. In addition to input and output data, there are policies between the service consumer and the service provider covering, e.g., messaging, security, and transactional context. Finally, all services should handle XML streams, the universal interface.
One thing that I found interesting after comparing similar software concepts between Unix and SOA is the directions and degree in which a concept expanded or evolved over the last 30 years. I will come back to this subject in the future. Looks like there is useful trending information there.
Posted at 10:17PM Aug 23, 2007 by tientienli in Sun |
JavaOne 2007
I will be attending JavaOne this year presenting a technical session on CASA (TS-8683). The following is the overview slide of the presentation providing a good summary of its content. I am looking forward to meeting some old friends and making new ones at the conference next week.
Posted at 10:12PM May 02, 2007 by tientienli in Sun |
Web Service Virtualization
In many Web service implementations, the protocol specific messaging code often built into both the consumer and provider of the service.
This makes it difficult to port the service to other protocols. A common solution to this problem is to separate the messaging aspect out from the consumer or the provider code. The resulting generic consumer or provider can be easily ported using other protocols.
Abstracting the physical service protocol out from web service code is a form of virtualization. Wikipedia, for example, define "Virtualization" as:
"A technique for hiding the physical characteristics of computing resources from the way in which other systems, applications, or end users interact with those resources."
1.virtualization.client-side.protocol
Web Services Invocation Framework (WSIF), is one of the early system that support client-side virtualization of the service protocol. It allows a client to interact with abstract services independent of protocols. The client can be statically or programmatically configured to use a specific service provider. This type of virtualization is supported by most JBI implementations including OpenESB.
2.virtualization.server-side.protocol
OpenESB also supports server-side virtualization of the service protocol. This allows, for example, a generic service provider to interact concurrently with multiple consumers via different protocols. Each consumer interacts with a virtual service provider using a specific protocol.
3.virtualization.others
Like the service protocol, many other physical characteristics of web service can also be virtualized to meet different requirements. For example, the service policy definition attached to a service can be virtualized. This will allow the consumer and the provider to interact using different policy definitions. Another example is high demand service applications. The physical provider of such applications may be virtualized using clusters or grids to provide necessary computing resource needed.
Posted at 08:31AM Apr 24, 2007 by tientienli in Sun |
Composite Application - Part 2, Service Component Model
In part 1 of this series, a brief definition of JBI component was given:
"A component in JBI is a logical service defined by one or more WSDLs. It interacts with components in other containers via operations/messages specified in WSDLs."
1.component.interface + implementation
We will provide a more detailed description of the service component model used in the composite application projects. In our model, a component has:
-
An interface definition specified by an xml-based descriptor file,
jbi.xml (of service unit). The descriptor specifies provides (input) and
consumes (output) endpoints of the component. The endpoints are typed using
portType (WSDL 1.1) or interface (WSDL 2.0) defined in a WSDL. An example of
the jbi.xml file is shown below:
<jbi ... version="1.0"> <services binding-component="false"> <provides endpoint-name="partner" interface-name="ns1:portType1" service-name="ns0:SynchronousSample"/> </services> </jbi> - An implementation consisting of deployment artifacts needed by the specific component container. For example, a typical BPEL component deployment artifact is a jar collection of BPEL sources and associated WSDL, XSD, and other data files.
2.component.composition
Components can be composed by connecting endpoints from one component to another. The connection is specified in an application level descriptor file, jbi.xml (of service assembly). An example of the connection specification is show below:
<connections>
<connection>
<consumer endpoint-name="port1" service-name="ns1:service1"/>
<provider endpoint-name="partner" service-name="ns2:SynchronousSample"/>
</connection>
</connections>
Given a set of components, the composite application project system can
auto-generate most of the necessary connections by matching
the consumes and provides endpoint type. We also provide a GUI-based Composite
Application Service Assembly (CASA) editor
for editing component connections.
3.component.model.comparison
A frequently asked question is how our component model compares to other SOA component models, e.g., Service Component Architecture (SCA) . There are some minor differences, but overall the two models are very similar. For example, if we replace terms in the SCA component diagram shown below by the corresponding JBI terms, the diagram very much describes the composite application component model.
CompApp Model SCA Model
consumes <-> reference
provides <-> service
connection <-> wire
One can consider our component model equivalent to the SCA model restricted to WSDL based interfaces. SCA supports two interface types:
- Java interfaces
- WSDL 1.1/2.0 interfaces
Posted at 07:33AM Mar 07, 2007 by tientienli in Sun |
Aspect Oriented Programming w/Domain Specific Languages (AOP/DSL)
Several friends asked me to explain the link between the message-based and the traditional approach of aspect composition discussed briefly in my last post. I will try to illustrate this concept with an example.
The "hello world" service is probably the simplest example of a service. However, when implemented as a http/soap based service in, e.g., Java, the code can be very complicated. Using the traditional AOP, the soap messaging aspect can be separated out from the core logic as follows:
-
First, write the code for the core logic in a short program
String msg = receiveMessage(...params...); sendMessage(msg, ...params...); -
Then, define aspects linking point-cuts to advices
execute soapMessageRecive(...) before receiveMessage(...) execute soapMessageSend(...) after sendMessage(...) -
Finally, implement the massive advice code to handle soap messaging
MessageFactory mf = MessageFactory.newInstance(); SOAPMessage msg = mf.createMessage(); SOAPPart part = msg.getSOAPPart(); SOAPEnvelope env = (SOAPEnvelope) part.getEnvelope(); SOAPBody body = env.getBody(); ...
This is nice... but feel like busy work because we restructured the service code without reducing its complexity. This often makes me wonder something important is missing in AOP. There must be a hidden door somewhere waiting to be discovered.
OK, let's try to implement the same service using the composite application platform introduced in Netbeans Enterprise Pack. We will need a SOAP binding component, and a BPEL or EJB service engine for the core logic. Once these containers are installed, we can implement the service component as follows:
-
First, write the code for the core logic in a short program
String msg = receiveMessage(...params...); sendMessage(msg, ...params...); -
Then, define aspects linking point-cuts to advices
connect myEchoPort to SOAP BC's echoPort -
Finally, implement the advice code to handle soap messaging in a WSDL
... <wsdl:service name="echoService"> <wsdl:port name="echoPort" binding="myns:echoBinding"> <soap:address location="http://localhost:12345/echo"/> </wsdl:port> </wsdl:service>
Yes, WSDL can be run in BCs! The important difference between this version and the one implemented using the traditional AOP approach is in the last step. Instead of using the same implementation language as the core logic, the aspect logic is implemented in its own domain specific language, in this case, WSDL. This is the hidden door I was earching for in AOP before. After separating aspects out from the core logic, why not run each aspect in its domain specific container and implement it in its own language, e.g., WSDL, XSL, SQL, XQUERY, etc.
There are many ways to broaden the conventional application architecture. One can extend primary programming languages, e.g., Java and C#, with facilities to handle domain specific logics. Annotation is a good example. Microsoft's LINQ is also a great example of such an approach. Another approach is to allow applications to be composed from components implemented in different languages. We refer the later approach as Composite Application Development (CAD) or Composite Application Programming (CAP).
Posted at 09:28AM Feb 27, 2007 by tientienli in Sun |
Composite Application - Part 1
In Netbeans Enterprise Pack 5.5 released last year, we introduced a new project system, called Composite Application Project, for building SOA applications targeting the Open ESB runtime based on JSR 208, the Java Business Integration (JBI), specification. Early this year, when InfoWorld selected Netbeans 5.5 for the Java IDE Innovator of the 2007 Technology of the Year Awards, a composite application project was shown in the middle of the screenshot for the award.
This is an honor for us involved in building this project system. Although the code has been released in open source for almost a year, we did not have much time to write to explain its design to our users. I hope this series of short blogs will provide some information to those interested in learning more about the composite application project system.
1.Composing.Aspects
To explain what a composite application is, we need to re-examine the traditional application model. A monolithic business application may be decomposed into distinct parts according to its functionality. For example, a service application may be broken into following functional parts:
- a core business logic component;
- a messaging component handling external communication functions; and
- a set of XML transformation utilities.
As alternatives to the traditional method of application development, many techniques and methodologies have been proposed to show how to weave aspects into an application. We discovered that messages are a good composition tool. By using messages as threads, aspects can be stitched together into an application. We call such an application a "Composite Application".
We were inspired by earlier work of others. In late 70s and early 80s, researchers found that better systems could be build by distributing functions such as database, logging, and others into separate servers, creating "Distributed Systems".
2.JBI.Logical.Services
In 2004, we studied early versions of the JBI spec. JBI is a very nice SOA/BI spec with a Java implementation. It proposed a WSDL/XML standard based SOA/BI application platform with detailed design including:
- a component container spec for plugging in component containers;
- a message exchange spec for defining component interactions; and
- management and other specs.
In our design, aspects of composite application are mapped to JBI components. Messages are mapped to WSDL messages associated with operations of a port type. So, in JBI, a composite application is implemented as a collection of interacting JBI logical services defined by a set of WSDLs.
The official JBI term used for component and composite application are:
- Service Unit - a component of a container type;
- Service Assembly - a composite application of components.
Posted at 09:52PM Feb 20, 2007 by tientienli in Sun | Comments[1]