XML or Java-Centric Web Services?
All,
Good to be back, and I thought I would start a thread on whether it is better to go the JSR 181 route (Java-centric using annotations and a POJO or EJB to generate web services) or the W3C WS route (XML-centric using schema and/or WSDL to generate a Java component model). In short, build your web services architecture around XML or Java? Or both?
Believe it or not, even having worked on the problem for several months, I am not sure what the best answer is. Granted, different environments will have different requirements. But at least right now, this is what I found out.
Java-Centric
Here writing your web services is extremely easy. Adding annotations to a POJO or EJB is extremely straightforward and simple. You don't have to switch from the Java side of your brain to the XML side. It is also very straightforward.The problems we ran into are a bit subtle but eventually prompted us to look at a more XML-centric solution.
One issue is that your service layer (WSDL API) is directly tied to your Java POJO or EJB's. This means it is really easy (too easy) to modify an object and not realize you impacted all your calling clients by a simple change in the underlying implementation. Another problem is with the underlying technologies themselves. I am normally a huge fan of JBoss, but declaring your web services in web.xml seems to hack-ish even for me. XFire handles the binding much better, and if you were to go the JSR 181 route, I think XFire would be the best. On the downside, they do not yet have the entire WS stack available.
XML-Centric
Here there is a lot more work. There are a number of options, including XFire and Axis to go XML-Centric. They will generally generate something like XMLBeans or JAXB from a given schema or WSDL. Personally, I think starting "in the middle" with a schema is the easiest. There is decent tooling for creating schemas, and you can reverse engineer one from an existing Java POJO or EJB. Then you have a tool generate the WSDL from the schema.
But you are still not done. You need to bind to your POJO or EJB from the XML component model that is generated. Not too much work, but anyone who has seen the cruft XMLBeans generates will know that using this as a domain model is problematic, at best. In effect, you are always writing parallel hierarchies (one schema/WSDL, the other POJO/EJB).
Why go to all that effort? Well for one thing, you can take advantage of the full WS stack (ws-security, ws-messaging, ws-transactions, ws-bpel, etc.) It also provides a nice layer of indirection, albeit at development cost, between your Java domain model and your service API . So, changing an implementation does not automatically 'ripple' to your service layer.
Problems with Either Method
Programming to interfaces is generally a good thing, especially in a service layer or domain model. The problem is that you cannot realistically use an interface in your service signatures. What implementation would be chosen? It is even more problematic when an interface would make sense for polymorphism. Now, the service engine would have an impossible time determining an implementation to use. Here's a concrete (no pun intended) example:
interface Address{}
@WebService
publicfinalclass AddressService{
@WebMethod
publicfinal Address getStandardizedForm(final Address target){}
}
The above cannot be done. You need a POJO or an EJB. Granted, this makes sense. However, losing the ability to simply have an existing domain model with interfaces that is used in your service classes or layer is to me a big let-down. Now, in effect, you must write a DTO for each "domain model" class you would have used the interface for instead. You are forced to do so using an XML-centric approach from the get-go. It is just a shame there is no way to reuse my existing domain interfaces in the service tier when going Java-centric.
Shangri-La
It would be nice if the existing open source implementations provided non-trivial examples using the whole WS stack. If you take a look at what gets "removed" from your POJO's and EJB's by going this route (authentication, authorization, validation via schema, business process orchestration, transaction demarcation, dispatch, etc.), there are a lot of benefits. You can also have these, what I term, service 'aspects' defined in a language-agnostic way.
You can find the list of all the WS specs here: http://en.wikipedia.org/wiki/List_of_Web_service_specifications. Sadly, the tutorials, and certainly the tooling, are not really descriptive or desirable enough yet. I also worry that going XML centric will allow me to make the same mistakes made earlier trying to use XQuery and XSLT as technologies. Whatever did solve the XML parsing/scaling problem anyway. (StAX is that good?)
I was just posting this to see if anyone else had similar difficulties and overcame them with something like a JSR 208 ESB.
- Saish
[5481 byte] By [
Saisha] at [2007-11-26 16:34:43]
# 1
Brilliant stuff, Saish.
The interface problem troubles me a lot. Your comment about changes to a POJO or EJB rippling out to clients is spot on. But I'm not sure that I want to buy everything that the extra complexity of WS-i is selling.
Our org is about to embark on its service oriented architecture journey. My fear is that we haven't dug deep enough to answer these questions. The choices are important and will have long-lasting effects.
Sometimes I think that this is just another effort by tool vendors to lock us into their stack and tools. It hasn't worked out with Java EE, with OSGi coming on board, so now they're moving onto WS-I to lock us in.
Great post, as usual. Thanks for taking the time. Sincerely, %
# 2
> Brilliant stuff, Saish.
>
> The interface problem troubles me a lot. Your
> comment about changes to a POJO or EJB rippling out
> to clients is spot on. But I'm not sure that I want
> to buy everything that the extra complexity of WS-i
> is selling.
>
Another option is ws02. http://wso2.com/. They have some promising and cool toys, but right now, we did not think they were stable enough. Definitely worth checking out though.
> Our org is about to embark on its service oriented
> architecture journey. My fear is that we haven't dug
> deep enough to answer these questions. The choices
> are important and will have long-lasting effects.
>
There are a lot of different takes on SOA, which makes me think it really is not all that new. (How is SOA really different from CORBA anyway?) I like thinking of SOA as two ideas: isolation and ownership. I know reuse is often cited, but given how few times I reuse my own code, reusing a service would seem just as problematic. Isolation so legacy code cannot 'infect' or ripple outside of its owning service. And speaking of which, ownership. Ideally, the service would uniquely own every domain, integration and persistence component, down to a database table/column (admittedly hard to achieve for legacy applications). Then, all calls have to enter the service layer. When you have those two things: isolation and ownership, that to me is SOA.
There was some web site, and I will mangle this quote, but it went something like, "One developer actually did figure out what SOA is, but he died immediately from the Truth."
> Sometimes I think that this is just another effort by
> tool vendors to lock us into their stack and tools.
> It hasn't worked out with Java EE, with OSGi coming
> on board, so now they're moving onto WS-I to lock us
> in.
>
Yepper. At the very least, it is a nice way to sell re-architecting your system to the business side. It is a rare day to get a project like that approved otherwise.
> Great post, as usual. Thanks for taking the time.
> Sincerely, %
Likewise!
- Saish
# 3
Oh, and there's one other key bit of SOA, I think I referred to it earlier, and that is the idea of aspects. Now, you can implement aspects via vanilla OOP as well as via AOP. But the idea of cross-cutting concerns occurring at the service layer to me is very appealing. I have been trying to implement the following via annotations in our SOA effort:
> Authentication
> Authorization
> Validation
> Business Process Orchestration
> Auditing
> Logging
> Exception Handling
That's just the first crack. Basically, you annotate a POJO and a JEE5 interceptor provides the AOP. You only have one interceptor that ensures the above are executed in a consistent order, based on the annotations present. That frees up your domain to concentrate solely on business logic. Integration classes generally are dictated to you anyway by a vendor. And persistence is already handled decently by JPA. So, by 'ripping' the above aspects out of the domain and into annotations in your service POJO's, the amount of boilerplate code is reduced immensely.
Of course, none of the above speaks at all to the VC in MVC. IMO, everything just mentioned is model functionality. SOA probably should not worry about clients.
- Saish
# 4
> Another option is ws02. http://wso2.com/. They have
> some promising and cool toys, but right now, we did
> not think they were stable enough. Definitely worth
> checking out though.
Totally ignorant of this. Thanks for the link.
> There are a lot of different takes on SOA, which
> makes me think it really is not all that new. (How
> is SOA really different from CORBA anyway?)
I've asked myself that every day.
> I like
> thinking of SOA as two ideas: isolation and
> ownership. I know reuse is often cited, but given
> how few times I reuse my own code, reusing a service
> would seem just as problematic. Isolation so legacy
> code cannot 'infect' or ripple outside of its owning
> service. And speaking of which, ownership. Ideally,
> the service would uniquely own every domain,
> integration and persistence component, down to a
> database table/column (admittedly hard to achieve for
> legacy applications). Then, all calls have to enter
> the service layer. When you have those two things:
> isolation and ownership, that to me is SOA.
Yes. This means a non-overlapping universe of data sources in the back. Completely unshared, and only accessible via the service. No worries about inconsistency, because only one service will own that data.
> There was some web site, and I will mangle this
> quote, but it went something like, "One developer
> actually did figure out what SOA is, but he died
> immediately from the Truth."
And ascended to heaven in a flaming chariot. 8)
> Yepper. At the very least, it is a nice way to sell
> re-architecting your system to the business side. It
> is a rare day to get a project like that approved
> otherwise.
I think it's our opportunity to finally get the data mess sorted out, but if we screw it up this time we're really done.
The one benefit of stovepipes is that they ARE isolated - their mess can't affect others. (They also can't communicate in a beneficial way, either.) With SOA they'll all be coupled and connected. I'm scared of this. Our track record isn't good.
Have you read Roy Fielding's dissertation on REST?
http://roy.gbiv.com/pubs/dissertation/top.htm
Could be good stuff. I like the simplicity of it. It'll feel familiar to developers, because they already know HTTP and servlets.
No ESB or Workshop to sell, though.
%
# 5
One other thing that might impact the choice between going XML-centric vs Java-centric, would be if you have already a large code base and want to expose (as Web services) stuff that you wrote before. In that case, it might be better to go Java-centric. OTOH, an XML-centric approach is easier to adopt if you haven't written any code yet.
One problem with going XML-centrist would be if your schema is bound to change often, and schema versioning. In effect, you have another type of coupling here, between your application and your XML structure. If the schema changes, you need to re-generate your classes. Reverse-engineering tools might ease this issue.
Having a set of generated classes from schema might help to get started writing code. However most of these binding frameworks use JavaBean wrappers that are not exactly OO. To me, OO design goes well beyond a bunch of get/set methods. This may sound foolishly academic.
Anyway, one solution would be to go with your suggestion to do the XML-binding with aspects instead, then you would effectively isolate your OO code from XML. You could also provide different XML-bindings without changing your code, and keeping the class structure you want. I heard JiBX does something to that effect.
As for ESBs, it seems that the architectural choice between Java-centric (ServiceMix) and XML-centric (Mule) approaches is still there. I'm no ESB expert though, and I'm still busy trying to separate the reality of the technology from the hype.
# 6
> One other thing that might impact the choice between
> going XML-centric vs Java-centric, would be if you
> have already a large code base and want to expose (as
> Web services) stuff that you wrote before. In that
> case, it might be better to go Java-centric. OTOH, an
> XML-centric approach is easier to adopt if you
> haven't written any code yet.
>
> One problem with going XML-centrist would be if your
> schema is bound to change often, and schema
> versioning. In effect, you have another type of
> coupling here, between your application and your XML
> structure. If the schema changes, you need to
> re-generate your classes. Reverse-engineering tools
> might ease this issue.
This coupling is what scares me to death.
> Having a set of generated classes from schema might
> help to get started writing code. However most of
> these binding frameworks use JavaBean wrappers that
> are not exactly OO. To me, OO design goes well beyond
> a bunch of get/set methods. This may sound foolishly
> academic.
Not foolishly academic IMO. This is spot on.
> Anyway, one solution would be to go with your
> suggestion to do the XML-binding with aspects
Now you're preaching to the choir. We'd like to have Spring as the basis for all services.
> instead, then you would effectively isolate your OO
> code from XML. You could also provide different
> XML-bindings without changing your code, and keeping
> the class structure you want. I heard JiBX does
> something to that effect.
> As for ESBs, it seems that the architectural choice
> between Java-centric (ServiceMix) and XML-centric
> (Mule) approaches is still there. I'm no ESB expert
> though, and I'm still busy trying to separate the
> reality of the technology from the hype.
I didn't realize the distinction. Sonic appears to be the front runner here (our management likes spending money on licences). I'll have to see which camp it falls into.
Another great post. Thanks, karma-9
%
# 7
> Oh, and there's one other key bit of SOA, I think I
> referred to it earlier, and that is the idea of
> aspects. Now, you can implement aspects via vanilla
> OOP as well as via AOP. But the idea of
> cross-cutting concerns occurring at the service layer
> to me is very appealing. I have been trying to
> implement the following via annotations in our SOA
> effort:
>
> > Authentication
> > Authorization
> > Validation
> > Business Process Orchestration
> > Auditing
> > Logging
> > Exception Handling
Saish, I never responded properly to this. I like your idea very much. All these features are what ESB salesmen are touting for their products, but I like the idea of distributing them. I worry about ESBs becoming a bottleneck for the enterprise.
I think aspects are still virgin territory for people like me. I'd like to know what they can really do for me and what problems they might cause.
%
# 8
It is actually really simple (at least this implementation is). The thing that scares me about aspects is that you in effect have a whole set of code that fires "magically" on method invocations. It is easy to understand with one aspect, but once you have multiple ones, I think you open yourself up to very hard to detect and debug runtime errors. So, I simply opt to use AOP once, as a bridge to a set of chained "aspects". However, the latter are just POJO's using OOP. So, it ends up looking something like this:
EJB Method Invocation
JEE 5 EJB Interceptor (Around Invoke Aspect)
Custom Interceptor enforcing proper ordering of aspect firing
Invoke actual method
End of Aspects and Rejoining of EJB Invocation
The aspects are added to any JEE 5 EJB via annotations. Here are a few:
@Authenticate (AuthenticationPolicy.PASSWORD)
@Authorize (Role="Poobah")
@Validate (Method="checkBalance")
@Orchestrate (ProcessName="transferAccount")
@Audit (AuditPolicy.FULL)
@TransactionAttribute (TransactionType.REQUIRED)
@Session
Then the EJB itself simply delegates the actual work to domain objects. It only needs to define a few annotations (some are opt-in, others are opt-out). Developers now should only have to worry about business or integration logic in the domain.
Here is a snippit of the interceptor (minus the annotation processing which is delegated to another class, and as you can see, I am still working on the async aspect):
@AroundInvoke
public final Object invokeEjb(final InvocationContext ctx)
throws Exception {
// Indicate start of AOP interception
boolean unexpectedExit = false;
String method = ctx.getMethod().toGenericString();
log(this.getClass().getName() + " starting interception of method '" + method + "'");
try {
// Apply pre-invocation audit
if (AOP_AUDIT != null) {
log(ME + " invoking AOP audit on start '" + AOP_AUDIT.getClass().getName() +
"' for method '" + method + "'");
AOP_AUDIT.onStart(ctx);
}
// Apply authentication
if (AOP_AUTHENTICATION != null) {
log(ME + " invoking AOP authentication '" + AOP_AUTHENTICATION.getClass().getName() +
"' for method '" + method + "'");
AOP_AUTHENTICATION.authenticate(ctx);
}
// Apply authorization
if (AOP_AUTHORIZATION != null) {
log(ME + " invoking AOP authorization '" + AOP_AUTHORIZATION.getClass().getName() +
"' for method '" + method + "'");
AOP_AUTHORIZATION.authorize(ctx);
}
// Apply validation
if (AOP_VALIDATION != null) {
log(ME + " invoking AOP validation '" + AOP_VALIDATION.getClass().getName() +
"' for method '" + method + "'");
AOP_VALIDATION.validate(ctx);
}
// If we are processing asynchronously, send the message now, and then continue on to finalize
if (AOP_ASYNCH != null) {
log(ME + " delivering asynch AOP message '" + AOP_AUDIT.getClass().getName() +
"' for method '" + method + "'");
log(ME + " confirmed delivery of AOP message '" + AOP_AUDIT.getClass().getName() +
"' for method '" + method + "'");
}
// Apply business process orchestration (jBPM)
if (AOP_ORCHESTRATION != null) {
log(ME + " invoking AOP orchestration '" + AOP_ORCHESTRATION.getClass().getName() +
"' for method '" + method + "'");
AOP_ORCHESTRATION.process(ctx);
}
// Finally, invoke the method itself
log(ME + " invoking intercepted method '" + method + "'");
Object returnValue = ctx.proceed();
// Apply post-invocation audit
if (AOP_AUDIT != null) {
log(ME + " invoking AOP audit on success '" + AOP_AUDIT.getClass().getName() +
"' for method '" + method + "'");
AOP_AUDIT.onSuccess(ctx, returnValue);
}
// Return the value received by the method
return returnValue;
}
// Handle any errors
catch (Throwable cause) {
if (AOP_AUDIT != null) {
log(ME + " invoking AOP audit on error '" + AOP_AUDIT.getClass().getName() +
"' for method '" + method + "'");
AOP_AUDIT.onError(ctx, cause);
}
// Handle the error normally but we must manually re-throw an AbstractException
unexpectedExit = (cause instanceof AbstractException == false);
ErrorHandler.getInstance().process(cause);
if (cause instanceof AbstractException) {
throw (AbstractException) cause;
}
// This line should never fire. ErrorHandler will re-throw any other exception encountered
throw new UnexpectedError(ME + " received a totally unexpected error that the " +
"ErrorHandler should have previously thrown!!!", cause);
}
// Indicate completion of the method
finally {
if (AOP_AUDIT != null) {
log(ME + " invoking AOP audit on finalize '" + AOP_AUDIT.getClass().getName() +
"' for method '" + method + "'");
AOP_AUDIT.onFinalize(ctx);
}
if (unexpectedExit) {
LOG.warn(this.getClass().getName() + " UNEXPECTEDLY finished interception of method '" +
method + "'");
}
else {
log(this.getClass().getName() + " finished interception of method '" +
method + "'");
}
}
}
The key part is the @AroundInvoke annotation, which enables the EJB3 interceptor (well, there is another class annotation not present, but trivial). The other key part is you only have one object like this and at the service layer.
There is obviously a decent amount of code to provide each of these aspects, but again, they are written as OOP POJO's.
- Saish
# 9
I think that this dude really knows his stuff:
Thomas Erl on why we should focus on service-orientation more than SOA
"I would not consider "SOA" as a term without substance. It's quite the opposite. It's a term that has been allocated too much substance, which is another reason it causes so much confusion. An architecture is not a computing platform, nor is it a design philosophy or an implementation technology. Depending on your sources, you will find SOA as a label for some or all of these things and more. By assigning it too much meaning, it loses meaning and definition."
http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci1189356,00.html
These articles are good for taking to your boss when he wants you to build a service for every database query:
1 of 6: Introduction to service-orientation
http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci1165286,00.html
2 of 6: Service contracts and loose coupling
http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1171966,00.html
3 of 6: Service abstraction and reuse
http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1179915,00.html
4 of 6: Service discoverability and composition
http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1187364,00.html
5 of 6: Service autonomy and statelessness
http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1192369,00.html
6 of 6: Principle interrelationships and service layers
http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1198465,00.html
# 10
> One other thing that might impact the choice between
> going XML-centric vs Java-centric, would be if you
> have already a large code base and want to expose (as
> Web services) stuff that you wrote before. In that
> case, it might be better to go Java-centric. OTOH, an
> XML-centric approach is easier to adopt if you
> haven't written any code yet.
>
Definitely a fair point. However, I think you also have to include all legacy systems in your enterprise in this analysis. The more heterogenous the environment, the more you will be pushed to take the XML-centric approach.
> One problem with going XML-centrist would be if your
> schema is bound to change often, and schema
> versioning. In effect, you have another type of
> coupling here, between your application and your XML
> structure. If the schema changes, you need to
> re-generate your classes. Reverse-engineering tools
> might ease this issue.
>
Right, but I think that's the nature of the beast. The service is a contract, however it is exposed. If something changes underneath, modification of the service could be required as well, whether a schema, Servlet or EJB.
> Having a set of generated classes from schema might
> help to get started writing code. However most of
> these binding frameworks use JavaBean wrappers that
> are not exactly OO. To me, OO design goes well beyond
> a bunch of get/set methods. This may sound foolishly
> academic.
>
I 100% agree. I have seen these called both 'boundaries' and 'component models'. A big push, IMO, has been 'programming by default', where frameworks code for the majority of cases leaving you to choose whether you want the default behavior or finer grained control. With most component models and boundaries, you are forced by the technology to make compromises. Examples are the HTTP-OO boundary, Relational-OO boundary, Web Service-OO boundary, etc. If you can find a programming by default solution (in this case java-centric JSR 181 or something similar), go for it. The last thing I think we all want is another component model ala Struts with a lot of boilerplate code. That in my opinion is one of the real disadvantage of the XML-centric solutions.
> Anyway, one solution would be to go with your
> suggestion to do the XML-binding with aspects
> instead, then you would effectively isolate your OO
> code from XML. You could also provide different
> XML-bindings without changing your code, and keeping
> the class structure you want. I heard JiBX does
> something to that effect.
>
I have not quite taken it that far, but I think it is a great idea and will check out JiBX. I am just trying to use aspects to simplify the coding of a service (again, programming by default).
> As for ESBs, it seems that the architectural choice
> between Java-centric (ServiceMix) and XML-centric
> (Mule) approaches is still there. I'm no ESB expert
> though, and I'm still busy trying to separate the
> reality of the technology from the hype.
One thing the ESB's do seem to offer nicely is versioning of services. Whether they are primarily written as schemas or POJO's or EJB's, I think true SOA will have to elegantly handle different simultaneous versions of a given service (according to some deprecation, support or sunset policy, whatever that might be). It gets even more complicated when you add BPM. What happens when a long-lived process (say on the order of weeks) has a service contract change?
Great points Karma!
- Saish
# 11
> One problem with going XML-centrist would be if your
> schema is bound to change often, and schema
> versioning. In effect, you have another type of
> coupling here, between your application and your XML
> structure. If the schema changes, you need to
> re-generate your classes. Reverse-engineering tools
> might ease this issue.
Yes, but this is only true because the approach is incorrect, IMO.
The XML schemas in the web service definition and your Java code should not be coupled. The big mistake that almost everyone makes is that they either generate the web service from code or they generate the code from the webservice.
The approach I adamantly recommend is that, if you are defining the service, create your contract first without writing a line of Java. This is the most important thing because you are pretty much stuck with this once it's public. and the contract is not just the WSDL, it's all the documentation about what's allowed, expected response times, requirements on the caller etc. This is the bulk of your work. This is the hard part.
For the technical implementation, I would write the classes that you will use to generate the data for these services. Do not generate them from the WSDL. Write them as good solid classes. Chances are you screwed up in the first part above and you'll need to create a version 2, or 3 of your service with a different WSDL.
Generate schemas (not WSDL) for your classes. You can do this with JAXB, I believe. Then it's a just a matter of transforming the xml produced from your classes to the service schema with XSL or similar language and use a framework for supporting the SOAP protocols.
I know there's a lot here and I'm being a little flip but the naive approaches will extract maximum pain over the long-term, in my experience.
# 12
I 100% agree Dubwai. We are going the schema-centric route. You can map to WSDL (we do this with XSLT) and then over to POJO's (via XMLBeans or JAXB). You still need to link the XML component model with your service endpoint, but that's the game we have opted to play.
I wish there was better tooling to manage a schema source tree ala a Java one.
- Saish
# 13
> Having a set of generated classes from schema might
> help to get started writing code. However most of
> these binding frameworks use JavaBean wrappers that
> are not exactly OO. To me, OO design goes well beyond
> a bunch of get/set methods. This may sound foolishly
> academic.
There are two distinct concepts of what OO is. There's the Alan Kay SmalTalk school that says C++ and Java are not OO. And then there's the Simula derived school.
In SmallTalk, the approach that is analogous to beans in Java is a fundamental part of OO. In the other school, it's bascially useless.
The problem I see is that Java almost straddles this fence but doesn't quite make it. It's still firmly on the Simula side because Java reflection is rudimentary and unweildy. We therefore need a higher level of abstraction to work with the beans effectively and this is where AOP and frameworks like Spring come into the picture.
# 14
> I 100% agree Dubwai. We are going the schema-centric
> route. You can map to WSDL (we do this with XSLT)
> and then over to POJO's (via XMLBeans or JAXB). You
> still need to link the XML component model with your
> service endpoint, but that's the game we have opted
> to play.
Just to reiterate, I would strongly recommend using JAXB to create schemas for your classes and not the other way around. There are two reasons:
1. w3C schema, DTD and RELAX NG all have much richer data structures than can be declared in Java (without executable logic.)
2. When you generate classes from the schema, you have completed the real task: binding the data to your 'real' Objects. This will either have to be done manually in reams of brittle code or you will be pulling your hair out trying to massage JAXB into doing the right thing.
If you generate the schema from your class you get simple transparent bindings to your class. And not to knock on JAXB or Castor's binding work but it's vastly easier to transform one XML into another using a XML specific language like XSL. A lot of tools have visual editors that greatly increase developer efficiency while maintaining standalone hand-editable code. If XML is a screw, XSL is a power-driver and Java is the broad side of a hatchet.
# 15
> Just to reiterate, I would strongly recommend using
> JAXB to create schemas for your classes and not the
> other way around. There are two reasons:
>
> 1. w3C schema, DTD and RELAX NG all have much richer
> data structures than can be declared in Java (without
> executable logic.)
>
This to me seems an argument in favor, rather than against, using schema-centric.
> 2. When you generate classes from the schema, you
> have completed the real task: binding the data to
> your 'real' Objects. This will either have to be
> done manually in reams of brittle code or you will be
> pulling your hair out trying to massage JAXB into
> doing the right thing.
>
Again, I look at this as a component model. I do not want a component model, for the above reasons, but once the compromise is accepted, I do not find it over-onerous.
The counter-point to the above is that going from Java to schema entails its own headaches. Now, Java changes automatically 'ripple' to the schema. Unless you generate the schema once and then hand-edit it in response to Java changes, again more work.
I do not see how you avoid the fact you have two different technologies and the boundary it creates.
> If you generate the schema from your class you get
> simple transparent bindings to your class. And not
> to knock on JAXB or Castor's binding work but it's
> vastly easier to transform one XML into another using
> a XML specific language like XSL. A lot of tools
> have visual editors that greatly increase developer
> efficiency while maintaining standalone hand-editable
> code. If XML is a screw, XSL is a power-driver and
> Java is the broad side of a hatchet.
Where *is* that damned socket wrench?
- Saish
Saisha at 2007-7-21 16:46:52 >
# 16
> This to me seems an argument in favor, rather than
> against, using schema-centric.
Maybe I misunderstand your meaning here but this isn't an argument for or against schema centric webservice design. It's really just that the common approaches to XML -> Object binding are very flawed in my opinion. Instead of trying to create a new XML based binding language, tools like JAXB should just be using XSL to bind to a canonical schema for the target (or source) class. But in lieu of that, we can do this ourselves.
I don't think we should be automatically generating Java code (except perhaps as scaffolding) from WebServices. My perspective may be somewhat unique because I experience being the middle-man in a complex B2B web of relationships. We had no choice but to support many different specifications for the same services. Some of these were vastly different in structure (even between versions of the same spec) but represented the same high-level serivce. Our leadership kept insisting we were going to try and get everyone on the same spec but it was never going to happen. By not dealing with this issue and decoupling the format of the messages from the logic that supported them, we had many problems including massive duplication of effort and all the problems stemming trom that. The attempts to do this had used standard JAXB class generation and were brittle and extremely code intensive. Think 10 levels of nested if A != null { if A.B != null { if A.B.C != null ... and no effective way to write resuable utilities across services and often even within them. Some of these issues could be resolved in newer verisons by converting to DOM but then why bother with JAXB?
# 17
> > One problem with going XML-centrist would be if
> your
> > schema is bound to change often, and schema
> > versioning. In effect, you have another type of
> > coupling here, between your application and your
> XML
> > structure. If the schema changes, you need to
> > re-generate your classes. Reverse-engineering
> tools
> > might ease this issue.
>
> Yes, but this is only true because the approach is
> incorrect, IMO.
IMO too. Still, this is the main approach that I encounter when I look at legacy code in Web services.
>
> The approach I adamantly recommend is that, if you
> are defining the service, create your contract first
> without writing a line of Java.
From the little that I know of Spring Web services (basically limited to this [url=http://www.infoq.com/articles/arjen-poutsma-spring-ws]interview on InfoQ[/url]), their approach is similar: start by writing a service contract, then write the Java classes as an implementation detail.
The generation of WSDL from XSD using XSLT was also mentioned in some Spring developer's blog as making its way into Spring-WS.
# 18
> > Yes, but this is only true because the approach is
> > incorrect, IMO.
>
> IMO too. Still, this is the main approach that I
> encounter when I look at legacy code in Web services.
Yeah, it's common. It's probably because there aren't any well known tools that put you on the right path, at least none that I know of.
> > The approach I adamantly recommend is that, if you
> > are defining the service, create your contract
> first
> > without writing a line of Java.
>
> From the little that I know of Spring Web
> services (basically limited to this
> [url=http://www.infoq.com/articles/arjen-poutsma-sprin
> g-ws]interview on InfoQ[/url]), their approach is
> similar: start by writing a service contract, then
> write the Java classes as an implementation detail.
If you read those articles on the first page, the author makes it very clear that the contract is the most crucial part of the web-service. The implementation is pretty unimportant other than that it works and even that can be resolved. If you screw the contract up, there's little you can do to remedy the situation.
What scares we is that so many people want to make the web-services contract an artifact of their code. This to me completely misses the point. Web-services aren't just a fancy way to do RPC. A service is a lot more than that.
# 19
I think we are all vaguely on the same page, or at least same set of principles. The contract is separate from any notion of a Java service or interface. That is the implementation. IMO, going schema-centric makes the most sense. You can use XSLT to get your WSDL, and you can use JAXB or XMLBeans to create the Java component model of the service. The schema itself becomes the contract (technically, it is still the WSDL, but I look at that as a generated artifact like the Java component model).
It still leaves the thorny question of versioning services and finding a good XML schema tool.
- Saish
Saisha at 2007-7-21 16:46:52 >
# 20
If you don't comply with WS-I BP 1.0 you're heading for trouble unless you know you control all clients for the web service now and into the future.
We ran into a major customer who couldn't (despite months of trying) get our web services (which are XML based but have some WS-I violations due to legacy issues brought on by our WS stack).
We're now going to have to build a special access library around our WS layer for them, effectively proxying their requests to our web services through a special service layer deployed on their systems.
Hardly what you expect of web services, which are supposed to require no special software installation client side except their own WS client stack which can be pretty much anything as long as it's compliant.
We'd love to upgrade our stack to something more modern but because of backwards compatibility issues with customer products accessing the WS layer that's impossible (literally thousands of people depend for their everyday work on that stack, it's not feasible to deploy new software to them all just because we want to change something).
# 21
> We ran into a major customer who couldn't (despite
> months of trying) get our web services (which are XML
> based but have some WS-I violations due to legacy
> issues brought on by our WS stack).
> We're now going to have to build a special access
> library around our WS layer for them, effectively
> proxying their requests to our web services through a
> special service layer deployed on their systems.
Have you considered creating a new verison of the service using a different stack? I'll risk a guess that management has excluded this option.
> Hardly what you expect of web services, which are
> supposed to require no special software installation
> client side except their own WS client stack which
> can be pretty much anything as long as it's
> compliant.
That's the big secret about SOAP based web-services that everyone that has used them for something real knows. Most vendors are not compliant. At my last job we had two tools from the same vendor that both produced WSDLs that the other could not understand. To be fair this vendor had acquired at least one of the tools from another development shop but they should have resolved this IMO.
One of the big reasons for this is that the WSDL 1.0 spec is a mess and contains redundant info. Vendors tend to provide all the correct nformation in one section but the other section is not right. Another vendor's tool will inevitably focus on the incorrect section and they can't talk.
> We'd love to upgrade our stack to something more
> modern but because of backwards compatibility issues
> with customer products accessing the WS layer that's
> impossible (literally thousands of people depend for
> their everyday work on that stack, it's not feasible
> to deploy new software to them all just because we
> want to change something).
I know this is not optimal but you should be able to create parrallel service on a different stack. You'll still be stuck supporting the old one but then you can work on incrementally moving people over. I know it's more easily said then done but it seems to me to be the only feasilble approach.
# 22
Sometimes I think that people complicate too much. This stuff about web services is so big, and the more you digg, the more you realise that there is no right way to do it.
Everyday we see new patterns appearing, new frameworks everybody is talking about, and so many specifications to follow.
I know its not a good way of doing thing, but sometimes I don't really follow the rules.... I was until last week working in a project:
ernstandedgar.dyndns.org
in which we needed to have a set of webservices that could listen to request from the mobile phone as well as from the web app, in the beginning we were keen to use SOAP with anotations, but we ended up using normal servlets....
The cost to send for eg a single id using soap from the mobile phone was just to costy, what I big envelop....
I know I am not that experient when It comes to working with webservices, but from what I am getting, there is no right path... it all depends on the project...
Great posts out there people ;)
MeTitus
# 23
SOAP is definitely overwieght but what else would you expect from Microsoft? I think it's basically a failed experiment. It's supposed to be this Object based message format but nobody uses it that way so SOAP really just gets in the way.
Now people talk about non-SOAP webservices which I find slightly odd because I recall webservices being defined as SOAP-based. I think this is confusing in general because when people talk about web-services a lot of people assume that means SOAP.
# 24
Servlets + REST can be SOA. :^)- Saish
Saisha at 2007-7-21 16:46:52 >
# 25
> Servlets + REST can be SOA. :^)
As far as I am concerned, the concept of 'service orientation' is completely independent of any technology. What's so wrong about SOA is that people think that it's a technology that you buy from a vendor. It's such a poorly defined term. I predict much pain and agony.
# 26
LOL...
Now we have this Rest framework, what will we have in two weeks time.. probably a new lot of frameworks. Frameworks won't stop comming. I am not a fan of .net, but at least when working with web services, the choice is not that much... I think that one of the problems Java will face in the future is the amout of diferent frameworks that will exist. Its good when he have a couple of tools to turn to, but when it gets to the current stage is bad... I just think that is all becoming to confusing. So many protocols, so many frameworks, I could never imagine XML would do all of this...
I am just going to strict to normal post/get, perhaps I will also use Annotations, very straight forward and its not dependent on any xml scheme... good ;)
MeTitus
Message was edited by:
Me_Titus
# 27
> There are a lot of different takes on SOA, which
> makes me think it really is not all that new. (How
> is SOA really different from CORBA anyway?)
IMO, CORBA was actually OO-based SOA (with IDL-defined interfaces ).
> I like
> thinking of SOA as two ideas: isolation and
> ownership. I know reuse is often cited, but given
> how few times I reuse my own code, reusing a service
> would seem just as problematic.
I know lots of people who would have a problem with that, if their main motivation about going SOA is the reuse of services.
And since there are hundreds of definitions of SOA (each more or less correct in its own context), here's mine, for what it's worth:
SOA is an architecture based on services, where a service is a (usually distributed) resource that is accessed in accordance with its interface. Therefore, how the service is implemented (Java, C++, etc...) is irrelevant to the client of the service.
That's it. Wonderfully simple and practically useless.
# 28
> IMO, CORBA was actually OO-based SOA (with
> IDL-defined interfaces ).
>
I would agree with that. So, we have traded OO-based SOA for hierarchy-based SOA (e.g. XML)? :^)
> I know lots of people who would have a problem with
> that, if their main motivation about going SOA is the
> reuse of services.
>
I agree with that as well. I will be the first to admit to this sin: reuse is difficult. It is not so much that reuse cannot save time, it is the difficulty in both documenting what is available and also taking the time to search what has been documented. I am not sure how SOA solves this any more than OO solves it. You are simply dealing with larger 'building blocks' than objects, IMO.
I do think widespread adoption of BPM in an organization can help to change that, but there are a whole host of new issues that are brought up (versioning, long-lived transactions, etc.)
> And since there are hundreds of definitions of SOA
> (each more or less correct in its own context),
> here's mine, for what it's worth:
>
> SOA is an architecture based on services, where a
> service is a (usually distributed) resource that is
> accessed in accordance with its interface. Therefore,
> how the service is implemented (Java, C++, etc...) is
> irrelevant to the client of the service.
>
> That's it. Wonderfully simple and practically useless.
Definitely not useless. I would agree with your definition. I would just add ownership and isolation. Legacy code exists, and we need some way to have SOA leverage it.
- Saish
Saisha at 2007-7-21 16:46:52 >
# 29
> SOA is an architecture based on services, where a
> service is a (usually distributed) resource that is
> accessed in accordance with its interface. Therefore,
> how the service is implemented (Java, C++, etc...) is
> irrelevant to the client of the service.
I've adopted Thomas Erl's definitions and he calls that Service-Orientation. SOA is given a more precise definition:
"I've always maintained that service-oriented architecture is a form of distributed architecture for automation logic that has been designed in accordance with service-orientation principles."
# 30
Isn't that definition tautological?- Saish
Saisha at 2007-7-21 16:46:57 >
# 31
> Isn't that definition tautological?
>
I would say not entirely. That definition, in the mind of the author, is a way to put the focus on design principles, not on technology nor particular product or implementation. A product or implementation might be superseded by another, but the paradigm itself will remain.
Of course he would need to go on and define precisely those "service-orientation principles"...Otherwise it is quite possible that the author's attempt to avoid the confusion around SOA might end up being even more confusing...
# 32
Fair enough. Can I kick the can one step down the road and ask what hte 'service-orientation' principles are then? :^)- Saish
Saisha at 2007-7-21 16:46:57 >
# 33
Ran a little search, and found [url=http://webservices.sys-con.com/read/136190.htm]one article[/url] where that author lists and explains those principles which are:
* services are loosely coupled
* services share a formal contract
* services abstract underlying logic
* services are composable
* services are reusable
* services are autonomous
* services are stateless
* services are discoverable
# 34
> Ran a little search, and found
> [url=http://webservices.sys-con.com/read/136190.htm]on
> e article[/url] where that author lists and explains
> those principles which are:
>
>* services are loosely coupled
Hard to disagree with.
> * services share a formal contract
Between each other or each? The latter seems the only possible interpretation.
>* services abstract underlying logic
Nothing to disagree with.
> * services are composable
Nothing to disagree with
>* services are reusable
Nothing to disagree with (though see caveat on reusability in previous posts)
> * services are autonomous
I am not sure what is being said. Is this an expansion on loose coupling?
>* services are stateless
Yes, that is the prescription, but linking a service to BPM or orchestration in general will introduce state, so my guess is this stricture will be relaxed.
> * services are discoverable
If discoverable internally (e.g., for documentation purposes), then I have nothing to disagree with. If discoverable externally, I have yet to find a company doing so. If they are doing so, I will whack them on the head and ask why.
BTW, please take the above in the spirit it was intended, just to spark some thoughts. When I re-read my responses, most indicate I have nothing to disagree with. I have developed an instinctive fear of ideas I cannot disagree with. It normally means the ideas are not saying much.
For example, "Services allow faster, more efficient, more reusable, language independent development." All well and good, but have I said much?
- Saish
Saisha at 2007-7-21 16:46:57 >
# 35
> BTW, please take the above in the spirit it was
> intended, just to spark some thoughts. When I
> re-read my responses, most indicate I have nothing to
> disagree with. I have developed an instinctive fear
> of ideas I cannot disagree with. It normally means
> the ideas are not saying much.
I don't want to repeat what Erl has already written but in reply 9, I posted a link to a full-length article on each of these concepts. I really recommend it when you have some time. It may not be perfect but it's something concrete. I'm trying to get people on my team to read these things so that we can work from a common lexicon.
Let me just say that I am very allergic to bs and I wouldn't post these links if I didn't think this guy was for real. I guess what made me so admire this author was that this was the first thing I read about serivce-orientation that actually meant anything to me. Everything else I had heard and read was just cloudware.
I think SOA or SO is going to have a similar life-cycle as OO did. Back in the day, OO was 'the thing' but after a while then all the charlatans found something else to sell and people who really knew things and appreciated the value of OO kept on using it. Nobody comes in and 'sells' OO to your CIO anymore. It's a decision made by technical people, for the most part. I expect the same with service orientation and SOA but the sad part is that things are going to get a lot worse before they get better.
# 36
> > * services are autonomous
>
> I am not sure what is being said. Is this an
> expansion on loose coupling?
This is a good example. From his artcile on autonomy and statelessness:
"For services to provide reliable, predictable performance they must exercise a significant degree of control over their underlying resources. Autonomy represents this measure and this principle emphasizes the need for individual services to possess high levels of individual autonomy."
I take this to say in part that services should not depend on each other, which is, to be honest, not something I had really been thinking. I don't think this is an obvious conclusion nor is it one that you here much about.
# 37
> I don't want to repeat what Erl has already written
> but in reply 9, I posted a link to a full-length
> article on each of these concepts. I really
> recommend it when you have some time. It may not be
> perfect but it's something concrete. I'm trying to
> get people on my team to read these things so that we
> can work from a common lexicon.
>
That is fine by me. It definitely increases the difficulty by an order of magnitude (if such things can be quantified) if posters cannot converse using a common 'language' for SOA. And I am happy to adopt several of the author's terms.
> Let me just say that I am very allergic to bs and I
> wouldn't post these links if I didn't think this guy
> was for real. I guess what made me so admire this
> author was that this was the first thing I read about
> serivce-orientation that actually meant anything to
> me. Everything else I had heard and read was just
> cloudware.
>
Me too. Severe allergy. It causes my nose to wrinkle up and has been known to cause sweats.
That having been said, and I hope you do not feel offended by this, but I really did not learn all that much from those articles. The main reason you should not be offended is that *no* article I have ever read (and I have read too many over the past half year) can really articulate what SOA is. There are always principles. There are always definitions. And, again, it is hard to argue against *any* of them. I have a hard time reading what Erl wrote and not thinking, "How is this different in any way from OOP and/or CORBA?"
It is exceptionally well written, but it gives me no real guidance. For example, if I told you, "your town will be happier if everyone treats their neighbors better", who could disagree? Yet, what prescription does that statement offer? How is it testable and how would one "know" that your decisions embraced SOA?
> I think SOA or SO is going to have a similar
> life-cycle as OO did. Back in the day, OO was 'the
> thing' but after a while then all the charlatans
> found something else to sell and people who really
> knew things and appreciated the value of OO kept on
> using it. Nobody comes in and 'sells' OO to your CIO
> anymore. It's a decision made by technical people,
> for the most part. I expect the same with service
> orientation and SOA but the sad part is that things
> are going to get a lot worse before they get better.
I totally agree 100% with all of the above.:^)
- Saish
Saisha at 2007-7-21 16:46:57 >
# 38
From Erl's definition of "pure" autonomy (which I take to be normative):
Pure autonomy The underlying logic is under complete control and ownership of the service. This is typically the case when the logic is built from the ground up in support of the service.
Again, vocabulary can be an issue, but referring back to my original assertions of what differentiates SOA, that quote, to me, *is* ownership and isolation.
- Saish
Saisha at 2007-7-21 16:46:57 >
# 39
> That having been said, and I hope you do not feel
> offended by this, but I really did not learn all that
> much from those articles. The main reason you should
> not be offended is that *no* article I have ever read
> (and I have read too many over the past half year)
> can really articulate what SOA is. There are always
> principles. There are always definitions. And,
> again, it is hard to argue against *any* of them. I
> have a hard time reading what Erl wrote and not
> thinking, "How is this different in any way from OOP
> and/or CORBA?"
When you say that it i hard to argue against them, are you saying you agree with them or that they are stated in such a way that there is no way to argue against them?
Maybe I need to give an example of why I think these are useful because I agree with you that at least in general, these are not concepts that are shocking and surprising. My personal belief is that SOA is evolutionary and not revolutionary, if you'll forgive the cliche. CORBA is an technology that could be used to implement SOA. I believe that EDI can be used to implement SOA. SOA is more general, like OO. SOA and OO also have parallels but I think that the Object concept doesn't translate well to SOA. I think it goes back to the "7 (or 8?) myths of the network".
But here's what I mean. I have a boss at work that has decided that SOA is the way to go but nobody really knows what that means. He's convinced that every query should be set up as a service. Really, everything is supposed to be a service. When I look at these articles, it makes me feel more confident in my beliefs that this doesn't make sense. Not just because he's saying what I think, but because he's articulating what I've learned from personal experience in a way that I can not and pointing out subtleties that aren't obvious (at least not to me.)
Maybe I'm making too much of it but I think it's light-years away from stuff like this: http://webservices.sys-con.com/read/233612.htm
# 40
> From Erl's definition of "pure" autonomy (which I
> take to be normative):
>
> Pure autonomy The underlying logic is under
> complete control and ownership of the service. This
> is typically the case when the logic is built from
> the ground up in support of the service.
>
> Again, vocabulary can be an issue, but referring back
> to my original assertions of what differentiates SOA,
> that quote, to me, *is* ownership and isolation.
>
> - Saish
You almost seem to be saying that you don't agree with it because you agree with it so much ; )
# 41
Well, maybe at least we could agree to what SOA is NOT:
- A technology
- A product
- A computing platform
- Revolutionary
And maybe also to what SOA is not entirely:
- Pure marketing-****
I prefer my own useless definition of SOA, (being naturally and understandably biased towards my own opinions), but I have to admit that Erl's writings on SOA are not just bull. Nothing really astonishing in his points, but gives you a general view of the concept that has its own usefulness.
At least it would give me some simple material for a PowerPoint presentation for (an often confused) upper-management.
Specially since some of us have the chance (or misfortune) to be invited by the CIO every time a (big) vendor comes in trying to sell us his Marchitecture on SOA/ESB. The amount of bull appears to be more or less proportionate to the level of sophistication of their presentation diagrams. The nicer the graphics, The more bs they seem to convey.
Maybe there is a "law"somewhere that states that.
# 42
> When you say that it i hard to argue against them,
> are you saying you agree with them or that they are
> stated in such a way that there is no way to argue
> against them?
>
Exactly. I think most serious decisions involve trade-offs and compromises. But you never hear anything like that in discussions of SOA. It appears to be a pure, universal good in terms of architecture, the way it is marketed. Whenever I hear something that sounds too good to be true, it usually is.
> Maybe I need to give an example of why I think these
> are useful because I agree with you that at least in
> general, these are not concepts that are shocking and
> surprising. My personal belief is that SOA is
> evolutionary and not revolutionary, if you'll forgive
> the cliche. CORBA is an technology that could be
> used to implement SOA. I believe that EDI can be
> used to implement SOA. SOA is more general, like OO.
> SOA and OO also have parallels but I think that the
> Object concept doesn't translate well to SOA. I
> think it goes back to the "7 (or 8?) myths of the
> network".
>
I totally agree that SOA could be realized via CORBA and that SOA and OO are strikingly similar. Look at the aspects common to both: modularity, reusability, loose coupling, autonomy, etc. IMO, services are conceptually like "larger" objects. They simply represent a unit of organization. A cynic might respond that OO was supposed to solve most of these problems a few decades ago, and it has not. Software complexity is continuing to grow to the point where developers without tooling will have a hard time coping.The solution? Create a larger unit of organization to keep track of. Now, you "think" in services and "build" in objects.
> But here's what I mean. I have a boss at work that
> has decided that SOA is the way to go but nobody
> really knows what that means. He's convinced that
> every query should be set up as a service. Really,
> everything is supposed to be a service. When I look
> at these articles, it makes me feel more confident in
> my beliefs that this doesn't make sense. Not just
> because he's saying what I think, but because he's
> articulating what I've learned from personal
> experience in a way that I can not and pointing out
> subtleties that aren't obvious (at least not to me.)
>
Sorry, I got confused. You do agree with your boss about SOA or not? (There is one sentence where you indicate it does not make sense and then then next where you agree with your boss).
But you are 100% right, no one really knows what SOA is. That's another reason that my spidey sense gets triggered. The best, practical take from what I have read is:
- Stateless (though BPM will change this)
- Autonomous (ownership and isolation in my mind)
- Loose Coupling
- Primary organizational unit of architecture
To those I would add that services should provide cross-cutting concerns or aspects such as authentication, authorization, validation, auditing, logging, error handling, transaction management, etc. (whether realized as AOP or OOP).
However, all of the above could easily be copy-pasted into a discussion of EJB-oriented architecture seven years ago. What does SOA add other than using XML/WSDL/WS?
> Maybe I'm making too much of it but I think it's
> light-years away from stuff like this:
> http://webservices.sys-con.com/read/233612.htm
That's an interesting take. In all honesty, I use Web 2.0 but have yet to develop anything (other than simple Ajax for business purposes) that leverages it. Really, I do not think they are at cross-purposes. SOA really speaks to the M in MVC whereas Web 2.0 could easily fill VC. If you move web state out of our SOA architecture (to remain stateless) and perhaps provide optimized protocols (e.g., do not invoke a web service from Ajax) for a richer client experience, one could have the best of both worlds. Granted, digesting SOA is hard enough without also trying to get Web 2.0 in there.
- Saish
Saisha at 2007-7-21 16:46:57 >
# 43
> You almost seem to be saying that you don't agree> with it because you agree with it so much ; )I am suspicious of it because I cannot find anything to disagree with. Yes. (It's sick, but too much silicon snake oil this year has me jumpy). :^)- Saish
Saisha at 2007-7-21 16:46:57 >
# 44
> Well, maybe at least we could agree to what SOA is
> NOT:
>
> - A technology
> - A product
> - A computing platform
> - Revolutionary
>
To that, I would add 'a panacea'. :^)
> And maybe also to what SOA is not entirely:
>
> - Pure marketing-****
>
> I prefer my own useless definition of SOA, (being
> naturally and understandably biased towards my own
> opinions), but I have to admit that Erl's writings on
> SOA are not just bull. Nothing really astonishing in
> his points, but gives you a general view of the
> concept that has its own usefulness.
> At least it would give me some simple material for a
> PowerPoint presentation for (an often confused)
> upper-management.
>
I would buy that, a synopsis rather than a prescription.
> Specially since some of us have the chance (or
> misfortune) to be invited by the CIO every time a
> (big) vendor comes in trying to sell us his
> Marchitecture on SOA/ESB. The amount of bull appears
> to be more or less proportionate to the level of
> sophistication of their presentation diagrams. The
> nicer the graphics, The more bs they seem to convey.
>
>
> Maybe there is a "law"somewhere that states that.
Murphy's.
- Saish
Saisha at 2007-7-21 16:46:57 >
# 45
> > When you say that it i hard to argue against them,
> > are you saying you agree with them or that they
> are
> > stated in such a way that there is no way to argue
> > against them?
> >
>
> Exactly.
Uh, it was an OR question ; )
> I think most serious decisions involve
> trade-offs and compromises. But you never hear
> anything like that in discussions of SOA. It appears
> to be a pure, universal good in terms of
> architecture, the way it is marketed. Whenever I
> hear something that sounds too good to be true, it
> usually is.
Well I agree that is what you usually see but referring back to that article:
"Clearly, it is more desirable for a service inventory to contain purely autonomous services. Not only does it help us deal with scalability concerns, such as concurrent access conditions, it also empowers us to position services more reliably to counter the "single point of failure" risk that often comes with leveraging reusable automation logic. However, because it generally requires that new service logic be created and often demands special deployment considerations, it can impose significant additional expense and effort."
In other words, this principle of service-orientation, if followed, will increase costs. That's a trade-off in my book.
> I totally agree that SOA could be realized via CORBA
> and that SOA and OO are strikingly similar. Look at
> the aspects common to both: modularity, reusability,
> loose coupling, autonomy, etc.
I don't see autonomy as being a principle of OO. Often Objects are composed of other Objects. Autonomy in the way Erl is using is says that services should not be composed of other services. I think this only really applies to base services. There are also pure-composites but IIRC that is discussed elsewhere. There is also no concept of polymorphism in SO (as far as I know) which is a crucial part of OO.
> IMO, services are
> conceptually like "larger" objects. They simply
> represent a unit of organization. A cynic might
> respond that OO was supposed to solve most of these
> problems a few decades ago, and it has not. Software
> complexity is continuing to grow to the point where
> developers without tooling will have a hard time
> coping.The solution? Create a larger unit of
> organization to keep track of. Now, you "think" in
> services and "build" in objects.
I don't disagree completely but it's not a direct analogy. The rules change at the 'enterprise' level.
> Sorry, I got confused. You do agree with your boss
> about SOA or not? (There is one sentence where you
> indicate it does not make sense and then then next
> where you agree with your boss).
No, I agree with Thomas Erl and not my boss (really my boss-boss.) Reading what Erl says made me more confident that it's not me who doesn't get it. To be clear I read this a while back after leaving an organization that was implementing a dysfunctional SO 'architecture'.
> But you are 100% right, no one really knows what SOA
> is. That's another reason that my spidey sense gets
> triggered. The best, practical take from what I have
> read is:
I think there are people that know what it is. The problem is few people agree. OO is kind of that way too, though.
> However, all of the above could easily be copy-pasted
> into a discussion of EJB-oriented architecture seven
> years ago. What does SOA add other than using
> XML/WSDL/WS?
But that's exactly the point. SO is like the book Design Patterns. It's not a bunch of new ideas cooked up by some suits at a think tank. It's a term given to proven approaches for distributed systems, especially those with heterogenous topologies. It's not new. You seem to keep combing back to that as a complaint. No one who knows anything about SOA will tell you it's new. It's not. A lot of this stuff has been done in the EDI world for decades. Much longer than CORBA or EJB have been around.
To me SOA is a chance for the IT industry to stop the endless parade of technologies that will 'solve all our problems' and say, "what the hell are we actually trying to accomplish?" The problem is that there are so many people acting as if SOA is another technology. SOA is not webservices or SOAP. It's got nothing to do with whether you use XML.
> > Maybe I'm making too much of it but I think it's
> > light-years away from stuff like this:
> > http://webservices.sys-con.com/read/233612.htm
>
> That's an interesting take. In all honesty, I use
> Web 2.0 but have yet to develop anything (other than
> simple Ajax for business purposes) that leverages it.
> Really, I do not think they are at cross-purposes.
To me this article says:
"48% of CIOs say they plan to mate their flux capacitors with external interfaces. Ajax your SOAs to leverage your impacted users' mindshare in the web 2.0 mashup blogosphere dancing silhouettes translucent windows."
# 46
> Well, maybe at least we could agree to what SOA is
> NOT:
>
> - A technology
> - A product
> - A computing platform
> - Revolutionary
Yes and it's also not 'the solution for every problem'.
> And maybe also to what SOA is not entirely:
>
> - Pure marketing-****
Depends on who's talking/writing about it.
> I prefer my own useless definition of SOA, (being
> naturally and understandably biased towards my own
> opinions), but I have to admit that Erl's writings on
> SOA are not just bull. Nothing really astonishing in
> his points, but gives you a general view of the
> concept that has its own usefulness.
I'm not sure why you think it's useless. I think you are saying that because it doesn't tweak your paradigm. The power is within you, my friend. Use the force.
> At least it would give me some simple material for a
> PowerPoint presentation for (an often confused)
> upper-management.
Exactly. This, to me is the value of SOA. Because it's so hot it gives peons like me a chance to explain how we can address the issues we face and not just buy more stuff.
# 47
> > I prefer my own useless definition of SOA,
> I'm not sure why you think it's useless. I think you
> are saying that because it doesn't tweak your
> paradigm.
In my personal mission to try to prevent organizations from being totally hype-driven, my own definition of SOA doesn't help much. I have yet to see someone's face enlighten with a new and deeper understanding of the idea when they hear/read it.
It is quite obvious that, the more confusion there is around a concept, the more detailed your definition must be.
I find it necessary to dig into more details than a simple two-lines definition (without having to write a whole book on the subject) to convey something that does not increase the amount of confusion in people's minds.
That's probably also why I find Erl's writings useful. By outlining those principles in more details, it helps people better understand what SOA is, what SOA is not (and hence what's not SOA).
# 48
> That's probably also why I find Erl's writings
> useful. By outlining those principles in more
> details, it helps people better understand what SOA
> is, what SOA is not (and hence what's not SOA).
I agree completely. SOA doesn't enlighten people like you me and Saish a whole lot but that doesn't mean it's not elighening anyone. Like you said, it's a good way to provide more guidance to the confused. My experience is that having something written (and published) to show someone is often more convincing than good logical arguments. I think this is a tragedy but it's my life. Personally I think this is because most people can't differentiate between a strong logical argument and rhetorical BS. The coming American presidential election will demonstrate this abundantly, I'm sure.
# 49
Sorry not to get back to you Dubwai and Karma, I got slammed starting Wednesday with no end in sight. Will try to collect some thoughts this weekend. Enjoy yours!- Saish
Saisha at 2007-7-21 16:47:02 >
# 50
>
> That's probably also why I find Erl's writings
> useful. By outlining those principles in more
> details, it helps people better understand what SOA
> is, what SOA is not (and hence what's not SOA).
I think I would find these sorts of high level conceptual principles much more meaningful if I ever worked for or even was aware of an organisation that was able to maintain a consistent planning system (with controlled evolution) for even several years.
Every company I have ever worked for or that I have even interviewed with works solely on a system that looks like the following.
1. Month One. ARRGGHHH! Everyone run to the right NOW!!!!!
2. Month Two. ARRGGHH! Everyone drop everything and run to the left NOW!!
3. Month Three STOP! STOP! Eveyone look at the newest conceptual model and rethink the entire process because it is entirely out of control!
4. Next day....go back to step 1 and repeat....
Of course some innovative companies modify the above schedule by attempting to reduce the steps above to either two week or even one week schedules. And then have their developers congradulate themselves on managing that.
# 51
> Every company I have ever worked for or that I have
> even interviewed with works solely on a system that
> looks like the following.
> 1. Month One. ARRGGHHH! Everyone run to the right
> NOW!!!!!
> 2. Month Two. ARRGGHH! Everyone drop everything and
> run to the left NOW!!
> 3. Month Three STOP! STOP! Eveyone look at the newest
> conceptual model and rethink the entire process
> because it is entirely out of control!
> 4. Next day....go back to step 1 and repeat....
>
These systems illustrate what happens when there is a serious disconnect between business and technical management, and where non-technical project managers are responsible for IT-driven projects and deliverables.
A couple of things need to happen to change this to eliminate these systems. First, the CIO needs to be included in all decisions including, new product development. All projects related to anything with a software delivery should have a project manager with an IT/Technical background. A Project Management certification from the BirdBrain Institute does not cut it any more :o)
Second, proper training on what a service oriented architecture is, is a truly fundamental requirement. Project managers and Business Development managers that get all their knowledge about SOA from ?oogle search results can't really make good decisions about building SOA architectures or applications.
These changes need to come from the top (i.e. CIO and a CFO that understands how things work). It is not about old-style linear management, it is more like circular development and proper leadership at the top. Leadership and managment are two separate, but related concepts.
Not all managers are leaders, and not all leaders are managers.
# 52
>
> These systems illustrate what happens when there is a
> serious disconnect between business and technical
> management, and where non-technical project managers
> are responsible for IT-driven projects and
> deliverables.
>
> A couple of things need to happen to change this to
> eliminate these systems. First, the CIO needs to be
> included in all decisions including, new product
> development. All projects related to anything with a
> software delivery should have a project manager with
> an IT/Technical background. A Project Management
> certification from the BirdBrain Institute does not
> cut it any more :o)
>
> Second, proper training on what a service oriented
> architecture is, is a truly fundamental requirement.
> Project managers and Business Development managers
> that get all their knowledge about SOA from ?oogle
> search results can't really make good decisions about
> building SOA architectures or applications.
>
> These changes need to come from the top (i.e. CIO and
> a CFO that understands how things work). It is not
> about old-style linear management, it is more like
> circular development and proper leadership at the
> top. Leadership and managment are two separate, but
> related concepts.
>
> Not all managers are leaders, and not all leaders are
> managers.
There are connections described there that do not and need not exist.
It has been proven that top down (management) driven process control is much more likely to succeed and to actually have visible improvement than bottom up.
All methodologies are impacted by that.
Project management is meaningless unless the process supports task management and schedule management and there is an understanding of the difference. The process must provide a way for those to be used rather than merely providing a tracking tool (tracking demonstrates nothing but that 'deliverables' are always late.)
All aspects of a business can be impacted postively by managing process control. Sales can be just as chaotic as software developement or it can be very rigorously controlled at the same time that software developement is chaotic. Technical profenciency does not decrease chaos, nor in my experience, is it any more likely to lead to a less chaotic environment. So one can't blame business leaders versus technical leaders for a failure to implement this. Actually technically trained individuals are more to blame because they are more likely (at least a little bit) to know that alternatives exist and should be capable of proving the benifits to the business but fail to even try. And at least some times the most profficient technically are the most likely to actively and passively fight the imposition of any process control.
I should note that even the "serious" efforts I have seen toward process control have evolved into little more that pushing paper excercises and at one place the rank and file didn't consider it anything but that. It indicates a failure to educate in the benefits of process control itself.
And when process control is effectively used it allows time for training in technical areas. It is a lot easier to travel to a seminar or schedule a class when one can effectively plan something for something two months from now rather than doing it anyways and hoping that half the trainees are pulled out to fight yet another fire.
# 53
> I think I would find these sorts of high level
> conceptual principles much more meaningful if I ever
> worked for or even was aware of an organisation that
> was able to maintain a consistent planning system
> (with controlled evolution) for even several years.
>
> Every company I have ever worked for or that I have
> even interviewed with works solely on a system that
> looks like the following.
> 1. Month One. ARRGGHHH! Everyone run to the right
> NOW!!!!!
> 2. Month Two. ARRGGHH! Everyone drop everything and
> run to the left NOW!!
> 3. Month Three STOP! STOP! Eveyone look at the newest
> conceptual model and rethink the entire process
> because it is entirely out of control!
> 4. Next day....go back to step 1 and repeat....
>
That is probably why I try to limit myself on making sure they fully understand the newest conceptual model.
What they'll do next, as what they were doing before, is basically out of my hands, and I stopped worrying about that some time ago. So, in this particular case, make sure they understand what SOA is. What they do with that understanding is up to them.
In corporate politics, there are all kinds of alliances, relationships, etc.. that drive the organization to basically nowhere (i.e. steps 1,2,3,4) ,and that you have practically no influence over. I stopped fighting for my ideas a long time ago. I just make suggestions now. Most of the time, they are not followed. And when they are, I often find out that the real motive lies elsewhere than in my recommendations, presentations and logical arguments.
# 54
> These systems illustrate what happens when there is a
> serious disconnect between business and technical
> management, and where non-technical project managers
> are responsible for IT-driven projects and
> deliverables.
I found the worst kind of manager to be somewhere in the middle, i.e. the one with just enough technical knowledge to screw things up.
# 55
> It has been proven that top down (management) driven process control is much more likely to succeed > and to actually have visible improvement than bottom up.
Yes, this is why I state that the role and importance of the CIO needs to be changed a bit and a process-oriented focus needs to stream downwards from this role. CEO has other things to focus on and CFO is only thinking about the hard dollar.
> Project management is meaningless unless the process supports task management and schedule
> management and there is an understanding of the difference.
Yes, in my opinion managing tasks and managing schedule are all part of project manangement. The problem with traditional PM is that is too linear and focused on sequential timelines and deliveries. Today's effective software development is circular by nature. The principles of the Agile methodology state it best:
Responding to change over following a plan
Customer collaboration over contract negotiation
Working software over comprehensive documentation
Individuals and interactions over processes and tools
By moving towards an adaptive process, IT leaders will be better able to serve the business more effectively and implement the process controls and standards to actually deliver successful software projects.
> Technical profenciency does not decrease chaos, nor in my experience, is it any more likely to lead > to a less chaotic environment.
True technical proficiency, in the terms of my statement, means that the individual understands the software development process of the organization and knows the technology and knows how to plan software development with the tools and resources in front of him/her. I'm not talking about knowing how to write a thread-safe Singleton or knowing what MVC is, for sure. The technical proficiency I speak of helps to reduce chaos and guide and implement robust engineering with effective process control.
Business leaders should not be blamed for failure. They should just not be expected to understand, manage, or lead the software process. And since most projects and business plans are centered around information systems and software, business leaders need to look down and put the right, technically proficient individuals in place. Someone with a MBA in Accounting should not be controlling the software development process and should not have a stronger voice than the IT leaders in product development/planning.
Effective IT leaders understand the need for process control and rarely actively or passivley fight it's imposition.
# 56
> Every company I have ever worked for or that I have
> even interviewed with works solely on a system that
> looks like the following.
> 1. Month One. ARRGGHHH! Everyone run to the right
> NOW!!!!!
> 2. Month Two. ARRGGHH! Everyone drop everything and
> run to the left NOW!!
> 3. Month Three STOP! STOP! Eveyone look at the newest
> conceptual model and rethink the entire process
> because it is entirely out of control!
> 4. Next day....go back to step 1 and repeat....
Hilarious stuff. Really. I want to print it out and put it on the wall at work.
I've been beaten down into despair because of this. At my last job I was beaten so bad I almost shriveled up and turned into a mushroom.
But then I got laid off. My position was off-shored and it was one of the best things that ever happened to me. I decided then I wasn't going to sit back and let a bunch of mrns get me fired again.
# 57
> > It has been proven that top down (management)
> driven process control is much more likely to succeed
> > and to actually have visible improvement than
> bottom up.
>
> Yes, this is why I state that the role and importance
> of the CIO needs to be changed a bit and a
> process-oriented focus needs to stream downwards from
> this role. CEO has other things to focus on and CFO
> is only thinking about the hard dollar.
>
>
> > Project management is meaningless unless the
> process supports task management and schedule
> > management and there is an understanding of the
> difference.
>
> Yes, in my opinion managing tasks and managing
> schedule are all part of project manangement. The
> problem with traditional PM is that is too linear and
> focused on sequential timelines and deliveries.
> Today's effective software development is circular by
> nature. The principles of the Agile methodology state
> it best:
>
> Responding to change over following a plan
> Customer collaboration over contract negotiation
> Working software over comprehensive documentation
> Individuals and interactions over processes and
> tools
>
> By moving towards an adaptive process, IT leaders
> will be better able to serve the business more
> effectively and implement the process controls and
> standards to actually deliver successful software
> projects.
>
Still missing the point - it doesn't matter what methodology is used in terms of success. All that matters is that methodology is driven from the top down. Agile isn't magic in that regard.
> > Technical profenciency does not decrease chaos, nor
> in my experience, is it any more likely to lead > to
> a less chaotic environment.
>
> True technical proficiency, in the terms of my
> statement, means that the individual understands the
> software development process of the organization and
> knows the technology and knows how to plan software
> development with the tools and resources in front of
> him/her. I'm not talking about knowing how to write a
> thread-safe Singleton or knowing what MVC is, for
> sure. The technical proficiency I speak of helps to
> reduce chaos and guide and implement robust
> engineering with effective process control.
>
I have never seen that actually occur. Even the few companies that actually thought they were doing it were still in the completely chaotic phase. When people think that coding standards provide benefit when they can't even manage to put together a coherent project estimate it is always a problem.
> Business leaders should not be blamed for failure.
> They should just not be expected to understand,
> manage, or lead the software process. And since most
> projects and business plans are centered around
> information systems and software, business leaders
> need to look down and put the right, technically
> proficient individuals in place. Someone with a MBA
> in Accounting should not be controlling the software
> development process and should not have a stronger
> voice than the IT leaders in product
> development/planning.
It doesn't matter why it happens.
However I have already indicated that in my experience I have seen people who were technically proficient and who seemed to understand the benefits of process control and who were far enough up in the hierarchy to enforce a real difference. And it never happened.
>
> Effective IT leaders understand the need for process
> control and rarely actively or passivley fight it's
> imposition.
Not in my experience although I am not sure what you mean by "leaders". Every individual I have seen in a management role has fallen into one of the following categories.
1. Process control is good but we don't have time for that now.
2. No idea why we are doing process control, the execs or customers want it, so just fill in the paperwork and get on with the real job.
# 58
>
> Hilarious stuff. Really. I want to print it out and
> put it on the wall at work.
>
> I've been beaten down into despair because of this.
> At my last job I was beaten so bad I almost
> shriveled up and turned into a mushroom.
>
> But then I got laid off. My position was off-shored
> and it was one of the best things that ever happened
> to me. I decided then I wasn't going to sit back and
> let a bunch of mrns get me fired again.
I just gave up. It started when a company I was out was bought out by another and we were told that a significant reason for that was because our process was better than theirs. Something like a month after that the process control committee (which I was a very active member of) was disbanded because, I was told, that that stuff would just 'confuse' the software developers at the other company.
I quit. I figured I would just go work for a company that was doing process control.
After interviewing over a number of years I realized that all companies did one of the following...
1. They have no idea what process control is and when I try to explain it they fixate on source control when I mention it and claim that they do that. (Actually one company didn't even have source control.)
2. The developers, individually (not a group) are allowed to do that if they want.
3. The developers as a group are trying that and real soon now they are going to put together some coding standards to enforce it. And they try to review at least 10% of code all the time but sometimes they don't make that (wink, wink, nudge, nudge.)
# 59
Not that I disagree with what has been added, but I think there are a number of other possibilities, other than top-down that can work.
For example, I have worked in locations that have centers of excellence with the most experienced developers (not architecture teams, but architects are on the team). People on that team spend about half time working on core tasks and the other being loaned out to individual projects as needed. I have seen this work fairly effectively, generally in organizations that also have mentoring.
Another option, along similar but slightly different lines, is to encourage competition between development groups. For example, in one company, there was a very large 'main' development group and a much smaller team assigned to a specific business unit. If the smaller group can move more rapidly than the larger team (which it should be able to do, even with the same quality of developers), the competition it engenders can be beneficial to the company.
The flip-side to both of the above is you can get in that unfortunate situation where you are implementing technology or frameworks for their own sake rather than for a specific problem or need.
Just my two cents.
- Saish
Saisha at 2007-7-21 16:47:02 >
# 60
> Another option, along similar but slightly different
> lines, is to encourage competition between
> development groups. For example, in one company,
> there was a very large 'main' development group and a
> much smaller team assigned to a specific business
> unit. If the smaller group can move more rapidly
> than the larger team (which it should be able to do,
> even with the same quality of developers), the
> competition it engenders can be beneficial to the
> company.
I actually worked (briefly) in a well-known financial company where that kind of competition was taking place. To the point that PMs were trying to steal each other's best developers by all means necessary. The work environment that the intense competition created was not ideal for the developers (hence not for the company as a whole), because of the tension and instability it created, added to the usual pressure to get a product out by due date.
Maybe you have a point, in general. But interesting ideas can have unintended and surprising "side-effects" when implemented.
# 61
Back to the Web Services subject, here's an interesting and kind of funny blog post about SOAP and WS-* stuff :[url= http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/]S stands for Simple[/url].
# 62
> Back to the Web Services subject, here's an
> interesting and kind of funny blog post about SOAP
> and WS-* stuff :
> [url=http://wanderingbarque.com/nonintersecting/2006/1
> 1/15/the-s-stands-for-simple/]S stands for
> Simple[/url].
That is right on the mark. So much so that it is scary. As far as I am concerned, SOAP is an unecessary complication.
# 63
That was priceless Karma!- Saish
Saisha at 2007-7-21 16:47:06 >
# 64
I actually worked (briefly) in a well-known financial company where that kind of competition was taking place. To the point that PMs were trying to steal each other's best developers by all means necessary. The work environment that the intense competition created was not ideal for the developers (hence not for the company as a whole), because of the tension and instability it created, added to the usual pressure to get a product out by due date.
Maybe you have a point, in general. But interesting ideas can have unintended and surprising "side-effects" when implemented.
Fair enough. Though in this specific instance, there was always a cohesive group that generated the competition. They would be 'loaned' to a given project, but only half-time. Yes, there are plenty of ways the system can be gamed or corrupted, but I just wanted to point out another possibility.
I do agree with JSchell that top-down works best, but I believe that is normally because you implicitly or explicitly have buy-in from upper management at that point.
- Saish
Saisha at 2007-7-21 16:47:06 >
