Poster: Werb Service Standards

InnoQ has this amazing poster that shows an overview of the Web services standards. There is also a PDF version.

SOA, CEP, Event-driven Architecture

Again EDA (Event-driven Architecture) and its relationship with SOA is being discussed. In my humble opinion EDA can use SOA to maximize its benefits. There is also an excellent article from SearchWebServices.com about SOA and CEP (Complex Event Processing): "SOA + CEP = 'a new physics of computing'.

When to use SOA and when to use EDA?
The answer comes from this post (Jack van Hoof's blog):

In contrast to SOA, EDA provides a way of loose coupling. EDA is not a synchronous command-and-control type of pattern, but just the contrary: an asynchronous publish-and-subscribe type of pattern. The publisher is completely unaware of the subscriber and vice versa; components are loosely coupled in the sense that they only share the semantics of the message.

If you are seeking to support strong cohesion in the business processes, situations where all process steps are under one control, SOA is the way to go. The command-and-control style of SOA - in general – is applicable to:

• Vertical interaction between the hierarchical layers of functional decomposition
• Functional request-and-reply processes such as man-machine dialogues; the user waits for an answer
• Processes with a transactional nature which require commit and rollback facilities
• Data enrichment in a message to be published to bring the message to its full content in a formal format

If you are seeking to support independency between business process steps, EDA is the way to go. This style of architecture is appropriate in federated and autonomous processing environments. Recognizable situations where EDA might be applicable are:

• Horizontal communication between tiers in a process chain
• Workflow type of processes
• Processes that cross recognizable functional organization borders, external (B2B) as well as internal

SOA=Command and Control, EDA=Business Process Chain
This same post presents the "SOA X EDA" view:



EDA Overview
Brenda Michelson wrote an EDA overview in her blog (in fact, the best definition I've read).

Also from this post from Brenda' blog are the pictures below:

1. Complex Event Flow

2. EDA Implementation Components

What Is Software Architecture?

In this blog I write posts and more posts about SOA, ESBs, RIA... ...all these subjects and terms are related to Software Architecture. But, what is software architecture? Besides definition that you can find at Wikipedia, there is an excellent source of many definitions at SEI.CMU website. SEI is the Software Engineering Institute at Carnegie Mellon University.

Below some examples:

• First, architecture defines elements. The architecture embodies information about how the elements relate to each other. This means that architecture specifically omits certain information about elements that does not pertain to their interaction. Thus, an architecture is foremost an abstraction of a system that suppresses details of elements that do not affect how they use, are used by, relate to, or interact with other elements. In nearly all modern systems, elements interact with each other by means of interfaces that partition details about an element into public and private parts. Architecture is concerned with the public side of this division; private details of elements—details having to do solely with internal implementation—are not architectural
• Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution (note from Davi: this is my best definition ever)
• A software system architecture comprises
  - A collection of software and system components, connections, and constraints.
  - A collection of system stakeholders' need statements.
  - A rationale which demonstrates that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system stakeholders' need statements.
• [Crispen 94]: An Architecture, as we intend to use the term, consists of (a) a partitioning strategy and (b) a coordination strategy. The partitioning strategy leads to dividing the entire system in discrete, non-overlapping parts or components. The coordination strategy leads to explicitly defined interfaces between those parts.

RIA versus JSF?

To be correct, the article's tittle is "RIA renaissance versus JSF dark ages?", from SearchWebServices.com. In this post I just want to write some excerpts:

- "Developers have a choice of tools and technologies for RIA, including Flash from Adobe Systems Inc. and the more generic Ajax, and they can even mix and match as best suits individual projects, he said during a Burton telebriefing on Tuesday. But they need to beware of tools and technologies that are inflexible. The theme of the briefing, "Build for Today, Architect for Tomorrow," was that architects and developers should select technologies and approaches to today's projects that are flexible, agile and not too complex, so that today's application can be modified to fit future needs."

- "Our confidence is pretty weak in JSF in general because we continue to get feedback from customers saying that the platform's too complicated..."

- "...Using Web frameworks like Shale and JSF and Struts to do RIA works, but it's inflexible. Because your interface is being generated rather than being coded, you don't have as much flexibility on how it's presented..."

- "What we're talking about is not Java in general, but a particular aspect of Java, which is the Java enterprise edition and that we do believe is overly complex to the point where it actually hinders productivity."

- "You can use them in combination. Many times we find that Ajax is the most powerful solution especially for enhancing existing Web apps, taking existing Web sites and adding some graphical capabilities to them. But sometimes it falls short and Flash or Java applets might be a better choice."

I completely agree.

JBossESB 4.0 Released

JBossESB 4.0 was just released. According to this news the next version (4.x?, 5.0?...) will be ready later year (2007). Below some features in this release:

• support for general notification framework. Transports supported include JMS (JBossMQ, JBoss Messaging and MQSeries), email, database or file system.
• trailblazer example.
• many quickstart examples to get you going.
• support for data transformations using Smooks or XSLT.
• listeners and action model to support loose-coupling of interaction steps.
• content based routing using JBoss Rules or XPath.
• support for registries, using JAX-R and jUDDI out-of-the-box.
• gateways to allow non-ESB aware traffic to flow into the ESB.
• high performance and reliability (in use by a large insurance company for 3 years).(*)

* probably it refers to the second-largest insurance company in Canada, where this ESB handles data from 3,000 employers and more that 2,0 million customers.

See an abstract view of ESB/SOA infrastructure:

SCA, SDO and DAS

Times from times I have read about standards like SCA and SDO in a SOA environment. This article was written by three IBM guys and it presents an overview of SDA and SDO.

Apache Tuscany project aims to create a infrastructure that simplifies the development of SOA-based systems. This project uses independent technology and standard that together provide:

• SCA: Service Component Architecture (SCA) enables composition of service networks through assembly of existing and new services;
• SDO: Service Data Object (SDO) provides a uniform interface for handling different forms of data, including XML documents, that can exist in a network of services and provides the mechanism for tracking changes;
• DAS: Data Access Service (DAS) provides a simple SDO interface to relational databases.

(image from Apache Tuscany website)

These specifications can be found at OSOA web site and Apache Tuscany provides input for them.

Here the SCA and SDO definitions from Tucany Project:

- SCA: "SCA provides developers with a simple, business-oriented, model for creating systems based on a service oriented architecture. It manages infrastructure complexities such as transactions, security and reliable messaging and frees the developer to focus on providing business function. The solutions developed using SCA can be changed declaratively to alter infrastructure capabilities or application configuration properties to meet changing business requirements. For example, infrastructure capabilities such as security policies may change from one environment to another and can be changed without the need for re-implementation. Application configuration may also be changed in this way, for example, the currency quoted by a stock quote feed may be changed though the SCA configuration mechanism."

- SDO: "Service Data Objects simplify and unify SOA data access architecture and code in a heterogeneous environment. SDO is programming language neutral. Within Tuscany it is being implemented in Java and in C++."

MULE ESB (II): 500,000 Downloads and counting...

According to this news at ebizQ.com, the open source ESB, MULE, has already more than 500,000 downloads.(image from MuleSource.com)

By the way, see below the environments where MULE can operate:

- Operating System: Red Hat / Fedora Linux, Windows Server, Solaris SPARC / x86, Suse Linux, Ubuntu / Debian Linux, FreeBSD, Mac OS X

- Java: 1.4, Java 5, 6 and 7

- Transport: JMS, MQ Series, Tibco, Oracle AQ, Web Services/SOAP, FTP, HTTP/HTTPS, SSL/TLS, Multicast, IMAP, In-Memory, JBI, JDBC, Multicast, SMTP/POP3, RMI, and more...

- Integration: Spring, JBI, EJB, GigaSpaces, HiveMind, JavaSpaces, JCA, JNDI, JOTM, JTA, PicoContainer, Plexus

- Web Services: Apache Axis, XFire, REST, SOAP, WebMethods Glue

- Application Servers: WebLogic, WebSphere, JBoss, Apache Tomcat, Geronimo, Jetty, JRun, Oracle, Resin

Good enough :-)?

MULE ESB: A Case Study

Eugene Ciurana (from Walmart.com) wrote this article that you can find at TheServerSide.com. The subject is ESB, more specifically MULE ESB. Version 1.3.3 is "fresh from the oven" with 27 issues/functionalities implemented since 1.3.2.

Eugene's text starts with a simple question: "Why are ESB needed?". After this there is an interesting comparation between the ESBs from TIBCO (Matrix BusinessWork), SUN (openESB), Progress Software (Sonic ESB), IBM (WebSphere ESB) and, of course, Mule ESB (open-source, MuleSource Inc.).

He points out some advantages of Mule ESB:

* Active open-source community and commercial support available
* State of the art implementation and ability to run under Java 5/6
* Number of relevant features out of the box
* Response time from vendors within 48 hours (average time for the winners was 2 hours)
* Ease of installation and deployment
* Ease of configuration and expansion
* “Codeless” integration with legacy, third-party, and commercial products
* Ability to drop in/pull out without incurring in lock-in or ancillary product dependencies
* Low total cost of ownership

And how Mule ESB enables two or more applications to communicate? Mule implements elegant protocols and standards based on well-defined patterns. Applications communicate with one another by implementing these patterns with a set of predefined components (see figure below):

Eugene continues:
"... - Applications interface with Mule over a transport.
- A transport carries service objects between components (some of the current documentation refers to service objects as “UMOs” or universal message objects; that term is deprecated now).
- The transport is any mechanism for exchanging data between two points
- Mule doesn’t implement or mandate use of particular transports. It offers instead a number of transport providers and the integration engineers or developers get to choose the appropriate one for a given application.
- A transport provider implements a message receiver or dispatcher, a connector that implements a protocol like JMS, TCP, etc., and an optional transformer.
- The transformer may be use to convert service objects from one format to another (XML to native Java, for example).
- Mule routes inbound and outbound data between transports through the service object component, which is responsible for managing component events to and from the component, and for managing pooled resources. ..."

Good reading!

RIA and SOA

I am investigating the advantages of RIA (Rich Internet Application) over the traditional Client/Web interfaces. In this article, Duane Nickul, Senior Technical Evangelist at Adobe, puts some light in this discussion.

Lest start with a traditional SOA stack:

Since a human being lives in the world above the service consumer,
the service itself will not necessarily care or be aware that a human is there. However, it is highly likely that humans are part of a service call and exist as either the trigger of some event that results in a service call and/or are the ultimate
consumers of the service result themselves. While contradictory to the title
of this article, one could state that humans are not directly part of SOA any
more than business processes are. However, both business processes and
humans utilize the SOA infrastructure.
To architect such interactions, architects should take great care to abstract any details of the service itself away from the human. The human should view the
"V" (view) component of MVC and not care about the "C" or "M" components. Accordingly, architects need a mechanism to present consistent views to the human that are abstract of any dependency upon the service.

Client-server Approaches:

1. Traditional Approach

2. AJAX, Flex mode for RIAs (new approach)

3. Final Considerations

In the Flex example shown, web services are used to communicate interactively
with the services at the bottom. Note that the cardinality is not limited in any
way to 1:1. A Flex or AJAX application may communicate directly with multiple
services, then abstract all the complexity of SOA and present the view and some
control components to the human being above the client side.
Several recent examples of the model for RIAs to interact between humans and services can be seen all over the Internet. Some applications like Apple iTunes have viewer panes which are generated locally on the client machine—such as the user's music library (see Figure 4). When they switch panes to view the iTunes Music Store, they connect directly to the Apple iTunes Music Store service, retrieve a result set, and then present it to the human being (see Figure 5). To the human being, the end result is a seamless experience joining both service calls and local
processing into one application

Implications of SOA on Business Strategy

This is an article that you can find in SOA Magazine, 3rd edition (Jan/2007). Thomas Erl is the site editor of this excellent source of information about Service-oriented Architecture.

Below some excepts from the article "Implications of SOA on Business Strategy and Organization Design", written by William Murray.

1. From Business Tasks to Business Services
In 1994 Hammer & Champy's “Manifesto for Business Revolution” argued that technology could be applied at the process-level to significantly improve organizational efficiencies through streamlining organizational processes, structures and governance, thereby bringing to the mainstream the discipline of business process reengineering, and the concept that business processes are the fundamental building blocks of the corporation. This is the beginning.

2. The IT Utility Curve
From this manifesto, we see that, regarding technology adoption in a company, there are three phases, mode and planning posture to this adoption:

Phases: Enabling, Disruptive, Enabling
Modes: Experimentation, Innovation, Commoditization
Planning Posture: Tactical, Strategic, Tactical

The graphic that shows the investment along these phases or modes is a "S" curve:

SOA Meta Model

This is what David Linthicum proposed as SOA Meta Model.

Ten Things to Think When Building SOA

David Linthicum wrote another excellent article. The tips (listed below), in fact, tell us what to do and what NOT to do regarding SOA implementation. Let's see the " rules" with my notes:

1. Focus holistically, act locally: SOA is NOT a project. SOA is a path that not ends, like quality (in an broad sense). SOA is the sum of many parts and you should take them in count when implement you architecture.
   
2. Define the value: Strategy is important, better, a business case. If you defined that SOA is the new architecture approach for you company, how it can happens if there is no guideline that will make this happen?
   
3. Don't neglect service design: What we have behind composite application and composite process?... ...Services! So, they deserve special attention. Web Services must be design to be reused, to provide behavior and information (not to be app specific), must be aware of hardware and O.S. (no calls to native interfaces).
   
4. Leveraging a legacy is unavoidable: What keeps our business running? Legacy systems! Service-oriented architecture came to allow you to take the best from these legacy systems, not to rewrite them.
   
5. Remember the semantics: When dealing with data think about the real meaning of them, the context of this information, the semantic... ...ask yourself which relevant information you can extract from this data?
   
6. The proper place for orchestration: SOA implementation does not necessarily need orchestration to run. However, consider it for some application.
   
7. Security soaks in as you execute; it's not an afterthought: You might firstly developer Web Services for internal use, but in a near future they can be used for other companies (partners). Think about Identity Management from the beginning.
   
8. Classify the patterns of use: Three rules when implementing Web Services: patterns, patterns and patterns.
   
9. Persistence is important: "... You need to think about persistence for a few reasons, including federation of services around the SOA. When building an SOA you may end up with composites or processes created out of services that may exist over a dozen or more different systems, and as such, persistence becomes more complex if done at the points...".
10. Don't skimp on testing: Keep in mind that most of the data and system that Web Services will deal with are business-critic. Thus a test plan is very important and this must be written from the beginning.
    

100+ in TI Innovation

In last December 2006 Transit received an important prize: it is one of 100+ in TI innovation (category: Telecom and Technology). The project submitted is related to "CDR convergence and mapping using SOA".

See all categories and the winners. I received, on behalf of IT team, this prize.

See below other picture.

SOA Book in my Wish List

This is the #1 SOA book in my wish list. Please feel free to donate one :-).

Happy 2007! (now with blackberry)

This Blackberry (BB) you are seeing is (was) one of the most desired gadgets in my "wish list". It was a suprise on my birthday (Dec, 27th). Now I can post directly from my BB, read and write my e-mails, browse the Internet, send SMS... ...and, believe or not, I can you use it as a mobile! Simply wonderful. I've asked myself how I could, so far, live without one of them?

Thanks Debby!

OSOA: Open SOA Collaboration

On August'06 I had already posted a message about OSOA. David Linthicum, in this article details the progress that this initiative has achieved. As David say, this group has concentrated its efforts on two projects - service component architecture (SCA) and service data objects (SDO).

• SCA is looking to provide a model for creating service components in a wide range of languages and a model for assembling service components in a business solution. In essence this is a standard that defines how services are created so they interact with each other without a lot of customization. This will benefit those who are looking to create composite applications that use these services (...SCA stresses decoupling the service implementation and service assembly from the details of the infrastructure capabilities and the access methods used to invoke services. SCA components operate at a business level, according to the spec);
• SDO is looking to provide a consistent way of handling data in applications, whatever its source or format may be. Okay, that would be data abstraction. Moreover, SDO provides a way to unify data handling for databases and services (...using SDO, application programmers can uniformly access and manipulate data from heterogeneous data sources, including relational databases, XML data sources, Web Services, and enterprise information systems).

Continuing with SDO goals:

1. Databases are connected to the applications by data mediator services;
2. Client applications query a data mediator service and get a data graph in response;
3. Client applications send an updated data graph to a data mediator service to have the updates applied to the original data source;
4. and this architecture allows applications to deal principally with data graphs and data objects.

(source: SDO for JAVA Specifitation V2.1 FINAL)

JAVA EE 5, SOA, the bad, the good... (Part 2)

+
This is the Part 2 This Special Report from WebServices.com about JavaEE 5 and Enterprise SOA.

1. The Bad (by Bruce Snyder, co-founder and developer for the Geronimo project and a senior architect at LogicBlaze Inc., an open source SOA provider)

Snyder said enterprise-grade SOA should have flexibility on the back end as well as on the developer side, and by that he means making it easier to do things. "There's a portion of Java EE trying to standardize on that," he said, such as the move toward annotations with the JAX-WS spec. "It's good in terms of standardization, but in terms of flexibility and simplifying things, I'm not sure Java EE 5 does that. I still see people going outside of Java EE to look for solutions."

2. The Good (by Michael Bechauf, vice president of industry standards at SAP AG)

All this said, organizations have to be asking themselves, just how much work is involved in taking existing enterprise apps and componentizing/service-enabling them? And does Java EE 5 make it easier?

"Java EE 5 as a technology platform has made it dramatically easier to service-enable an existing Java application," said SAP's Bechauf. "For example, Java annotations can easily service-enable a Java method. Tools also may help a great deal with the service-enabling. If you wanted to do this with a bare-bones IDE and had to write all of the code yourself using Web service APIs, it could be a fair amount of work. If you were to use a tool which helped automate this process, it would be much easier.

3. A sensate opinion (from J.Bloomberg, ZapThink.com)

Vendors that are part of the EE 5 ecosystem like SAP and JBoss are offering broader capabilities than just Java EE 5, said Jason Bloomberg, a senior analyst with ZapThink LLC. "You still need scalable, transactional Web sites, and if you want [IBM] WebSphere or [BEA] WebLogic that makes sense, but if you're looking to do SOA you're not going to focus on the same priority. It's what BEA is struggling with as it moved to SOA 360 º, for example. [Vendors] are rethinking what it means to provide a SOA platform."

4. A word from Bill Roth, Vice-President of BEA

While Roth said the company is not looking to distance itself from the Java platform, "are we saying things other than J2EE? Yes, for example an ESB is a useful way to think. There's no J in SOA, it opens up whole new world for us. The SOA world is not necessarily Java. Is Java the most productive platform for creating building blocks in SOA? Of course. Is it the best way to build everything? No.

Roth said he views building composite applications and Java EE 5 as orthogonal. "There are new technologies like Service Component Architecture, which describe how larger services are woven together and BPM [business process management], which talks about how services talk to each other. Java EE 5 [is about] how to build better services, but the process of weaving them together as an SOA is at a much larger level and might not involve Java."

5. And finally, the Importance of Service Component Architecture (SCA), by Richard Monson-Haefel, a senior analyst at Burton Group Inc.

Monson-Haefel said the Service Component Architecture (SCA) initiative "is supported by all the big players in EE space and SCA has little or nothing to do with EE."

SCA supports service implementations written using a variety of programming languages, including object-oriented languages, as well as Java, PHP, C++, and Cobol; XML-centric languages such as BPEL and XSLT; and declarative languages such as SQL and XQuery.

The fact that SCA is implemented on top of Java EE, but "doesn't reference Java EE specifically," is telling, Monson-Haefel said. "I don't have a lot of confidence that SCA will go anywhere, but all the vendors [involved] is indicative they're hedging their bets.

Free BPM Tool from TIBCO (Eclipse Integrated)

TIBCO First to Offer Full-Featured, Eclipse-Based BPM Modeling and Simulation Product for Free
— TIBCO Software Inc. , a leading business integration and process management software company that enables real-time business, today announced that the latest generation of TIBCO Business Studio(TM), version 1.1 is available for free.

More from this article: "To date, commercially available process modeling environments have been too cost-prohibitive for most companies to invest in for non-technical users. The few made available for free are generally not standards compliant, have limited functionality, or do not fit into the current IT infrastructure. As a result, models built in these solutions cannot be executed easily and, in most cases, require significant re-work by IT to ensure compliance with the execution engine. TIBCO Business Studio, version 1.1 is the first fully functional, standards-based process modeling product tailor-made for business users offered at no cost. This eliminates a key barrier to entry by giving organizations an easy, low-risk way to get started with their BPM projects."

The most important, the tool can be download from here!

Make SOA happen or SOA will happen to You

Don't panic, but think about. At Gartner Inc.'s Web Services Summit (Orlando, Fla., Dec'2006), this was a consensus among the analysts.

See the complete report here.

Let's point out some important conclusions:

1. "SOA is not something you chose to do. It will happen to you whether you chose it or not," stated Daryl Plummer, a managing vice president at Gartner;
2. Throughout the first day of the show, Gartner analysts talked up their approach to SOA governance, called SOA Portfolio. "Portfolio is a set of capabilities that you track," Plummer said. "SOA needs to be tracked."
3. According to Ivo Totev, vice president of product marketing for Software AG, "A company that focuses on SOA governance is 20% more likely to have an effectively running business."

Gartner advises to:

1. Start it's governance/management approach with the underlying technical infrastructure of SOA, like middleware and integration protocols;
2. Next in line are the procedures in use, like blueprints, templates and guidelines;
3. The final piece involves composition, which includes business processes and the humans inside a business along with the orchestration of those people and processes.
4. A central registry and repository are critical components of this dashboard. Any service is accounted for, guidelines are put into place and, therefore, the business has an organized system in play.

And finally, "No SOA suite!":

"No vendor has it all. You want SOA your way, not a vendor's way." Eliminating "suite" thinking, according to Plummer, allows for a more organic business processes that can deliver a better ROI.

JAVA EE 5, SOA, the bad, the good... (Part 1)

This Special Report from WebServices.com brings some light to recurrent discussion: at the end, JAVA EE 5 is too complex? EE would be a good option to implement SOA-based project? How well suited is Java EE style to implement lightweight services?

According to this report:

The good:

• Java EE 5 includes several key specifications intended to improve and simplify Web services support. These are: Java API for XML-Based Web Services (JAX-WS) 2.0, Java Architecture for XML Binding (JAXB) 2.0, Web Services Metadata for the Java Platform 2.0 and SOAP with Attachments API for Java (SAAJ) 1.3.
• The core tenet of SOA is loose coupling within Web services and without," Kassem said. "In Web services, our [J2EE 1.4] initial foray was very RPC-centric. That dramatically shifted with JAX-WS 2.0, it was an important programming model shift. It enables us to build more loosely coupled Web services that will scale very well for the Web. [It] was a significant SOA-centric initiative. Simultaneously, we [made] significant improvements in the JAXB 2.0 spec to enable better quality data bindings. The quality of bindings is really important. If you don't get the bindings right, you have round-tripping problems in the SOA world that you never get right. We're not completely there, but it's a big improvement.

The Bad:

(from Richard Monson-Haefel) "What we're seeing are the last few years of Java EE as a leading choice in doing enterprise development, which is pretty obvious with the rise of rebel frameworks like Hibernate, Spring, Tapestry and Struts, which don't fall directly under the EE spec. These are indications that programmers are looking for platforms that are easier to work with. There are solutions you can use with Java EE like Struts, and many claim these reinforce EE as a good platform, but they're actually raising the abstraction so developers are working with the framework and not the EE platform programming model."

Jason Bloomberg, senior analyst at ZapThink LLC, said, "In the big picture in the SOA world, people are moving away from Java EE 5. It's becoming less and less relevant. EE is essentially an architecture for building scalable, transactional Web sites. It's not designed for SOA. More people are understanding the limitations, and realizing there are other Java-based approaches. We're not seeing anybody interested in JAX-WS and JAXB. We are seeing open source Java suites as appropriate for SOA. It depends on what you're trying to accomplish, but we see a lot of use of elements of open source ESBs and Hibernate for various parts of the Java infrastructure. What we're not seeing is interest in Java EE."