Google Apps gains traction for Enterprise Support
Enterprise support for Google Apps engine is surely ramping up. You can now run Java 5 and 6 code on Google App Engine as long as it doesn’t break the security sandbox on Google’s servers. Given that most enterprises have standardized on either .NET or Java, this announcement alone is very big news since only Python was supported previously in GAE. This also means just about any programming language capable of running within a JVM now works in GAE as well. Google has also came to the decision to support Java platform capabilities such as dependency injection, aspect-oriented programming (AOP), and expression language runtimes. Google has already tested GAE with Groovy, JavaScript, Python, Ruby, Scala, and Scheme, well-known languages that developers are very interested in at the moment.
The new Secure Data Connector (SDC) in GAE provides a secure tunnel into organizations that want to use their data, Web services, and SOAs from within GAE, without moving the data itself out into the cloud. SDC requires Google Apps Premier Edition, which brings along some potential entanglements, but in return provides a fully encrypted connection between Google App Engine applications and enterprise data inside the firewall. SDC also provides declarative filters to prevent inadvertent exposure of business data as well as OAuth, which is becoming popular for enabling safe access via open standards to secure Web APIs, for providing secure access to internal SOA services with best practices. With SDC, GAE can directly and safely access a much broader wealth of enterprise data than was possible previously, without the challenges of uploading titanic enterprise datasets across the Internet into Google’s data center as well as dealing with GAE’s still somewhat limited datastore.
Some types of application, however, particularly very high performance ones, will require enterprise data to be moved into Google’s cloud. The new GAE database import tools allows businesses to bulk load their data off their premises and into GAE. This will allow enterprises to more easily and quickly migrate production datasets into GAE as needed. Note that only database import is offered for now, though Google promises to offer a way to bulk export data in the very near future.
GAE originally offering computing based on an exclusive request/response model, just like the Web itself (HTTP GET/POST, etc.) This makes the GAE computing platform operate only when an inbound request comes in form the network but is a limitation when background processing has to take place. Previously, businesses had to establish their own batch jobs external to GAE using their own facilities. With built-in Cron support, GAE now supports both request/response and background processing, which is required to to meet a robust set of enterprise application requirements since background processing is critical for tasks like backups, report generation, asynchronous processing, etc.

The non-overlapping responsibilities of Enterprise Architect and Solution Architect:


I would say Enterprise Architect is the one who works closely with Business Architects and Solution Architects and hence a blend of both of them. Any more thoughts on this would be highly welcomed.

Communities I follow :-

CIO PeertoPeer Research Panel

SAP Business Process Expert Community

BEA Enterprise 360

Excerpts from recent interview of Sandy Carter, responsible for driving IBM's cross-company, worldwide SOA marketing initiatives

The three business entry points for SOA are people, process, and information. The two technical entry points are connectivity and reuse.

The five most common questions from customers who are beginning their SOA journey are usually:
Can I still use my existing software and hardware?
Where do I begin with SOA?
Is SOA for large companies only?
How do I gain the much-needed SOA skills?
How do I prove the value of SOA to the executives in my organization

First, SOA is specifically designed to protect existing IT investments in software and hardware. The most successful SOA deployments are found at those companies that begin with a view of SOA as a long-term business strategy. These companies approach SOA incrementally, through one of the five entry points cited above, and continuously measure and monitor its success at every step along the way.

For those companies that are expanding their SOA, the questions are usually about, "how do I document and share my business processes?" To do this, it's important that the SOA initiative includes a strong governance strategy to make sure that its services can be easily managed, monitored, and reused while ensuring only best practices are shared.

In terms of developing skills, it's clear that the industry is facing a serious SOA IT skills shortage. In fact, a recent study found that 56 percent of IBM customers cited lack of skills, mainly individuals with a blending of IT technical understanding and business process acumen, as the leading inhibitor to SOA.

To address the SOA skills shortage, IBM recently announced new tools and certification programs to help organizations develop teams of individuals with so-called "T-shaped" skills, which encompass both deep business skills, represented by the horizontal line of the "T," and technical understanding, represented by the vertical line.

IBM recognizes that a successful SOA strategy requires both IT and business executives to collectively map out goals and illustrate the value of the SOA project. To this end, IBM offers free, online assessment tools to help executives at companies of all sizes determine their organization's business and IT needs. For example, IBM's SOA Business Analyzer helps an organization identify its greatest assets and opportunities that are ripe for an SOA project.

Also, the IBM BPM with SOA ROI Assessment Tools helps organizations assess their Business Process Management (BPM) readiness through 10 simple questions. It then delivers a BPM score, assesses an organization's position to realize benefits from BPM, and provides recommended next steps. Through this assessment, both IT and business executives can better understand the business value of an SOA strategy.

The significant advantages of the Java-to-WSDL approach are:
It is a quick way to expose legacy implementations as Web services.
It requires little or no knowledge of WSDL or XML because the WSDL document is generated by the tools.
It provides better and easier support for exposing overloaded operationsThe disadvantages of the bottom-up approach are:
The generated schema defining the data types in the WSDL document derives only from the Java classes from the provider's environment and not from any standards-based schema.
The provider-side data types may not be simple DTOs, in that they include additional business logic. Such logic can't be reconstructed on the requester side.
The generated schema is embedded in the WSDL, which makes reuse of the schema, perhaps in the definition of other Web services, more difficult. It is possible, of course, to extract the schema from the original WSDL document.
The development of the server-side Web service implementation and the client-side Web service requester can't proceed in parallel. The server-side skeleton and DTOs have to be developed before a WSDL can be generated that can be used to generate the client-side stubs and DTOs.
Incremental changes to the interface are more difficult to manage. For example, if the interface of the class that implements the service is changed and the WSDL is regenerated, more significant changes could occur in the WSDL, thus causing interoperability with existing clients to fail. The basic problem is that, on the server-side, the class implementing the service is deemed the master interface and, on the client-side, the WSDL provided by the server-side is the master interface. These two different masters can cause the interfaces to become out of sync and difficult to debug and fix.
The namespaces of the embedded schema types are typically generated from the Java package names of the server-side JavaBeans. Therefore, if the package names are changed, the namespace will be changed, which means the types are no longer compatible. Most of the tools allow a package to namespace mapping, but this must be explicitly set during the execution of the tool.

WS-Addressing Links

http://www-128.ibm.com/developerworks/webservices/library/ws-address.html

http://dev2dev.bea.com/pub/a/2005/01/ws_addressing_intro.html

ebXML Links:-

http://dev2dev.bea.com/pub/a/2004/12/ebXML.html

http://dev2dev.bea.com/pub/a/2005/01/ebxml_security1.html

http://dev2dev.bea.com/pub/a/2005/01/ebxml_security2.html

Must Read SOA Links

http://www-306.ibm.com/software/solutions/soa/

http://dev2dev.bea.com/pub/a/2006/03/enterprise-architecture.html

http://dev2dev.bea.com/pub/a/2006/08/soa-service-lifecycle-design.html

http://dev2dev.bea.com/pub/a/2006/11/soa-service-lifecycle-run.html

http://dev2dev.bea.com/pub/a/2005/12/soa-roadmap.html

http://dev2dev.bea.com/pub/a/2005/11/planning-for-soa.html

http://dev2dev.bea.com/blog/kemo/archive/2007/04/integration_ser.html

http://dev2dev.bea.com/blog/arch2archeditor/archive/2007/04/services_earning_their_keep.html

http://dev2dev.bea.com/blog/quinton_wall/archive/2007/04/the_state_of_ja.html

Designing a WSDL (Web-Services Description Language) file

This article is aimed to get a very clear picture of various binding styles and their use while designing a WSDL file. I have tried my level best to put description in a very simple and precise manner.

The Web- Service Description Language (WSDL ) is XML based service description often pronounced “Whiz-Dull” that describes the public interface to the web-service. It abstractly describes the supported operations and messages and how they are bound to concrete network protocol and message format.

Although there are lot of discussions going on various binding style and their use, there still lies the confusion on how to determine which combination of style and use to apply while designing WSDL file.

The element of the WSDL contains a pair of parameters that influence the form of the resulting SOAP messages: binding style (RPC or document) and use (encoded or literal).

This gives you four style/use models:

1. RPC/encoded
2. RPC/literal
3. Document/encoded
4. Document/literal

Add to this collection a pattern which is commonly called the document/literal wrapped pattern and you have five binding styles to choose from when creating a WSDL file.

The terminology here is very unfortunate: RPC versus document. These terms imply that the RPC style should be used for RPC programming models and that the document style should be used for document or messaging programming models. That is not the case at all. The style has nothing to do with a programming model. It merely dictates how to translate a WSDL binding to a SOAP message. Nothing more. You can use either style with any programming model.

Likewise, the terms encoded and literal are only meaningful for the WSDL-to-SOAP mapping only while the actual meanings make a bit more sense.

According to the WSDL 1.1 Specification, the key differences between binding styles are as follows :-

RPC Style

• This style specifies that it has an element with the name same as
that of service method name called as wrapper element.

• This element, in turn, contains an entry for each parameter and return value of this method

• This style mandates that the parameters specified must be in the specific parameter order

Document Stlye

• When the attribute is set to document style, the client understands that it should make use of XML schemas rather than remote procedure calling conventions

• This style does not contain any wrapper element. Instead the message parts appear
directly under the element

• The contains what the sender and receiver agreed on as an XML document

Within those styles, you can also have literal use and encoded use.

Literal

• Each message part references the concrete schema definition using either the element or type attribute

• In other words, data is serialized according to the given schema agreed upon by the sender and receiver, usually expressed using the W3C XML Schema Specification

Encoded

• Each message part references an abstract type using the type attribute only

• The encoding used is SOAP encoding which specifies that the serialization will be done according to the SOAP rules. SOAP 1.1 has the set of serialization rules defined which specify how objects, arrays, and structures should be serialized

Lets discuss the Pros and Cons of various style/use combinations. As mentioned earlier, we have 5 different style/use combinations

1) RPC/encoded style

Strengths
• The WSDL is very much straightforward
• The operation name appears in the message, so the receiver has an easy time dispatching this message to the implementation of the operation.

Weaknesses
• SOAP message contains xsi :type encoding attributes which is usually just overhead and degrades throughput performance
• However, it’s difficult to validation to message because the service method name is not defined in the schema, but is instead a WSDL definition.
• RPC/encoded is not WS-I compliant. Thus makes it difficult for other types of clients to read the WSDL and generate appropriate stubs on the client side to call the service.

2) RPC/literal style
The RPC/literal WSDL looks almost the same as the RPC/encoded WSDL except the use in the binding is changed from encoded to literal. The SOAP message for RPC/literal is same as RPC/encoded with the type encodings been removed.
Here are the strengths and weaknesses of this approach:

Strengths
• The WSDL is still about as straightforward as it is possible for WSDL to be.
• The operation name still appears in the message.
• SOAP message does NOT contain xsi :type encoding attributes
• RPC/literal is WS-I compliant.

Weaknesses
• You still cannot easily validate this message since the service method name is not defined in the schema, but is instead a WSDL definition.
What about the document styles? Do they help overcome this weakness?

3) Document/literal

The WSDL for document/literal changes somewhat from the WSDL for RPC/literal. Here are the strengths and weaknesses of this approach:

Strengths
• There is no type encoding information in SOAP message
• You can finally validate this message with any XML validator. Everything within the soap:body is defined in a schema.
• Document/literal is WS-I compliant

Weaknesses
• The WSDL is getting a bit more complicated. This is a very minor weakness
• The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible.
• There are cases where you'll need to use one of the RPC styles.
For instance, say you have the set of methods in SEI as follows :-
public void myMethod(int x, float y);
public void myMethod(int x);
public void someOtherMethod(int x, float y);

Now assume that your server receives the document/literal SOAP message. Which method should the server dispatch to? All you know for sure is that it's not myMethod(int x) because the message has two parameters and this method requires one. It could be either of the other two methods. With the document/literal style, you have no way to know which one. Instead of the document/literal message, assume that the server receives an RPC/literal message. With this message it's fairly easy for a server to decide which method to dispatch to. You know the operation name is myMethod, and you know you have two parameters, so it must be myMethod(int x, float y).


4) Document/encoded

Nobody follows this style. It is not WS-I compliant. So let's move on.

5) Document/literal wrapped

While each style has its place, under most situations the best style is document/literal wrapped. This wrapped style originates from Microsoft®. There is no specification that defines this style. This style is meant to improve on some of the weakness of doc/literal style
These are the basic characteristics of the document/literal wrapped pattern:

• The input message has a single part.
• The part is an element.
• The element has the same name as the operation.
• The element's complex type has no attributes
• The WSDL schema now has a wrapper around the parameters

Comparison between RPC/literal and Document/literal wrapped

• In the RPC/literal SOAP message, the service method name was the name of the operation.
• In the document/literal wrapped SOAP message, the service method name is the name of the wrapper element which the single input message's part refers to.
It just so happens that one of the characteristics of the wrapped pattern is that the name of the input element is the same as the name of the operation. This pattern is a sly way of putting the operation name back into the SOAP message.
So far, this article has given the impression that the document/literal wrapped style is the best approach. Very often that's true. But there are still cases where you'd be better off using another style.

Strengths
• There is no type encoding info.
• Everything that appears in the soap:body is defined by the schema, so you can easily validate this message.
• Once again, you have the method name in the SOAP message.

Weaknesses
• The WSDL is even more complicated.
• WSDL allows overloaded operations. But when you add the wrapped pattern to WSDL, you require an element to have the same name as the operation, and you cannot have two elements with the same name in XML. So you must use the document/literal, non-wrapped style or one of the RPC styles.
As you can see, there is still a weakness with the document/literal wrapped pattern, but it's minor and far outweighed by the strengths.

So, Can there be RPC/literal wrapped also ?

From a WSDL point of view, there's no reason the wrapped pattern is tied only to document/literal bindings. It could just as easily be applied to an RPC/literal binding. But this would be rather silly. The SOAP message would contain a service method name for the operation and a child element as service method name for wrapper element. Also, even though it's legal WSDL, an RPC/literal part should be a type; an element part is not WS-I compliant.

Summary

There are four binding styles (there are really five, but document/encoded is meaningless). While each style has its place, under most situations the best style is document/literal wrapped.
In general, the literal use is gaining importance, and as far as encoded use is concerned, the Web Services Interoperability Organization (WS-I) in its Basic Profile Version 1.0a of August 2003 with web ruled out the use of SOAP encoding services.